Issue 18436: Serilaization of required stereotypes (uml25-ftf) Source: EADS (Mr. Yves Bernard, yves.bernard(at)airbus.com) Nature: Clarification Severity: Summary: There are some specific cases where serialization of Extension instances resulting from the application of a stereotype does not provide any added value. However it creates a memory footprint overhead. These cases can be characterized by the conjunction of the following conditions: The stereotype is defined so that it is an required extension (i.e. its isRequired property is “true”) This stereotype does not have any property or all of its properties are derived (i.e. isDerived is “true”) As per the current specifications of UML and MOF2XMI, I cannot find anything that formally implies the serialization of extensions resulting from the application of such a stereotype but this reading appears to be controversial (cf. the attached mails exchange). Nevertheless, the standard way to add semantics in a profile relies on stereotypes definition only and there are some practical cases leading to defined stereotypes of the kind described above. For instance, within the SysML specification we defined a set of queries to retrieve elements involved in a specific kind of relationships (e.g. allocation), even if those elements do not themselves hold any information about it. Finally, those stereotypes are no more that a specification mechanism used to define a set of query applicable to a set of elements and the memory footprint overhead is not justified. Suggested resolution: To add a Boolean query (with maybe a corresponding derived property) to the Extension metaclass. This will return “true” when an extension shall be serialized. I propose to use the following OCL expression to specify this query: context Extension def: mustBeSerialized() : Boolean = self.isRequired=false or self.ownedEnd.type.attribute->select(isDerived)->notEmpty() To clarify that extensions that return “false” to the query above are aliases for their base classes in any context where the profile is applied. Therefore, any reference to an element typed by the corresponding stereotype shall actually be resolved (and then serialized) as a reference to the corresponding instance of the extended class. Resolution: Revised Text: Actions taken: February 11, 2013: received issue Discussion: End of Annotations:===== m: "BERNARD, Yves" To: "issues@omg.org" Date: Mon, 11 Feb 2013 10:58:13 +0100 Subject: [UML] Serilaization of required stereotypes Thread-Topic: [UML] Serilaization of required stereotypes Thread-Index: Ac4IPk5TIUTtNfLgReaK3hHd6XHS4A== Accept-Language: fr-FR, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Hi Juergen, Would you create an issue with the following content, please? Kind: Clarification. Issue description: There are some specific cases where serialization of Extension instances resulting from the application of a stereotype does not provide any added value. However it creates a memory footprint overhead. These cases can be characterized by the conjunction of the following conditions: The stereotype is defined so that it is an required extension (i.e. its isRequired property is .true.) This stereotype does not have any property or all of its properties are derived (i.e. isDerived is .true.) As per the current specifications of UML and MOF2XMI, I cannot find anything that formally implies the serialization of extensions resulting from the application of such a stereotype but this reading appears to be controversial (cf. the attached mails exchange). Nevertheless, the standard way to add semantics in a profile relies on stereotypes definition only and there are some practical cases leading to defined stereotypes of the kind described above. For instance, within the SysML specification we defined a set of queries to retrieve elements involved in a specific kind of relationships (e.g. allocation), even if those elements do not themselves hold any information about it. Finally, those stereotypes are no more that a specification mechanism used to define a set of query applicable to a set of elements and the memory footprint overhead is not justified. Suggested resolution: To add a Boolean query (with maybe a corresponding derived property) to the Extension metaclass. This will return .true. when an extension shall be serialized. I propose to use the following OCL expression to specify this query: context Extension def: mustBeSerialized() : Boolean = self.isRequired=false or self.ownedEnd.type.attribute->select(isDerived)->notEmpty() To clarify that extensions that return .false. to the query above are aliases for their base classes in any context where the profile is applied. Therefore, any reference to an element typed by the corresponding stereotype shall actually be resolved (and then serialized) as a reference to the corresponding instance of the extended class. Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Received: from airbus-sf6.airbus.gmessaging.net (81.252.56.22) by webmail.airbus.com (44.225.0.151) with Microsoft SMTP Server id 8.3.279.5; Fri, 1 Feb 2013 17:13:47 +0100 Received: from airbus-pf4.airbus.gmessaging.net (localhost.localdomain [127.0.0.1]) by localhost.airbus.gmessaging.net (Postfix) with SMTP id E58591FC01F2 for ; Fri, 1 Feb 2013 17:13:16 +0100 (CET) Received: from ogate203.mailprotector.net (outbound124-2.mailprotector.net [208.83.76.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by airbus-pf4.airbus.gmessaging.net (Postfix) with ESMTPS id C62A7C70078 for ; Fri, 1 Feb 2013 17:13:15 +0100 (CET) Received: from outbound.mailprotector.net (unknown [10.1.50.225]) by ogate203.mailprotector.net (Postfix) with ESMTPS id 20EA67C006E; Fri, 1 Feb 2013 11:13:14 -0500 (EST) Received: from EXCH2K7CCR.VIRTUMEN.LOCAL ([10.1.50.227]) by VMDC1.VIRTUMEN.LOCAL ([10.1.50.225]) with mapi; Fri, 1 Feb 2013 11:13:14 -0500 From: Ed Seidewitz To: "BERNARD, Yves" CC: "sysml-rtf@omg.org" , "uml25-ftf@omg.org" Date: Fri, 1 Feb 2013 17:13:12 +0100 Subject: RE: [UML 2.5 FTF] About "required" stereotypes Thread-Topic: [UML 2.5 FTF] About "required" stereotypes Thread-Index: Ac3+8mKEcwxS3vmJTti4So4htbnPMAAFMzbAAAEcz3AAAGzogAAA3qjgABujoPAAE1wRQAADeavgAB177yAADXPH4AAAtwNwAAMaaAA= Message-ID: <10136_1359735196_510BE99C_10136_19700_1_AAEBB9232BCBC1458C21E95FAB0DC2750149F457A781@EXCH2K7CCR.VIRTUMEN.LOCAL> References: <32256_1359648733_510A97DD_32256_9393_1_07CD06DC38007B439B2EFDF74F48514C6783C03AA8@DE0-MAILMBX-P03.res.airbus.corp> <23777_1359655057_510AB090_23777_796_1_674FC3679265A241ACB4BF58BA0EB3BE02A175AD@DHOST001-50.DEX001.intermedia.net> <17232_1359705029_510B73C5_17232_17478_1_07CD06DC38007B439B2EFDF74F48514C6783C03F32@DE0-MAILMBX-P03.res.airbus.corp> <8845_1359729020_510BD17B_8845_15417_1_AAEBB9232BCBC1458C21E95FAB0DC2750149F457A71D@EXCH2K7CCR.VIRTUMEN.LOCAL> <5735_1359734480_510BE6CF_5735_8864_1_07CD06DC38007B439B2EFDF74F48514C6783C6327B@DE0-MAILMBX-P03.res.airbus.corp> In-Reply-To: <5735_1359734480_510BE6CF_5735_8864_1_07CD06DC38007B439B2EFDF74F48514C6783C6327B@DE0-MAILMBX-P03.res.airbus.corp> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: de0-mailhub-p05.res.airbus.corp X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-pmx-version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.1.160033 x-perlmx-spam: Gauge=IIIIIIIII, Probability=9%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODY_SIZE_10000_PLUS 0, DATE_TZ_NA 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_NOT_1 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS ' x-perlmx-sil: Medium Content-Type: multipart/alternative; boundary="_000_101361359735196510BE99C10136197001AAEBB9232BCBC1458C21E_" MIME-Version: 1.0 Yves . Huh?? There are many attributes in the UML specification that are marked as derived. These are exactly (and only) the information that is not serialized in UML XMI. This has been thoroughly discussed in the MIWG over the last few years, and is not a point of contention. As Pete noted, the XMI specification does not say anything about stereotype application. The serialization of stereotype application in terms of an .equivalent MOF model. is specified only for UML, in subclause 18.3.7 of the UML 2.4.1 spec (12.3.3 in UML 2.5). This subclause says .An instance of a Stereotype (created when the Stereotype is applied to an Element) maps to an instance of the CMOF class representing the Stereotype. It is associated with the Element to which it applies using a Link which is an instance of the Association to which the Extension is mapped.. And that is how it is serialized . there is no exception given for any special case of required stereotypes of any sort. The benefits of what you propose are unfortunately not relevant to what the spec does or does not currently allow. The fact that there has been an extended discussion of this means that what may be .clear. to you is not clear to others. So, I repeat, if you want the benefits are claim for what you propose, you need to submit an issue. I will defer any further comment on this until such time as this issue is submitted and taken up for discussion by the FTF. -- Ed From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, February 01, 2013 11:01 AM To: Ed Seidewitz Cc: sysml-rtf@omg.org; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] About "required" stereotypes Ed, You say: .It has always been the case that only attributes explicitly marked as derived are considered derived for the purposes of XMI serialization.. Except if I missed something, there is no such an explicit directive in the UML specification. In other words, extending this rule to other kinds of derived information cannot formally be considered an unconformity to either UML or MOF2XMI specifications. So, if you think it should be, please raise an issue that it can be discussed. ;o) You said that .the issue is exactly how to determine what the specific case is. but you did not explain why an OCL expression like the one I propose could not work. As currently stated in the UML specification, the sentence you quoted about the required stereotype (.a required stereotype means..) applies to the UML model itself and not to its serialization (§12.3.3 is about semantics not serialization). Considering that: · As per explicitly specified by the UML specification the rules for serialization of UML model in XMI file are given by the MOF2XMI specification (cf. reference in my previous mail) · The MOF2XMI specification clearly states that the serialization of derived information is optional (cf. reference in my previous mail) · Nowhere in the MOF2XMI specification a reference is made to the UML specification to defined what .derived information. means · The spirit of the serialization policy, which is recalled number of times both in the MOF2XMI and in the MOF specs is, in substance: .serialize only what is strictly necessary, avoid duplication. To me we do not need any modification in the UML specification and honestly, I would say that the benefits of modifying the UML specification to forbid my interpretation of the spec are not clear to me. Yves From: Ed Seidewitz [mailto:ed-s@modeldriven.com] Sent: vendredi 1 fĂ©ier 2013 15:30 To: BERNARD, Yves Cc: sysml-rtf@omg.org; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] About "required" stereotypes Yves . Whether it makes sense or not, the application of a required stereotype is simply not defined as .derived information. in the UML spec. It has always been the case that only attributes explicitly marked as derived are considered derived for the purposes of XMI serialization. The situation for stereotype applications is somewhat muddled by the fact that there is no UML abstract syntax metamodel for stereotype application, the semantics being defined instead in terms of an equivalent MOF model. However, it says pretty clearly in subclause 18.3.2 of the UML 2.4.1 spec (and, similarly, in subclause 12.3.3 of the UML 2.5 spec) that .A required extension means that an instance of a stereotype must always be linked to an instance of the extended metaclass.. There is nothing said about this being .derived. in some particular cases. Rather, .the model is not well-formed. if the stereotypes are applied properly . that is, it is a well-formedness rule on stereotype applications that exist in the model. It is thus quite clear to me that the UML and XMI spec currently do not support what you want. And, as Pete notes, there is no way to generically determine, in terms of the XMI spec, that, in some cases, the stereotype application may be effectively .derived., while in other cases it cannot. The whole issue here is, in fact, that are discussing .not about required stereotypes .in general. but about a required stereotype [in a specific case]. . the issue is exactly how to determine what the specific case is. And since profiles and stereotypes are defined only in the UML spec, not the MOF or XMI specs, this is a matter that would need to be addressed explicitly and carefully in the UML spec . which it currently is not. If you think it should be, then, as I have said before, submit a UML issue on it and we can continue this discussion at the appropriate time on that issue. -- Ed From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, February 01, 2013 2:50 AM To: Pete Rivett Cc: sysml-rtf@omg.org; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] About "required" stereotypes Pete, Please, keep in mind that what we discussing not about required stereotypes .in general. but about a required stereotype which cannot hold any information specific to its instances (i.e. have no attribute except derived ones, cf. the OCL expression in my previous mail). Saving a model that would not have such a stereotype applied on the element on which it is required has absolutely no interest and does not make sense (cf. the UML definition of the isRequired semantics) All the instances of such a stereotype existing in a model are derived information, depending of the application of the profile only. The MOF to XMI specification, which specified as the reference of the UML models serialization by UML 2.5 (cf. Annexe E), states the following (p21): .7.8.10 Derived Information Whether or not information is derived information is orthogonal to whether or not that information is serialized. The org.omg.xmi.serialize tag is provided optionally to include derived data. This capability provides more control to the metamodelers, allowing them to customize exactly which information is present in their files. In some cases, derived information may be more condensed than the information it is derived from. In these cases, serialization of only the derived information may be desirable to keep the size of the XMI file as small as possible.. Therefore it is clear to me that if MOF2XMI indeed allows and provide facilities for serialization of derived information, it does not make it mandatory. Yves From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: jeudi 31 janvier 2013 18:58 To: BERNARD, Yves; sysml-rtf@omg.org Subject: RE: [UML 2.5 FTF] About "required" stereotypes I don.t follow your point about transient situations . to be able to save a partial (albeit invalid) model it must surely be possible to distinguish an element without an isRequired stereotype applied. Another point I didn.t mention is that XMI is generically defined at the MOF level and has no knowledge at all of Stereotypes or Profiles. Making the XMI serialization rules dependent on Profiles (which are only part of UML, not MOF) as you suggest would be a major change to XMI that could not, IMO, be achieved via RTF. Finally I disagree with you about the impact . the extra storage is minor compared with the size of XMI files generally, especially if Canonical XMI is used. Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Thursday, January 31, 2013 8:12 AM To: Sysml-Rtf (sysml-rtf@omg.org) Subject: FW: [UML 2.5 FTF] About "required" stereotypes For information, following our discussion today during the RTF online SysML. From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: jeudi 31 janvier 2013 08:47 To: Pete Rivett; Rouquette, Nicolas F (313K); uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] About "required" stereotypes Pete, I do not think that specifying these rules would be that difficult. The point is that we need to serialize the minimum to ensure that no information is lost but no more. For the case we are discussing, I think that the rule would be relatively simple to write. I am not an OCL specialist but I guess we could use something like this: context Extension def: mustBeSerialized() : Boolean = self.isRequired=false or self.ownedEnd.type.attribute->select(isDerived)->notEmpty() I agree that, in the absolute, we may need to be able to have an .invalid model. at some point but it is always linked to transient situations, related to updates of the model and where we can accept existing rules to be relaxed precisely because we can master both their duration and recovery. Nevertheless, any industrial exploitation of a model implies it is valid. Considering the effort and the cost spent in verification and validation activities in our development process, it makes sense trying to get things correct .by construction. wherever possible. Since the duplication of information requires more resources for storage and synchronization and more verification effort, it makes sense to avoid it, except if its benefits can justify its costs. Yves From: Pete Rivett [mailto:pete.rivett@adaptive.com] Sent: mercredi 30 janvier 2013 18:50 To: Rouquette, Nicolas F (313K); BERNARD, Yves; uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] About "required" stereotypes My answer was based on the current spec, which you helpfully quoted. I was not making a justification as to why it.s a good idea. But making the change would be quite significant and it would be hard I think to frame the rules for when to omit them. And I cannot see much justification for the change - having the stereotype instances does not seem that burdensome. And it makes life a lot easier for an importing tool. And for an OCL engine to validate certain constraints which might be associated with the stereotype (presumably you.d expect the tool to work out if the stereotype is required and act as if it were actually present?). Likewise QVT. Further, I believe that isRequired is only effected at the instant the profile is applied: subsequent creation of elements would presumably need the explicit stereotype instances? And isRequired does not I believe stop someone removing the stereotype: it would become an invalid model but there are lots of ways we (deliberately) allow people to create (incomplete/partial) models that are not valid with respect to all UML constraints. Pete From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Wednesday, January 30, 2013 9:15 AM To: Pete Rivett; BERNARD, Yves; uml25-ftf@omg.org Subject: Re: [UML 2.5 FTF] About "required" stereotypes Pete, Can you explain your reasoning for a stereotype S with isRequired=true, particularly if that S only has derived attributes (if any) ? The spec says: | When a Profile is applied, instances of the appropriate Stereotypes must be created for those elements that are instances of metaclasses with ExtensionEnds which have isRequired = true. The model is not well-formed without these instances. In the case above, there is nothing inherently useful in serializing the instances of S. At best, serialization should be optional in that case; better would be to exclude its serialization altogether. · Nicolas. From: Pete Adaptive Date: Wednesday, January 30, 2013 9:05 AM To: "BERNARD, Yves" , "uml25-ftf@omg.org" Subject: RE: [UML 2.5 FTF] About "required" stereotypes No it is not acceptable in any case: if the Stereotype is applied (even if via isRequired) the stereotype instance (I assume that is what you meant by .extension instances.) must be serialized. Pete From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Wednesday, January 30, 2013 8:34 AM To: uml25-ftf@omg.org Subject: RE: [UML 2.5 FTF] About "required" stereotypes Sorry it appears I attached the wrong messages exchange. Here is the right one. From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: mercredi 30 janvier 2013 15:02 To: uml25-ftf@omg.org Subject: [UML 2.5 FTF] About "required" stereotypes Question: Assuming there is one UML profile .P. defining a stereotype .S. which extends a metaclass .M. so that the isRequired() query of the extension definition returns .true.. Is it acceptable to NOT serialize the extension instances corresponding to this stereotype for the model where this profile .P. is applied in the following cases: a. The definition of S does not specify any feature or rules? b. The definition of S specifies only a set of queries? c. The definition of S specifies only a set of rules? d. The definition of S specifies only a set of derived attributes? Thanks, Yves P.S.: in attachment is the mails exchange we had within the SysML RTF which motivates this question. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.