Issue 19468: Semantics of static features (uml2-rtf) Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com) Nature: Clarification Severity: Summary: “In §9.4.3, the following sentence: “The isStatic property specifies whether the characteristic relates to the Classifier’s instances considered individually (isStatic=false), or to the Classifier itself (isStatic=true)” may suggest that a static feature cannot relates to the instances of this classifier. This does not seem to be the intent. If so, improve the sentence. Otherwise explain how the semantics of a property which have the same value for all the instances of a classifier shall be modeled.” Resolution: Revised Text: Actions taken: June 12, 2014: received issue Discussion: End of Annotations:===== m: "BERNARD, Yves" To: Ed Seidewitz , Juergen Boldt CC: "uml2-rtf@omg.org" Date: Thu, 12 Jun 2014 08:23:13 +0200 Subject: RE: About "static" properties Thread-Topic: About "static" properties Thread-Index: Ac+EwWsD4V1YIOA8TSKg5IebvJa5rwABWfv1AAJCPwAAAgBLIP//9USAgAAQouD///OfgIAAEK1Q///z8oD//zmPUP/+ZRyg//zJysD/+Y2LkP/yPNgA/+R2dwD/yOZhgP+RNRDA Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-Virus-Scanned: amavisd-new at omg.org Ed, Juergen, I think that, at least, a clarification is required. According to Steve, it’s not that clear that the required semantics is a new feature. In addition this is very important for us. Thus, I suggest creating an issue with the following title: “Semantics of static features” and the following description: “In §9.4.3, the following sentence: “The isStatic property specifies whether the characteristic relates to the Classifier’s instances considered individually (isStatic=false), or to the Classifier itself (isStatic=true)” may suggest that a static feature cannot relates to the instances of this classifier. This does not seem to be the intent. If so, improve the sentence. Otherwise explain how the semantics of a property which have the same value for all the instances of a classifier shall be modeled.” Thanks, Yves De : Ed Seidewitz [mailto:eseidewitz@ivarjacobson.com] EnvoyĂ© : mercredi 11 juin 2014 22:02 Ă€ : Juergen Boldt Cc : uml2-rtf@omg.org Objet : Re: About "static" properties I do not believe there is really any issue here on static properties. Yves may or may not have an issue about UML lacking a specific modeling capability, but that would essentially be a new feature request, which I don’t think has been well articulated yet. From: Juergen Boldt Date: Wednesday, June 11, 2014 at 11:38 AM To: Michael Chonoles , Tim Weilkiens , Yves BERNARD , Ed Seidewitz , Conrad Bock Cc: "uml2-rtf@omg.org" Subject: RE: About "static" properties still 'just' discussion or an issue? -Juergen At 11:27 AM 6/11/2014, Michael Chonoles wrote: Tim Unfortunately, that doesn't quite work that way. You are being misled by the word "static". A static property is not unchangeable. A static property is effectively the same value for all instances (it is a software language mechanism decision whether this is done with a property at the class level or somehow synched copies at the instance level). Nothing prevents the static property being changed. Adding "isReadOnly" would be overly restrictive -- and, in general, not be useful. A typical Static property, in my usage, is a count of the number of instances made of this class. As the class makes new instances it increments it. As an instance is destroyed, it decrements the count. When it hits zero, special memory handling can be invoked. Another type of isStatic property is commonly used property for an instance. Imagine a Class of interest bearing bank accounts. When the interest for the Class is changed, all instance of the Class get the changed interest rate. Michael -----Original Message----- From: Tim Weilkiens [ mailto:Tim.Weilkiens@oose.de] Sent: Wednesday, June 11, 2014 3:13 AM To: BERNARD, Yves; Ed Seidewitz; Bock, Conrad Cc: uml2-rtf@omg.org Subject: RE: About "static" properties Hi Yves, if you want "them to be the same for any instance of the product" I would set the property isReadOnly=true and define a default value. Then the value is the same for any instance and can't be changed. Tim -----Original Message----- From: BERNARD, Yves [ mailto:Yves.Bernard@airbus.com] Sent: Wednesday, June 11, 2014 9:09 AM To: Tim Weilkiens; Ed Seidewitz; Bock, Conrad Cc: uml2-rtf@omg.org Subject: RE: About "static" properties Hi Tim, A significant part of our specifications are made of values we want to enforce for some characteristics. That is: we want them to be the same for any instance of the product, i.e. they are "of the class" in the sense where they applied to any instance of that class rather than they characterize the classifier itself, e.g. like its name. A practical example could be the specification of the characteristics of a power supply module you want to include in your system (delivered power, voltage, frequency ...). Yves >-----Message d'origine----- >De : Tim Weilkiens [ mailto:Tim.Weilkiens@oose.de] Envoyďż˝ : mercredi 11 >juin 2014 08:50 ďż˝ : BERNARD, Yves; Ed Seidewitz; Bock, Conrad Cc : >uml2-rtf@omg.org Objet : RE: About "static" properties > >Yves, > >By now I've never used static features for system modeling. Do you have >a good use case for that? Or is isStatic superfluous for SysML? > >Tim > > >-----Original Message----- >From: BERNARD, Yves [ mailto:Yves.Bernard@airbus.com] >Sent: Wednesday, June 11, 2014 8:36 AM >To: Ed Seidewitz; Bock, Conrad >Cc: uml2-rtf@omg.org >Subject: RE: About "static" properties > >Ed, > >The principle of MBSE approaches is to use models as first class >artifacts for supporting the engineering activities. This includes system specification. > >Assuming the model of a system is used as a specification, we would >define the class features in order to describe the characteristics of >the system to be developed. > >So, any feature added to that class restricts the solution space. > >Assume a property "color" for this class that we intend to use to >specify the color of our system and assume we specify it as "static". Does it: > >1. Enforce any instance of the class to have the same value for this >property and then to have the same color? >or >2. Have no impact on the system specification since this attribute >actually characterizes the classifier and not its instances? > > >Thanks, > >Yves > >>-----Message d'origine----- >>De : Ed Seidewitz [ mailto:eseidewitz@ivarjacobson.com] >>Envoyďż˝ : mardi 10 juin 2014 19:08 >>ďż˝ : Bock, Conrad >>Cc : uml2-rtf@omg.org >>Objet : Re: About "static" properties >> >>Conrad < >> >>So, what is your point? >> >>The original question was on the UML semantics of isStatic. My point >>is that I donďż˝t think the point you are making (as I understand it) is >>relevant to UML semantics. As such, I donďż˝t think it is particularly >>important for the RTF to consider. >> >>< Ed >> >>On 6/10/14, 12:55 PM, "Bock, Conrad" wrote: >> >>>Ed, >>> >>> > Sure, instead of representing the value of a static feature using >>> > some sort of meta-object, you could define a semantic >>> > representation in >>>which >>> > each instance actually has values for the static feature. >>> >>>The above is implementation, not semantics, see below. >>> >>> > fUML doesn't include static features, so we have never really >>> > dealt >>>with >>> > this issue formally. >>> >>>You keep getting distracted by things other than the point. Reread >>>the message, substituting the term "conformance" for whatever term >>>you prefer for M0 instances that can be specified by a given classifier. >>>If still isn't clear, we can go over it whenever the RTF calls start >>>up if it's considering important enough. >>> >>>Conrad >>> >>>-----Original Message----- >>>From: Bock, Conrad >>>Sent: Tuesday, June 10, 2014 12:24 PM >>>To: uml2-rtf@omg.org >>>Subject: RE: About "static" properties >>> >>>Ed, >>> >>> > I agree with Tim - I don't see any conflict with the UML >>> > definition >>>of a > static feature and C++ or Java. A property that "has the >>>same value for > any instance of the classifier" is pretty much the >>>same thing as a > "property of the classifier", since the value of >>>the property is not > related in any way to a particular instance. >>> >>>It changes which instances conform to the classifier (ie, the semantics). >>>Static properties in UML 2.5 place no restriction on which instances >>>conform, whereas having the same value for every instance obviously >>would. >>> >>>My reconstruction of the reasoning in UML 2.5 is that you don't need >>>static properties to have the same value for a property on every >>>instance (just use initial values on read-only properties), whereas >>>to specify properties of classifiers themselves (like authors of the >>>classifier, last modified date, etc) requires them. >>> >>>Conrad >> >> >>This mail has originated outside your organization, either from an >>external partner or the Global Internet. >>Keep this in mind if you answer this message. >> > > >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. > > >This mail has originated outside your organization, either from an >external partner or the Global Internet. >Keep this in mind if you answer this message. > 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. Juergen Boldt Director, Member Services 109 Highland Ave Needham, MA 02494 USA Tel: +1 (781) 444 0404 x 132 fax: +1 (781) 444 0320 www.omg.org [] 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. X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=ZOVZmBLb c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=9cW_t1CCXrUA:10 a=WLhMWes79ycA:10 a=IkcTkHD0fZMA:10 a=YYzpnO7rAAAA:8 a=5DqnjfGMAAAA:8 a=KHpXyVWLAAAA:8 a=CjxXgO3LAAAA:8 a=97WRd6UGAAAA:8 a=oCcaPWc0AAAA:8 a=5yyx5hz1xLVw-snglU4A:9 a=_XKz4dfSi6teANhE:21 a=jtK7SBF0UY9ZOpJw:21 a=joiuKQ3rC1RweXdF:21 a=QEXdDO2ut3YA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=c9tJgGcuwpQA:10 a=ngL6kCF7wasA:10 a=WP4_USCxRkkA:10 a=rC2wZJ5BpNYA:10 a=DLrAvYGtb7wA:10 a=VWtqRZUfChcA:10 Date: Thu, 12 Jun 2014 07:54:32 +0100 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 CC: "uml2-rtf@omg.org" Subject: Re: About "static" properties X-Virus-Scanned: amavisd-new at omg.org Hi I think 9.4.3 as highlighted by Steve is good. A static feature relates to the Classifier not its instances. If a static feature relates to the classifier, it seems obvious that it has the same value for each of its instances. It does not say that a static feature is realized per-instance, and while it doesn't specifically prohibit realization per-instance, that seems to be a perfectly reasonable loophole for alternative implementations. Imagine a hardware architecture with a very fine-grained MMU that allowed me to create a coherent object from many disparate memory locations. In this architecture the one shared Classifier static variable could indeed appear as part of each of its instances and could even vary depending on the execution context/thread. To me the problem is in 9.5.3, where the topic of isStatic is re-addressed without precision. Just adding a "(see 9.4.3)" to the end of the third paragraph in 9.5.3 seems enough. It would also be helpful to add further headings in 9.4.3 such as "isStatic", "isReadonly". But this a general editorial issue that could be applied throughout to break up long descriptions into smaller topical sections more amenable to discovery by skim reading. Regards Ed Willink