Community
Participate
Working Groups
Consider the following steps to create a part property. In an IBD: - drag a property prop1(hence not a part property) - in the properties view, set the type of prop1 to another block, and set its composition to "composite". prop1 is now a part property, yet there's no association in the model.
I won't expect that the tool create an association in this use case. 2 suggestion: - when dropping a property, add a specific strategy to create a part - add a validation rule to check "consistency" of parts
Hi Benoit, (In reply to Benoit Maggi from comment #1) > I won't expect that the tool create an association in this use case. What do you exactly mean with "I won't expect"? Did you mean "I wouldn't expect"? > 2 suggestion: > - when dropping a property, add a specific strategy to create a part > - add a validation rule to check "consistency" of parts Hmm, rereading this, I'm not sure the bug is correctly formulated. Constraint [4] on page 53 of the spec mentions the following [quote] In the UML metamodel on which SysML is built, a Property that is typed by a block must be defined as an end of an association. (An inverse end of this association, whether owned by another block or the association itself, must always be present so there is always a metamodel element to record the inverse multiplicity of the reference.) [/quote] So I would expect that a SysML tool would have a 'hook', to ensure that, whenever the type of a property is modified and the property is now typed by a block, it is checked if an association already exists, and if not an association is created in order to ensure models are consistent. Whether the property is now a part property or not, doesn't seem to matter (as expressed wrongly in the original bug report.
I have a draft for this rule but I have a strange behavior. Model Block1 property1:Block2 (valid) property2:Block2 (invalid) Block2 Association (property1;Block2) use case 1: - run validation on the model => no error use case 2: - run validation sub tree on property2 => error
Gerrit change https://git.eclipse.org/r/85198 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus-sysml.git/commit/?id=5d55ed0a93c484face11e7daefe9d43456766c72
I merged the rule since, it seems correctly implemented. The problem of validation has been reported to the core in Bug 507734. The rule can be validate by launching validate sub tree on a property. Which is technically working but clearly not acceptable in user point of view
New Gerrit change created: https://git.eclipse.org/r/86846
Gerrit change https://git.eclipse.org/r/86846 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus-sysml.git/commit/?id=8cf5d7f96a40b03e09e97755825b29fb14a2ce6a
(In reply to Eclipse Genie from comment #7) > Gerrit change https://git.eclipse.org/r/86846 was merged to [master]. > Commit: > http://git.eclipse.org/c/papyrus/org.eclipse.papyrus-sysml.git/commit/ > ?id=8cf5d7f96a40b03e09e97755825b29fb14a2ce6a It looks like the warning is now also generated for port (properties). A SysML specification problem? (Still, a very annoying one :-)
@Klaas: Indeed. In your opinion how should the norm be interpreted? 8.3.2.3 Block [4] In the UML metamodel on which SysML is built, a Property that is typed by a block must be defined as an end of an association. (An inverse end of this association, whether owned by another block or the association itself, must always be present so there is always a metamodel element to record the inverse multiplicity of the reference.) => I didn't found references exempting the port. This is probably a bug in the norm. You can disable the rule in the preferences.
(In reply to Benoit Maggi from comment #9) > @Klaas: Indeed. > > In your opinion how should the norm be interpreted? > > 8.3.2.3 Block [4] In the UML metamodel on which SysML is built, > a Property that is typed by a block must be defined as an end of an > association. > (An inverse end of this association, whether owned by > another block or the association itself, must always be present so there > is always a metamodel element to record the inverse multiplicity of the > reference.) > > => I didn't found references exempting the port. > This is probably a bug in the norm. Hi Benoit, at least the norm is unclear here IMO! Section 9.3.1.6 does mention the following: [quote] Ports are specialized kinds of properties, and can be shown in same way as other properties. They can appear in block compartments in the same format as other properties of their owning blocks, or as the ends of associations, with the port appearing in the same format as other association ends, on the end opposite the owning block. All ports and nested ports (i.e., proxy, full, and ports with no stereotype applied), and their type definitions (e.g., interface blocks, blocks) can include compartments with textual and graphical representations to display their features in the same way as other properties and types, including rectangles used to display properties in structure compartments. [/quote] For a FullPort, it would seem very logical to also impose the existence of an association IMO. Indeed, a FullPort is a typically used for a part property which is 'on the boundary' of its parent. As such it would seem strange that associations are only necessary for parts on the inside, but not for parts on the outside For an ProxyPort, it is less obvious in my opinion, but in the strict sense, it has to be typed by an interface block so an association should also exist. Given the statements in section 9.3.1.6, I would assume that it might be the intention of SysML to indeed have an association for each port (notice my careful statements :-) Unfortunately, the Diagram Elements paragraph of Section 9 in the spec doesn't show any example. And without having a custom label on the association end (for instance "<<fullPort>> partNameOnTheBoundary" instead of just "partNameOnTheBoundary") it might be confusing... > You can disable the rule in the preferences. [/MeBangsHeadsAgainstTheWall] :-) Thx!
I agree that it is unclear for now. Although we are not sure about the correct interpretation, I guess it is better to change the current validation to exclude it on Ports. Why? * Suppose the standard really means to include Ports: --> then we end up having an incomplete validation. * Suppose the standard does not mean to include Ports: --> then we are unnecessarily bothering the user with a massive amount of validation issues, making validation essentially useless (or at least requiring the use to disable the validation manually and losing everything.) Therefore: my preference would be to change BlockPropertyAssociationEndModelConstraint to exclude Ports.
New Gerrit change created: https://git.eclipse.org/r/90730
@Johan, Klaas: I made a patch to apply the constraint only and property (not port) Does it looks god to you? Klaas Do you want that I add the <<Full Port>> in the constraint ? I added a FIXME in the code if we ever get a clear answer on the subject.
Guys, I have been re-reading section "8.3.2.3 Block" of the spec in order to try and understand the "intention" of the specification's authors. I consider the following phrases of the spec: * "In SysML, navigation is equivalent to a named property owned directly by a block." My interpretation: SysML doesn't need an association to reflect navigability. If the Block owns the Property, it considers it to be navigable by definition. * "The only form of an association end that SysML allows an association to own directly is an unnamed end used to carry an inverse multiplicity of a reference property." My interpratation: SysML _only_ requires associations for one specific case: a reference property needs some way to store its inverse multiplicity. * Constraint [4] "In the UML metamodel on which SysML is built, a Property that is typed by a block must be defined as an end of an association. (An inverse end of this association, whether owned by another block or the association itself, must always be present so there is always a metamodel element to record the inverse multiplicity of the reference.)" My interpretation: the SysML spec "solves" both previous bullets by imposing that the association is always available. My conclusion: I feel that SysML's constraint 4 is overkill. * Why do we need to reflect navigability through a UML metamodel element? Just to show to "UML" that we have that additional SysML semantics that owned properties are navigable by default? Does navigability have any other consequences at all except for semantical interpretation? * The only real need is a metamodel element to record the inverse multiplicity for references. Therefore, I would suggest to reduce the implementation of [4] even further: * Only enforce this [4] for references * Advantage 1: much less cluttering associations * Advantage 2: the issue about FullPorts is "solved", since they are always composite. In addition, by preference Papyrus should automatically create/destroy the required association and its owned unnamed memberEnd based on the aggregation status of the Property. That frees the user from manually fulfilling this "artificial" requirement.
Hi Johan and Benoit, (In reply to Johan Van Noten from comment #14) > Guys, I have been re-reading section "8.3.2.3 Block" of the spec in order to > try and understand the "intention" of the specification's authors. > > I consider the following phrases of the spec: > > * "In SysML, navigation is equivalent to a named property owned directly by > a block." > My interpretation: SysML doesn't need an association to reflect > navigability. If the Block owns the Property, it considers it to be > navigable by definition. > > * "The only form of an association end that SysML allows an association to > own directly is an unnamed end used to carry an inverse multiplicity of a > reference > property." > My interpratation: SysML _only_ requires associations for one specific > case: a reference property needs some way to store its inverse multiplicity. > > * Constraint [4] "In the UML metamodel on which SysML is built, a Property > that is typed by a block must be defined as an end of an association. (An > inverse end of this association, whether owned by another block or the > association itself, must always be present so there is always a metamodel > element to record the inverse multiplicity of the reference.)" > My interpretation: the SysML spec "solves" both previous bullets by > imposing that the association is always available. > > My conclusion: I feel that SysML's constraint 4 is overkill. > * Why do we need to reflect navigability through a UML metamodel element? > Just to show to "UML" that we have that additional SysML semantics that > owned properties are navigable by default? Does navigability have any other > consequences at all except for semantical interpretation? > * The only real need is a metamodel element to record the inverse > multiplicity for references. > > Therefore, I would suggest to reduce the implementation of [4] even further: > * Only enforce this [4] for references > * Advantage 1: much less cluttering associations > * Advantage 2: the issue about FullPorts is "solved", since they are always > composite. In my feeling, you forget one intention of SysML. My "impression" [*] (I didn't re-read the spec thoroughly today though) has always been that the SysML spec authors have tried to simplify and streamline the UML spec when it comes to associations. More concretely: when you don't impose Constraint [4] to its full extent, _some_ part properties will have an association (because a user manually created an association in the diagram, other won't. In my opinion this is one of the things constraint [4] tried to avoid. [*] 8.1 Some capabilities available for UML classes, such as more specialized forms of associations, have been excluded from SysML blocks to simplify the language. 8.3.2.3 SysML excludes variations of associations in UML in which navigable ends can be owned directly by the association. Wrt. Advantage 1: -> IMO this is rather a tool issue, and I'm not sure it's a good idea to relax a specification constraint because papyrus doesn't have a convenient way of hiding associations. > In addition, by preference Papyrus should automatically create/destroy the > required association and its owned unnamed memberEnd based on the > aggregation status of the Property. That frees the user from manually > fulfilling this "artificial" requirement. I think this is indeed a key thing. The user/modeler should not be bothered by all this. Papyrus should in the background _enforce_ compliancy with the SysML spec, rather than send 1400 violation errors to the user when it's too late. In that respect, as long as it's not possible to enforce this (or at least having a function to correct all validation warnings at once), I would argue not to implement it for FullPorts, just for the convenience of the user. For the rest, the patch looks fine to me!
Gerrit change https://git.eclipse.org/r/90730 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus-sysml.git/commit/?id=2d37af4db0462604fb251fbafdd79aa5a9a23300
(In reply to Benoit Maggi from comment #13) > @Johan, Klaas: I made a patch to apply the constraint only and property (not > port) > > Does it looks god to you? > > Klaas Do you want that I add the <<Full Port>> in the constraint ? > > I added a FIXME in the code if we ever get a clear answer on the subject. From http://www.omgwiki.org/OMGSysML/lib/exe/fetch.php?media=sysml-roadmap:interface_needs_r7.docx [quote] Section 3. Limitations of current SysML interface modeling (i.e. ports, connectors, item flows) Item 6. Full Port and Part over lapping semantics a. A Full Port is intended to represent a part located on a boundary, therefore a Full Port should have the same semantics as a part that has been moved to a boundary. b. Often both the part and the full port need to be represented in different views. This requires both constructs to be created and maintained. A part is created when a composition relationship is created but not a full-port. [/quote] Maybe it would be a good idea for an OMG member (hint ;-) to contact somebody of the http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:systems_engineering_concept_model_workgroup and ask for their opinion on the matter how the constraint should be implement currently?
