Issue 12473: Section: A.2.5.8 Sequence Operations (ocl2-rtf) Source: (, ) Nature: Revision Severity: Minor Summary: There is one error in Table A.6 in the semantics column for the operation "first". The index should be 1, not i. Resolution: Revised Text: In Table A.6, in the semantics column for the operation first, replace the index so that it is 1 instead of i. Actions taken: May 14, 2008: received issue October 16, 2009: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 14 May 2008 14:15:33 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Garr Lystad Company: Net.Orange (i.e. Net Dot Orange) mailFrom: glystad@ndorange.com Notification: Yes Specification: Object Constraint Language Section: A.2.5.8 Sequence Operations FormalNumber: n/a Version: 2.0 RevisionDate: 1 May 2006 Page: 197 Nature: Revision Severity: Minor HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 Description There is one error in Table A.6 in the semantics column for the operation "first". The index should be 1, not i. Date: Thu, 15 May 2008 10:49:38 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: Burkhart Roger M Cc: sysml-rtf@omg.org Subject: Re: (relates to 10473) ! A UML2.1.2 Slot may optionally show other properties of the feature, such as its type: and consequences for SysML IBD compartments X-Virus-Scanned: ClamAV 0.91.2/7124/Thu May 15 04:11:00 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-98.1 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, MIME_HTML_ONLY,RCVD_IN_PBL,RDNS_NONE,USER_IN_WHITELIST autolearn=no version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.nomagicasia.com Burkhart Roger M wrote: I had overlooked the option of ": Type" in UML slot value notation, so I'll add this to the resolution for 10473 to go with its reference to elements of UML InstanceSpecification notation. --Roger Many Thanks, Darren -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! Date: Thu, 15 May 2008 21:53:21 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: Burkhart Roger M , "sysml-rtf@omg.org" Subject: Ballot 4: 10473_resolved: instance specifications for default values' SUGGEST idea: qualify 'initial values' compartment name with name of Block that "manages and assigns" the "initial values" X-Virus-Scanned: ClamAV 0.91.2/7128/Thu May 15 17:45:41 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-98.1 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, MIME_HTML_ONLY,RCVD_IN_PBL,RDNS_NONE,USER_IN_WHITELIST autolearn=no version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.nomagicasia.com Hi Roger, Just stub email to record spirit of the idea. This suggestion might meet both of our requirements and expectations for an "initial values" compartment. It would enable the current MD SysML approach to be used in combination with what you seem to want to achieve. (1) In the case where the "initial values" are UML-style property-specific initial values from Property.defaultValue (as "vector") one has the usual "initial values" compartment (formerly SysML1.0 defaultValue), as illustrated already in my MD SysML diagrams. If the same Property appears twice in an IBD at different paths, because it's owning Block type is used in different parts, then the initial values stay displayed the same; there is in this case no additional configuration context, and no special indicator. (2) In the case where path-specific "initial values" are assigned from a context higher than the immediate owner of the Property at the end of the path, one could qualify the name of the "initial values" compartment with an indicator of the assigning context. Something like: (we can play with the specific notation): ContextBlock."initial values" Where ContextBlock need not be the very highest context, it could be any intermediate higher context. This is very flexible. It would enable one to mix and match different levels of configurations with a clear indication of which Block "manages" the configuration. Also, one need not then only have the initial values assigned by the very top-level context Block (one would not need to rely on the IBD frame name indicator), nor on one single context Block. It also enable mapping of many partial instance trees rooted at the Property.defaultValue for a given property typed by a Branch. This would thus promote reuse of a wide range of partial configurations, mapped to property paths. It also avoids confusion concerning people interpreting a Property symbol at a given path within an IBD with a Property (which may in fact appear many times in one IBD at different path ends). Motto: it's the small annoying piece of grit in the oyster that makes the pearl. -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! X-WSS-ID: 0K0WTQL-05-30O-01 Subject: RE: URGENT: Ballot 4: 10473_resolved: instance specifications for default values: rejection of proposed resolution by No Magic and justification by example Date: Thu, 15 May 2008 07:37:33 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URGENT: Ballot 4: 10473_resolved: instance specifications for default values: rejection of proposed resolution by No Magic and justification by example Thread-Index: Aci2LLBbLIlS7/NFQ8y4Nx8JhWllewAVna+Q From: Burkhart Roger M To: "Darren R C KELLY" Cc: , "Nerijus Jankevicius" , "Rattanawan Rattakul" , "Andrius Strazdauskas" , "Friedenthal, Sanford" X-OriginalArrivalTime: 15 May 2008 12:37:38.0522 (UTC) FILETIME=[759EFBA0:01C8B688] Darren-- Just below your message below I have attached an entire message thread from just before the Washington, D.C. meeting, which was initiated by a proposal from Nerijus for a metamodel extension that could support path-specific values on a Configuration stereotype of Block. While we ended up relying on a tree of UML InstanceValue elements with selected slots filled in to provide a metamodel representation, rather than a propertyPath attribute as in Nerijus's proposal, this earlier discussion had already set the stage for understanding a "defaultValues" compartment (renamed as appropriate) as a holder of path-specific values. This understanding is also entirely consistent with the entire history of this compartment, going back to the original submission discussions, extending through the current spec which suggested that these values would require a property-specific type, and continuing through this new resolution which unloads the need for property-specific types to carry context-specific values, which is a key goal that we've all been after. As I stated in my message you're replying to below, by its placement on properties within an ibd, the defaultValue (renamed initialValues) compartment inherently displays information specific to a individual property context, at whatever level of nesting that a particular property is displayed. You can still specify the original, immutable property-specific default values on a property owned by a block on its own block definition. Nothing specified within some other containing block context on an ibd will ever replace that original property-specific value. The new context-specific value is owned by the containing block that references some existing definition through one of its properties, and does not change anything in the definition of the block or value type that types a property. --Roger -------------------------------------------------------------------------------- From: Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Sent: Wednesday, May 14, 2008 8:41 PM To: Burkhart Roger M Cc: sysml-rtf@omg.org; Nerijus Jankevicius; Rattanawan Rattakul; Andrius Strazdauskas; Friedenthal, Sanford Subject: Re: URGENT: Ballot 4: 10473_resolved: instance specifications for default values: rejection of proposed resolution by No Magic and justification by example Hi Roger, Burkhart Roger M wrote: The actual scope of this resolution is just to rename the former "defaultValue" compartment to "initialValues" which has been done (although I have recommended 'initial values') .. and to state how any values specified in this compartment are stored in the metamodel. The resolution offers a very specific interpretation of the 'initialValues' compartment, one quite at odds with the definition of the UML2 Property.defaultValue (after which the compartment was originally named) and the related description: '7.3.44 Property (from Kernel, AssociationClasses) If there is a default specified for a property, this default is evaluated when an instance of the property is created in the absence of a specific setting for the property or a constraint in the model that requires the property to have a specific value. The evaluated default then becomes the initial value (or values) of the property.' And it enables the defaultValue/initialValue compartment to be used for two very separate things: Property-specific initial values: for "progressive" initialisation of a part using only the Property.defaultValue "managed" by its owning block Path-specific values: for deep initialisation of the entire system in an additional context (including re-initialisation of an entire system usage), completely overriding the meaning of "initial values" above, and exactly as I have many times advised against. !!! This makes it impossible to display BOTH property-specific initial values (which are immutable) and path-specific values (which are subject to an additional value context) at the same time in one IBD !!! That much scope we had all agreed upon at the Washington meeting. It was not agreed that the 'initial values' compartment should confusingly be used for the second (separate) purpose of path-specific values. Already there is the feature-level 'values->:values' compartment using the [PropertySpecificType] "trick", and I have separately suggested and additional "instance values" compartment specifically for the purpose of assigning path-specific values in an additional values context, and I have demonstrated it most exactly here recently. I was assigned the task of resolving just this much scope, regardless of how any of the other issues on instance specifications or other value compartments might eventually be resolved. But you didn't; you added in most controversial aspects. Darren wrote: In fact the resolution as it stands suggests exactly what I have advised against, and what our tool does not support under the compartment initial values: Initial value compartments may be specified within nested properties, which then apply only in the particular usage context defined by the outermost containing block. Such "initial values" as proposed are then precisely NOT property-specific initial values; they are "context specific initial values", where the context is a higher context, higher than the owner of a structured Property for which values are indicated. They might well be named "path-specific initial values" (where the path is deep). Roger wrote: SysML badly needs a fix to its current specification of the defaultValue compartment, since it didn't specify a metamodel and incorrectly stated that property-specific types were required to use it. Agreed. This should not be used as an opportunity to introduce dual and confusing meanings to a single IBD compartment, which is exactly what the resolution does; my advice and demonstrations on the matter have not been sufficiently examined. Note that I have already have ample experience attempting to explain and teach the quite subtle IBD compartments, one of which - the feature-based values->:values - I also originally misundertood; we don't need more confusion. Because this compartment appears on the properties on an ibd, the values are inherently specific to a block context. That is not at all clear; I have advised that most users expect to see exactly the same thing in property compartments, whether they appear in their own IBD or nested in another, and this is true already of the feature-based values compartment (except when the ProperySpecificType is used to evoke the impression that the values are specific to the top-level context). My suggested instance values (could be otherwise named) compartment for path-specific values (subject to a context) would ONLY BE AVAILABLE IN AN ADDITIONAL VALUE CONTEXT, whereas the 'initial values' compartment should always available even if there is only one single context (RootAssembly with leaf:Leaf), and that is the whole point. This was pointed out by me many times, and I have shown (live) examples from our tool; what you have proposed is exactly the opposite of what I have demonstrated running: Your proposed resolution admits the possibility that the initial values compartments here could show different "path-specific" values for the same property t:Type on different symbols. instead of the Property.defaultValue "manged" by the immediate _single_ Property owner. My advice and my clear live demonstration at Washington DC OMG TM has been at best misunderstood. We're only renaming the compartment. No you aren't; you are completely changing the semantics of it and the metamodel for it. Any other change to its current definition would be out of scope of this specific resolution. We've all agreed that increased support for value specifications of all kinds is an important priority for future consideration, and we retain the existing open issues (as well as any others that may be raised) under which such support can be considered. With this explanation, I hope you'll support the limited scope of the proposed 10473 resolution .. I am most appreciative of your detailed response and I feel I understand what you want to achieve through our resolution, however I can't accept it either from a modelling perspective (and I am very experienced systems modeller) nor on behalf of the tool vendor No Magic Inc and the MD SysML Plugin development effor, for whom this proposal represents a massive and possibly very expensive change, as well as requiring reeducating customers, and changing large amounts of training materials. Yours by Default, Progressively Initialised, then Systematically (and most deeply) configured, Darren 2008-05-15 RMB Here is a message thread from just before the Washington, D.C. meeting, discussing a proposal for path-specific values within a Configuration stereotype of Block, as made by Nerijus Jankevicius. --Roger -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, March 05, 2008 12:06 PM To: Alan Moore; Friedenthal, Sanford; sysml-rtf@omg.org Subject: Re: new Property Specific Types metamodel I'm not against the same "values" compartment. BTW, should we use "defaultValues" or "defaultValue" compartment name for default values? As I understand, it could be many values, so maybe "defaultValues" should be used to be consistent with "values". The question is do we need to show something on type? I mean should we remove brackets used for PropertySpecificType? I would like to remove this notation. Nerijus ----- Original Message ----- From: Alan Moore To: Friedenthal, Sanford ; Nerijus Jankevicius ; sysml-rtf@omg.org Sent: Wednesday, March 05, 2008 7:32 PM Subject: RE: new Property Specific Types metamodel Nerijus, Have you given any thought to the notation for this new construct on the ibd? Alan. -------------------------------------------------------------------------------- From: Friedenthal, Sanford [mailto:sanford.friedenthal@lmco.com] Sent: Tuesday, March 04, 2008 4:30 PM To: Nerijus Jankevicius; sysml-rtf@omg.org Subject: RE: new Property Specific Types metamodel Nerijus I find your proposal very intriguing with a lot of promise. This proposal addresses the following problem. If I change the type of wheel diameter on my car, I end up have to specify a whole new car since this change propagates up the entire assembly tree. This issue has always bothered me. Instance specifications and property specific types do not address this issue, since as Roger says, we need the ability to define different default values in different contexts. In the example above, we need a different default value for wheel in each context of car. Your proposal addresses this issue by defining a <> stereotype that is a container for all the redefined properties. All one has to do to specify a new configuration is to apply this stereotype and include the list of properties and their values that are redefined. Pretty interesting. A couple of comments regarding your specific proposal. a) In the .sample problem model using new metamodel. towards the bottom of this page, can you show the BigCarConfiguration. owned by Hybrid SUV directly b) Can you change to stereotype names so they start with lower case c) The major item is to consider if the configuration stereotype can include other features of the blocks beyond properties, such as operations, constraints, ports, etc that are unique to the local context. d) Can a configuration include nested configurations as you suggested on the call? For example, the big car configuration could include a wheel configuration its list of redefined properties. e) Clarify whether this would replace property specific type or augment it I look forward to careful examination of this proposal by the rest of the team. This could potentially address a major issue, as described by the problem statement. Sandy Sanford Friedenthal Lockheed Martin (703) 293-5557 -------------------------------------------------------------------------------- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Tuesday, March 04, 2008 9:13 AM To: sysml-rtf@omg.org Subject: new Property Specific Types metamodel Proposed Property Specific Types problem solution Example based on HSUV model Task description: Make new Car with different wheel size. Required supporting model using current PropertySpecificType approach: Steps: Create new Block Add Generalization to .redefined. Block name it as .redefined. block, but surrounded with .[]. it should be owned by context block (where property of such type is defined) create new property in the context block add reference to .redefined property. set property specific type as type of such redefined property if it is still not required property which value should be redefined, go to step1 redefine value, as .default value. of the property Cons of current metamodel: Whole system must be redefined to reach deep nested property multiple COPIES of system must be supported and maintained automatically there is no way to have several configurations for the same system/block New suggested metamodel Configuration should be owned in redefinition context. Configuration must own all redefined properties directly, as ownedAttributes. Every RedefinedProperty must hold property path to exact redefined property in the context of this internal structure (the same mechanism as used in NestedConnectorEnd) Sample problem model using new metamodel: Steps: 1.Create Configuration element owned in redefinition context 2. Create RedefinedProperty for Configuration Set property path from redefinition context to exact redefined deep nested proper Pros: very compact and clear model all redefined properties are at the same level, in one list names of redefined properties can be .user friendly., changed in redefinition context (e.g. wheelSize instead of .diameter. as many diameters are used in whole system) many configuration could be created and reused.