Community
Participate
Working Groups
Build Identifier: 20100617-1415 Papyrus : 0.7.3.v201104270854 One shall be able to specify an initial value specific to a particular instance usage. One shall be able to reproduce IBD of table 8.3, page 35 of the SysML 1.2 specification. See Section 8.3.1.2, “Internal Block Diagram,” subsection “Initial value compartments.” """A compartment with a label of “initialValues” may be used to show values of properties belonging to a containing block. These values override any default values that may have been previously specified on these properties on their originally defining block. Initial value compartments may be specified within nested properties, which then apply only in the particular usage context defined by the outermost containing block.""" Reproducible: Always Steps to Reproduce: 1. create two Block Block1 and Block2 2. create a Property on Block2 say x:Integer 3. create a composite association from Block1 to Block2 4. create an IBD on Block1 5. add block2 part on IBD 6. Here initialValues compartment shall be visible to set an initial value for x.
According to the SysML specification, nothing is defined constraining x to have an initial value.
Sorry, I went to fast. It should be implemented in Papyrus. I reclassify the task as an enhancement.
reopen.
(In reply to comment #3) > reopen. Hi, I wonder what the exact scope of this bug is. Does it only include the creation of the initialValues compartment, or also the necessary infrastructure for easily creating the instance specifications that are used as initialValues. For instance, the specification describes quite constraints about this topic. <quote> If a property belonging to a block has a specification of initial values for any of the properties belonging to its type, then the default value of that property must be a UML InstanceValue element. This element must reference a UML InstanceSpecification element created to hold the initial values of the individual properties within its usage context. The instance specification must be unnamed and owned by the same package that owns the outermost containing block for which the initial values are being specified. Selected slots of the referenced instance specification must contain value specifications for the individual property values specified in a corresponding initialValues compartment. If a value of a property is shown by a nested property box with its own initialValues compartment, then the slot of the instance specification for the containing property must hold a new InstanceValue element. Selected slots of the instance specification referenced by this value must contain value specifications for any nested initial values, recursively through any number of levels of nesting. A tree of instance values referencing instance specifications, each of which may in turn hold slots carrying instance values, must exist until self- contained value specifications are reached at the leaf level. </quote> Does this bug include either: - The creation of the necessary validation rules to ensure these constraints are met, or - The creation of some wizards that _ensure_ these constraints are met Or are these parts of a different bug?
Created attachment 231087 [details] Model + IBD Mockup I've added - A papyrus model with the necessary "default values" set, by means of instance specifications. Apart from the fact that the instance specifications should be 'unnamed' according to the standard, I think the model is SysML compliant. It was created using the latest nightly build - A mockup of what the IBD could look like if Context Specific Values would be supported by Papyrus. Notes: - The creation of the instances is currently a very tedious job, but I guess that is stuff for another bug report I'm not sure what's the best way to implement this, but from a user perspective at least it seems like there are several options (assuming that the instances are created manually, I other use cases out of consideration right now) UC1: Automagic filling of the parts of a specific context. Assuming that the BDD is there, and the necessary instances are created, and the default values of attributes s1 and s2 are set. 1/ Create an IBD below Context. 2/ [opt] Right-click on the "block" Context and select "Filters -> Show/Hide Compartments" -> select "initialValues" 2/ Right-click on the "block" Context on the IBD and Select Filters -> Show/hide Contents. At the bottom of this window , the user can select an option to "Automatically fill in the contents based on default values". The result of this is the figure shown in the mockup result. UC2/ Manual filling of the parts -> This is currently kind of hard for me to imagine how to do it, since it can/will conflict with the existing "Show/hide Contents" menu. [*] [*] Note that the current version of "Show/hide Contents" does not work very well in case of multiplicities > 1. For instance in the 'context' of the s1 subsystem, the multiplicity of p1 is 2 (as can also be seen on the instance diagram). However, when selecting "Show/hide Contents" on s1:subsystem, p1 only appears once. If you unselect 'p1', one of the two p1:Parts dissappear. If you press another time "Show/hide Contents" on the s1:subsystem, p1 is set again. Unselecting it again will make the other p1:Part disappear... Hence currently, the show/hide contents seems not to take into account possible multiplicities of the part (I can imagine this is not trivial in the case of multiplicities '*' :-) Thoughts? Side note: is there currently any effort planned on this bug (as it has the "assigned" status)? To me personally, context specific values seem to be a show stopper in order to claim to be able to do something useful with SysML models.
For benoit :-) Rationale for this compartment from SysML 1.4 spec. 8.3.1.2.8 Initial values compartment A compartment with a label of “initialValues” may be used to show values of properties belonging to a containing block. These values override any default values that may have been previously specified on these properties on their originally defining block. Initial value compartments may be specified within nested properties, which then apply only in the particular usage context defined by the outermost containing block. Values are specified in an initialValues compartment by lines in the form <property-name> = <value-specification> or <property-name> : <type> = <value-specification>, each line of which specifies the initial value for one property owned either by the block that types the property or by any of its supertypes. This portion of concrete syntax is the same as may be shown for values within the UML instance specification notation, but this is the only element of UML InstanceSpecification notation that may be shown in an initial values compartment. See “Block” on page 51” for details of how values within initialValues compartments are represented in the SysML metamodel. p. 52 In addition to the form of default value specifications that SysML supports on properties of a block (with an optional “=” <value-specification> string following the rest of a property definition), SysML supports an additional form of value specification for properties using initialValue compartments on an internal block diagram (see “Internal Block Diagram” on page 44). An entire tree of context-specific values can be specified on a containing block to carry values of nested properties as shown on an internal block diagram.
Hi Benoit, Could you move this one to SysML 1.4? Thx!
