Issue 16726: Issue on Block constraint#4 (sysml-rtf) Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com) Nature: Uncategorized Issue Severity: Summary: In SysML v1.3, §8.3.2.2 Blocks, the constraint #4 states: “[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.)” No such constraint exists in the UML specification which conversely says the following (UML v2.4, §7.3.45): “A property related to a classifier by ownedAttribute represents an attribute, and it may also represent an association end. It relates an instance of the class to a value or collection of values of the type of the attribute” The SysML Block constraint #4 has no clear justification and should be removed. Resolution: Defer Postponed to the next RTF Revised Text: Actions taken: November 28, 2011: received issue January 3, 2017: Deferred April 6, 2017: closed issue Discussion: End of Annotations:===== m: "BERNARD, Yves" To: "Sysml-Rtf (sysml-rtf@omg.org)" Date: Mon, 28 Nov 2011 11:45:44 +0100 Subject: Issue on Block constraint#4 Thread-Topic: Issue on Block constraint#4 Thread-Index: AcytuuFqxPjC7si2Rt2Dip9K5LazMQ== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US In SysML v1.3, §8.3.2.2 Blocks, the constraint #4 states: .[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.). No such constraint exists in the UML specification which conversely says the following (UML v2.4, §7.3.45): .A property related to a classifier by ownedAttribute represents an attribute, and it may also represent an association end. It relates an instance of the class to a value or collection of values of the type of the attribute. The SysML Block constraint #4 has no clear justification and should be removed. Yves BERNARD Avionics MBSE Leader EADS - AIRBUS Operations S.A.S EYYA - Avionics R&T, Architecture & Integration Phone: 33 (0)5 67 19 45 32 Fax: 33 (0)5 61 93 08 83 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=aQPFlke8TjtRDJ4LjTY362Bd7nDPgwUXw+jv0g/RyCY=; b=wQCigwbbEbAk9gQnR7XHZ7fZQxIveZ3xbNAhJJe6Q4F5PhCp6Lr1sebMSKSo+GkQWq o9/fGhrkVDQCelkQMLDiaMo0xSBrNTqveSsWMpqoUoMdRZjyczqvJx/TjF2nRAEAeyZU EKb+gW5THxQlZXQa39v2IHiIn3x3q7QFSGMnE= From: "Sanford Friedenthal" To: "'BERNARD, Yves'" , "'Burkhart Roger M'" Cc: "'Sysml-Rtf'" Subject: RE: Issue on Block constraint#4 Date: Mon, 28 Nov 2011 08:49:03 -0500 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcytuuFqxPjC7si2Rt2Dip9K5LazMQAGVeIA Yves I agree. For starters, we have situations when Value Types are at both ends of an association. Perhaps Roger can comment. I suggest you then file an issue and if Roger agrees, we can address this in v1.4 as part of the cleanup. Let.s here from Roger to see if there is more to the story first. Thanks. Sandy From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Monday, November 28, 2011 5:46 AM To: Sysml-Rtf (sysml-rtf@omg.org) Subject: Issue on Block constraint#4 In SysML v1.3, §8.3.2.2 Blocks, the constraint #4 states: .[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.). No such constraint exists in the UML specification which conversely says the following (UML v2.4, §7.3.45): .A property related to a classifier by ownedAttribute represents an attribute, and it may also represent an association end. It relates an instance of the class to a value or collection of values of the type of the attribute. The SysML Block constraint #4 has no clear justification and should be removed. Yves BERNARD Avionics MBSE Leader EADS - AIRBUS Operations S.A.S EYYA - Avionics R&T, Architecture & Integration Phone: 33 (0)5 67 19 45 32 Fax: 33 (0)5 61 93 08 83 From: TANGUY Yann 176637 To: "sysml-rtf@omg.org" CC: GERARD Sebastien 166342 , "BERNARD, Yves (Yves.Bernard@airbus.com)" , Alain LEGUENNEC Subject: Is a property typed by Block necessary an association end ? Thread-Topic: Is a property typed by Block necessary an association end ? Thread-Index: AcywPm+3pa7a0hrOSKuXa/oY1ZRZ7w== Date: Thu, 1 Dec 2011 15:32:31 +0000 Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.106] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18554.000 x-tm-as-result: No--42.286500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Hi everyone, We had an interesting discussion recently with Yves related to Papyrus SysML support, and in particular, related to this 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.) From Yves point of view this constraint is an obvious specification mistake as the same kind of constraint does not exist in UML. Is this opinion shared by the SysML team? Is the constraint incorrectly written or is it totally invalid? I was wondering if there was some kind of simplification means behind this constraint, after all if the same constraint already existed in UML adding it in SysML would have been pointless anyway. In UML a Property related to a Classifier by ownedAttribute represent an attribute and may also represent an association end. UML allows an .association-like. notation for attributes, and an .attribute-like. notation for association end. Always defining property typed by block as defined in the constraint could be a voluntary simplification which legitimates both representations with a common modeling. Best regards, Yann Tanguy From: "Rouquette, Nicolas F (313K)" To: TANGUY Yann 176637 CC: "sysml-rtf@omg.org" , GERARD Sebastien 166342 , "BERNARD, Yves (Yves.Bernard@airbus.com)" , Alain LEGUENNEC Date: Thu, 1 Dec 2011 08:13:02 -0800 Subject: Re: Is a property typed by Block necessary an association end ? Thread-Topic: Is a property typed by Block necessary an association end ? Thread-Index: AcywRBpGHgYFHEmQSX6HwOmX+VcYzg== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Yann, On Dec 1, 2011, at 7:32 AM, TANGUY Yann 176637 wrote: Hi everyone, We had an interesting discussion recently with Yves related to Papyrus SysML support, and in particular, related to this 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.) From Yves point of view this constraint is an obvious specification mistake as the same kind of constraint does not exist in UML. I disagree with Yves' assessment. SysML [4] is fine -- it's what makes SysML better than UML because the UML association notation is unfortunately ambiguous. When you see an association-like notation between A and B, it could mean: a) there is really an Association relating A and B. b) there is no Association relating A and B but the association-like notation is used to show an attribute of A typed by B or to show an attribute of B typed by A (see UML 2.4.1, figure 7.31 in sec. 7.3.8) With SysML [4], the meaning of the association0like notation is always (a), not (b). Furthermore, SysML says that the property that is owned by the association and is typically not labeled in diagram is semantically the inverse of the property that is shown in the diagram. As far as I'm concerned, SysML is, conceptually, a better-behaved modeling language than UML is even though SysML is, practically, incompletely specified (lots of OCL is missing). Is this opinion shared by the SysML team? Is the constraint incorrectly written or is it totally invalid? As far as I'm concerned, the constraint is totally valid, perfectly sensible, and defensively useful for modeling purposes. I was wondering if there was some kind of simplification means behind this constraint, after all if the same constraint already existed in UML adding it in SysML would have been pointless anyway. It's not in UML otherwise it would have been pointless to add it in SysML. In UML a Property related to a Classifier by ownedAttribute represent an attribute and may also represent an association end. UML allows an .association-like. notation for attributes, and an .attribute-like. notation for association end. Indeed, the UML notation is inherently ambiguous. In practice, very few tools have supported the association-like notation for class attributes so few people have complained to tool vendors/implementors about it. Always defining property typed by block as defined in the constraint could be a voluntary simplification which legitimates both representations with a common modeling. Well, we can be thankful that some folks in SysML had their modeling thinking cap screwed on tightly and put language in the SysML spec to protect users against this nonsensical ambiguity. - Nicolas. Best regards, Yann Tanguy From: "BERNARD, Yves" To: "Rouquette, Nicolas F (313K)" , TANGUY Yann 176637 CC: "sysml-rtf@omg.org" , GERARD Sebastien 166342 , Alain LEGUENNEC Date: Thu, 1 Dec 2011 17:56:09 +0100 Subject: RE: Is a property typed by Block necessary an association end ? Thread-Topic: Is a property typed by Block necessary an association end ? Thread-Index: AcywRBpGHgYFHEmQSX6HwOmX+VcYzgAAJgZg Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Hi Nicolas, There are three points in the question and I would be fine to not mix them up: 1. Does the UML metamodel imply a part to be a role? 2. Do we want such a constraint in SysML? 3. Do we want in SysML an association-like notation for attribute and an attribute-like notation for association end? Answer to 1 is clearly: No. So constraint #4 is wrong, at least as it is currently written. Points 2 and 3 are distinct and must be discussed separately. Let.s start with point 2 first. Assume, I want to simply specify that the Block type .Wheel. has one part named .tire. of type and nothing more. All what I actually need is to add one property .tire. to the Wheel block definition, typed by B. It.s exactly what I do (nothing less, nothing more) when I create this property as an ownedAttribute. If conversely I choose to model it using an association, I.m going to create, in addition to the .tire. property, one new classifier for the association and another property for the opposite end of the association. What is the rationale for such extra data? Now, try to think with the Certification Authorities viewpoint: how can you justify creating the second property (opposite side) in your specification since it is obviously not required according to the need? At least you should admit that creating an attribute and creating a role is not the same thing at all. Yves From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: jeudi 1 démbre 2011 17:13 To: TANGUY Yann 176637 Cc: sysml-rtf@omg.org; GERARD Sebastien 166342; BERNARD, Yves; Alain LEGUENNEC Subject: Re: Is a property typed by Block necessary an association end ? Yann, On Dec 1, 2011, at 7:32 AM, TANGUY Yann 176637 wrote: Hi everyone, We had an interesting discussion recently with Yves related to Papyrus SysML support, and in particular, related to this 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.) From Yves point of view this constraint is an obvious specification mistake as the same kind of constraint does not exist in UML. I disagree with Yves' assessment. SysML [4] is fine -- it's what makes SysML better than UML because the UML association notation is unfortunately ambiguous. When you see an association-like notation between A and B, it could mean: a) there is really an Association relating A and B. b) there is no Association relating A and B but the association-like notation is used to show an attribute of A typed by B or to show an attribute of B typed by A (see UML 2.4.1, figure 7.31 in sec. 7.3.8) With SysML [4], the meaning of the association0like notation is always (a), not (b). Furthermore, SysML says that the property that is owned by the association and is typically not labeled in diagram is semantically the inverse of the property that is shown in the diagram. As far as I'm concerned, SysML is, conceptually, a better-behaved modeling language than UML is even though SysML is, practically, incompletely specified (lots of OCL is missing). Is this opinion shared by the SysML team? Is the constraint incorrectly written or is it totally invalid? As far as I'm concerned, the constraint is totally valid, perfectly sensible, and defensively useful for modeling purposes. I was wondering if there was some kind of simplification means behind this constraint, after all if the same constraint already existed in UML adding it in SysML would have been pointless anyway. It's not in UML otherwise it would have been pointless to add it in SysML. In UML a Property related to a Classifier by ownedAttribute represent an attribute and may also represent an association end. UML allows an .association-like. notation for attributes, and an .attribute-like. notation for association end. Indeed, the UML notation is inherently ambiguous. In practice, very few tools have supported the association-like notation for class attributes so few people have complained to tool vendors/implementors about it. Always defining property typed by block as defined in the constraint could be a voluntary simplification which legitimates both representations with a common modeling. Well, we can be thankful that some folks in SysML had their modeling thinking cap screwed on tightly and put language in the SysML spec to protect users against this nonsensical ambiguity. - Nicolas. Best regards, Yann Tanguy From: "Rouquette, Nicolas F (313K)" To: "BERNARD, Yves" CC: TANGUY Yann 176637 , "sysml-rtf@omg.org" , GERARD Sebastien 166342 , Alain LEGUENNEC Date: Thu, 1 Dec 2011 09:20:04 -0800 Subject: Re: Is a property typed by Block necessary an association end ? Thread-Topic: Is a property typed by Block necessary an association end ? Thread-Index: AcywTXdxCtDF689bTEa4RCzd9mrdMA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap02.jpl.nasa.gov [128.149.137.73] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized On Dec 1, 2011, at 8:56 AM, BERNARD, Yves wrote: Hi Nicolas, There are three points in the question and I would be fine to not mix them up: 1. Does the UML metamodel imply a part to be a role? 2. Do we want such a constraint in SysML? 3. Do we want in SysML an association-like notation for attribute and an attribute-like notation for association end? Answer to 1 is clearly: No. Again, it's an unfortunate ambiguity inherited from the fact that UML's model of composite structure in 2.0 was half-baked. In hindsight, SysML was an impressive effort to find elegant ways to make composite structure practically useful. So constraint #4 is wrong, at least as it is currently written. No, it is a strong indication that SysML is making a semantic clarification w.r.t. this ambiguity: that is, a part property typed by a block in sysml is also a role in an association where the part property is a member end of that association. I have no idea what kind of semantics or ontological basis would there be in a modeling language with part properties that are not at all association end properties as well. The notion of modeling that A has a part property typed by B certainly implies a kind of (structural) relationship between A and B. The association conveys this (structural) relationship quite well. Points 2 and 3 are distinct and must be discussed separately. Let.s start with point 2 first. Assume, I want to simply specify that the Block type .Wheel. has one part named .tire. of type and nothing more. Yes and in doing this, you are effectively modeling a structural relationship between Wheel and Tire. All what I actually need is to add one property .tire. to the Wheel block definition, typed by B. It.s exactly what I do (nothing less, nothing more) when I create this property as an ownedAttribute. Sure you have an attribute but if you were to look more closely, what is an attribute? it's an instance of UML:Property. If you were to use a real CMOF-based modeling tool, you'd see instances of the M2 associations between Class / Property (i.e., ownedAttribute) and between Property / Type (i.e., tire is typed by Tire) So the relationship is there at M2. Why pretend it doesn't exist at M1 when you can perfectly represent it as an association between Wheel & Tire with tire as one of the association ends? If conversely I choose to model it using an association, I.m going to create, in addition to the .tire. property, one new classifier for the association and another property for the opposite end of the association. What is the rationale for such extra data? If you were to create a bunch of instances of Wheel & Tire objects, without the association, then you can't tell to which Wheel a particular Tire belongs. That is, you have, from the perspective of a Wheel, what appears to be exclusive structural ownership of parts. But, from the perspective of Tire, you've got no clue that there's any kind of structure at all. An association allows both sides (the Wheels on the left and the Tires on the right) to leave peacefully in harmony knowing that some Wheels are married to some Tires and there is no swapping! Now, try to think with the Certification Authorities viewpoint: how can you justify creating the second property (opposite side) in your specification since it is obviously not required according to the need? It's the basis on which you can verify consistency of part/role relationships! Without the associations, you simply have insufficient information to verify that your model of part structure makes sense! At least you should admit that creating an attribute and creating a role is not the same thing at all. An attribute is vague: is it typed by a block? if it is, it's part and it is necessarily a role in a relationship. if it is typed by a datatype, it's a value property -- in that case, the association is meaningless because instances of datatypes have no identity! Again, SysML got it right! Stop being so French! - Nicolas. Yves From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: jeudi 1 démbre 2011 17:13 To: TANGUY Yann 176637 Cc: sysml-rtf@omg.org; GERARD Sebastien 166342; BERNARD, Yves; Alain LEGUENNEC Subject: Re: Is a property typed by Block necessary an association end ? Yann, On Dec 1, 2011, at 7:32 AM, TANGUY Yann 176637 wrote: Hi everyone, We had an interesting discussion recently with Yves related to Papyrus SysML support, and in particular, related to this 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.) From Yves point of view this constraint is an obvious specification mistake as the same kind of constraint does not exist in UML. I disagree with Yves' assessment. SysML [4] is fine -- it's what makes SysML better than UML because the UML association notation is unfortunately ambiguous. When you see an association-like notation between A and B, it could mean: a) there is really an Association relating A and B. b) there is no Association relating A and B but the association-like notation is used to show an attribute of A typed by B or to show an attribute of B typed by A (see UML 2.4.1, figure 7.31 in sec. 7.3.8) With SysML [4], the meaning of the association0like notation is always (a), not (b). Furthermore, SysML says that the property that is owned by the association and is typically not labeled in diagram is semantically the inverse of the property that is shown in the diagram. As far as I'm concerned, SysML is, conceptually, a better-behaved modeling language than UML is even though SysML is, practically, incompletely specified (lots of OCL is missing). Is this opinion shared by the SysML team? Is the constraint incorrectly written or is it totally invalid? As far as I'm concerned, the constraint is totally valid, perfectly sensible, and defensively useful for modeling purposes. I was wondering if there was some kind of simplification means behind this constraint, after all if the same constraint already existed in UML adding it in SysML would have been pointless anyway. It's not in UML otherwise it would have been pointless to add it in SysML. In UML a Property related to a Classifier by ownedAttribute represent an attribute and may also represent an association end. UML allows an .association-like. notation for attributes, and an .attribute-like. notation for association end. Indeed, the UML notation is inherently ambiguous. In practice, very few tools have supported the association-like notation for class attributes so few people have complained to tool vendors/implementors about it. Always defining property typed by block as defined in the constraint could be a voluntary simplification which legitimates both representations with a common modeling. Well, we can be thankful that some folks in SysML had their modeling thinking cap screwed on tightly and put language in the SysML spec to protect users against this nonsensical ambiguity. - Nicolas. Best regards, Yann Tanguy From: "BERNARD, Yves" To: "Rouquette, Nicolas F (313K)" CC: TANGUY Yann 176637 , "sysml-rtf@omg.org" , GERARD Sebastien 166342 , Alain LEGUENNEC Date: Fri, 2 Dec 2011 10:23:50 +0100 Subject: RE: Is a property typed by Block necessary an association end ? Thread-Topic: Is a property typed by Block necessary an association end ? Thread-Index: AcywTXdxCtDF689bTEa4RCzd9mrdMAAdEAUw Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Nicolas, First of all I would like to say that my point a nothing to do with a philosophical viewpoint, it is base on a very concrete concern to a practical usage of SysML model for engineering critical embedded systems, which is not a strictly .French stuff. I think. ;o) See my comments below. Cheers, Yves From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: jeudi 1 démbre 2011 18:20 To: BERNARD, Yves Cc: TANGUY Yann 176637; sysml-rtf@omg.org; GERARD Sebastien 166342; Alain LEGUENNEC Subject: Re: Is a property typed by Block necessary an association end ? So constraint #4 is wrong, at least as it is currently written. No, it is a strong indication that SysML is making a semantic clarification w.r.t. this ambiguity: that is, a part property typed by a block in sysml is also a role in an association where the part property is a member end of that association. [BERNARD, Yves] Please, read carefully: .at least as it is written. => even from your point of view you should consider rewording this constraint. The notion of modeling that A has a part property typed by B certainly implies a kind of (structural) relationship between A and B. The association conveys this (structural) relationship quite well. [BERNARD, Yves] There is a structural relationship, for sure. The question is: must this relationship be an UML::Association in all cases? All what I actually need is to add one property .tire. to the Wheel block definition, typed by B. It.s exactly what I do (nothing less, nothing more) when I create this property as an ownedAttribute. Sure you have an attribute but if you were to look more closely, what is an attribute? it's an instance of UML:Property. If you were to use a real CMOF-based modeling tool, you'd see instances of the M2 associations between Class / Property (i.e., ownedAttribute) and between Property / Type (i.e., tire is typed by Tire) So the relationship is there at M2. [BERNARD, Yves] CMOF is no more than an implementation based on a set of technical choices made for technical reasons. This does not prove that Properties cannot exist out of associations. One could even says that ultimately, if you look at low level how all those languages are implemented any including relationships is built on .attribute-like. data structure. So, implementation doesn.t sound as a valuable argument here. Why pretend it doesn't exist at M1 when you can perfectly represent it as an association between Wheel & Tire with tire as one of the association ends? [BERNARD, Yves] I never said it is not possible, just that it is not desirable in all cases If conversely I choose to model it using an association, I.m going to create, in addition to the .tire. property, one new classifier for the association and another property for the opposite end of the association. What is the rationale for such extra data? If you were to create a bunch of instances of Wheel & Tire objects, without the association, then you can't tell to which Wheel a particular Tire belongs. [BERNARD, Yves] That.s not true. The tire .cannot know. which wheel it belongs to, but you can. And indeed, if you consider the tires of your car you will see that they actually have no intrinsic property allowing them to know what instance of a wheel they are related to. No more than a wheel has an intrinsic property to know what instance of a tire is related to it. All of this is only engineering information. The point is: how to model and organize this information from an engineering perspective to describe without ambiguity what has to been produced and to be able to prove that the required Design Assurance Level has been reached. Now, try to think with the Certification Authorities viewpoint: how can you justify creating the second property (opposite side) in your specification since it is obviously not required according to the need? It's the basis on which you can verify consistency of part/role relationships! Without the associations, you simply have insufficient information to verify that your model of part structure makes sense! [BERNARD, Yves] Certification Authorities just don.t care about part/role relationships. They care about requirements management. According to Micouin.s theory about Property-based Requirements, any specification of a property is a requirement constraining the owner of that property. Therefore, creating an association instead of a simple attribute will generate two requirements instead of one. You will have to justify both of them according to upstream requirements. In some case it will be easy but in some other it will be far more difficult (maybe impossible) and in all case it will cost more, so I don.t want to be enforced to do it if I don.t really need it. Subject: RE: Is a property typed by Block necessary an association end ? Date: Fri, 2 Dec 2011 08:47:22 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Is a property typed by Block necessary an association end ? Thread-Index: AcywTXdxCtDF689bTEa4RCzd9mrdMAAdEAUwABPrqcA= From: "Pete Rivett" To: "BERNARD, Yves" , "Rouquette, Nicolas F (313K)" Cc: "TANGUY Yann 176637" , , "GERARD Sebastien 166342" , "Alain LEGUENNEC" Ø BERNARD, Yves] CMOF is no more than an implementation based on a set of technical choices made for technical reasons I must disagree with this: CMOF is the compliance level of the MOF 2 specification that is used to define the UML2 metamodel! It.s the standard which is the basis for UML2 and other metamodels and provides the semantics of metamodeling. Not at all an implementation option. Pete -- Pete Rivett (pete.rivett@adaptive.com) CTO, Adaptive Inc 65 Enterprise, Aliso Viejo, CA 92656 cell: +1 949 338 3794 Follow me on Twitter @rivettp or http://twitter.com/rivettp From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, December 02, 2011 1:24 AM To: Rouquette, Nicolas F (313K) Cc: TANGUY Yann 176637; sysml-rtf@omg.org; GERARD Sebastien 166342; Alain LEGUENNEC Subject: RE: Is a property typed by Block necessary an association end ? Nicolas, First of all I would like to say that my point a nothing to do with a philosophical viewpoint, it is base on a very concrete concern to a practical usage of SysML model for engineering critical embedded systems, which is not a strictly .French stuff. I think. ;o) See my comments below. Cheers, Yves From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: jeudi 1 démbre 2011 18:20 To: BERNARD, Yves Cc: TANGUY Yann 176637; sysml-rtf@omg.org; GERARD Sebastien 166342; Alain LEGUENNEC Subject: Re: Is a property typed by Block necessary an association end ? So constraint #4 is wrong, at least as it is currently written. No, it is a strong indication that SysML is making a semantic clarification w.r.t. this ambiguity: that is, a part property typed by a block in sysml is also a role in an association where the part property is a member end of that association. [BERNARD, Yves] Please, read carefully: .at least as it is written. => even from your point of view you should consider rewording this constraint. The notion of modeling that A has a part property typed by B certainly implies a kind of (structural) relationship between A and B. The association conveys this (structural) relationship quite well. [BERNARD, Yves] There is a structural relationship, for sure. The question is: must this relationship be an UML::Association in all cases? All what I actually need is to add one property .tire. to the Wheel block definition, typed by B. It.s exactly what I do (nothing less, nothing more) when I create this property as an ownedAttribute. Sure you have an attribute but if you were to look more closely, what is an attribute? it's an instance of UML:Property. If you were to use a real CMOF-based modeling tool, you'd see instances of the M2 associations between Class / Property (i.e., ownedAttribute) and between Property / Type (i.e., tire is typed by Tire) So the relationship is there at M2. [BERNARD, Yves] CMOF is no more than an implementation based on a set of technical choices made for technical reasons. This does not prove that Properties cannot exist out of associations. One could even says that ultimately, if you look at low level how all those languages are implemented any including relationships is built on .attribute-like. data structure. So, implementation doesn.t sound as a valuable argument here. Why pretend it doesn't exist at M1 when you can perfectly represent it as an association between Wheel & Tire with tire as one of the association ends? [BERNARD, Yves] I never said it is not possible, just that it is not desirable in all cases If conversely I choose to model it using an association, I.m going to create, in addition to the .tire. property, one new classifier for the association and another property for the opposite end of the association. What is the rationale for such extra data? If you were to create a bunch of instances of Wheel & Tire objects, without the association, then you can't tell to which Wheel a particular Tire belongs. [BERNARD, Yves] That.s not true. The tire .cannot know. which wheel it belongs to, but you can. And indeed, if you consider the tires of your car you will see that they actually have no intrinsic property allowing them to know what instance of a wheel they are related to. No more than a wheel has an intrinsic property to know what instance of a tire is related to it. All of this is only engineering information. The point is: how to model and organize this information from an engineering perspective to describe without ambiguity what has to been produced and to be able to prove that the required Design Assurance Level has been reached. Now, try to think with the Certification Authorities viewpoint: how can you justify creating the second property (opposite side) in your specification since it is obviously not required according to the need? It's the basis on which you can verify consistency of part/role relationships! Without the associations, you simply have insufficient information to verify that your model of part structure makes sense! [BERNARD, Yves] Certification Authorities just don.t care about part/role relationships. They care about requirements management. According to Micouin.s theory about Property-based Requirements, any specification of a property is a requirement constraining the owner of that property. Therefore, creating an association instead of a simple attribute will generate two requirements instead of one. You will have to justify both of them according to upstream requirements. In some case it will be easy but in some other it will be far more difficult (maybe impossible) and in all case it will cost more, so I don.t want to be enforced to do it if I don.t really need it. From: "Rouquette, Nicolas F (313K)" To: "BERNARD, Yves" , TANGUY Yann 176637 CC: "sysml-rtf@omg.org" , GERARD 166342 , Alain LEGUENNEC , Pete Rivett Date: Fri, 2 Dec 2011 13:24:48 -0800 Subject: Re: Is a property typed by Block necessary an association end ? Thread-Topic: Is a property typed by Block necessary an association end ? Thread-Index: AcyxONLkzqPQrRvyRiifWzm4D3AWXw== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized See below. On Dec 2, 2011, at 8:47 AM, Pete Rivett wrote: Ø BERNARD, Yves] CMOF is no more than an implementation based on a set of technical choices made for technical reasons I must disagree with this: CMOF is the compliance level of the MOF 2 specification that is used to define the UML2 metamodel! It.s the standard which is the basis for UML2 and other metamodels and provides the semantics of metamodeling. Not at all an implementation option. Thanks Pete for this concise clarification. ... First of all I would like to say that my point a nothing to do with a philosophical viewpoint, it is base on a very concrete concern to a practical usage of SysML model for engineering critical embedded systems, which is not a strictly .French stuff. I think. ;o) Yes, we both want to use SysML for rigorous model-based systems engineering. Currently, this requires imposing additional restrictions on the use of the language because there is insufficient rigor in the OMG specs. No, it is a strong indication that SysML is making a semantic clarification w.r.t. this ambiguity: that is, a part property typed by a block in sysml is also a role in an association where the part property is a member end of that association. [BERNARD, Yves] Please, read carefully: .at least as it is written. => even from your point of view you should consider rewording this constraint. As written, [4] is misleading: [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.) Since the concept of block is from SysML, it's clear that this sentence is ill-formed; it could be written to convey the intended restriction better, e.g.: [4] SysML imposes a restriction on the UML metamodel on which it is built where 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.) The notion of modeling that A has a part property typed by B certainly implies a kind of (structural) relationship between A and B. The association conveys this (structural) relationship quite well. [BERNARD, Yves] There is a structural relationship, for sure. The question is: must this relationship be an UML::Association in all cases? Indeed, the right question is how should we represent structural relationships in models? All what I actually need is to add one property .tire. to the Wheel block definition, typed by B. It.s exactly what I do (nothing less, nothing more) when I create this property as an ownedAttribute. This simplicity is deceptive because it comes at very expensive price: asymmetric verification complexity. Consider an instance of a Wheel, w, and an instance of a Tire, t. In OCL, you can check if t is the tire of w: w.tire = t The asymmetry comes from the difference in the cost of navigating between Wheel & Tire. In one direction, navigation is cheap: w.tire In the other direction, navigation is very expensive; without a-priori knowledge to restrict the scope of possible Wheels to consider, you'd have to write: Wheel.allInstances()->select(w| w.tire = t) SysML offers an effective compromise between modeling simplicity and verification symmetry: - you still get the simplicity that, in a BDD diagram, you only see Wheel, Tire and Wheel.tire (the "directed" association end). - although the association end typed by Wheel is unlabeled in SysML diagrams, it is there; per conventions its name is the name of the type with initial lowercase letter; i.e., wheel in this case - thanks to OCL 2.3, we can navigate in either direction -- that is, the ownership of association ends is irrelevant for OCL navigation: w.tire t.wheel - since QVT Operational is specified as an extension of OCL, then we can legitimately expect to get the benefits of OCL navigation support in QVT Operational as well Sure you have an attribute but if you were to look more closely, what is an attribute? it's an instance of UML:Property. If you were to use a real CMOF-based modeling tool, you'd see instances of the M2 associations between Class / Property (i.e., ownedAttribute) and between Property / Type (i.e., tire is typed by Tire) So the relationship is there at M2. [BERNARD, Yves] CMOF is no more than an implementation based on a set of technical choices made for technical reasons. Pete addressed this point. This does not prove that Properties cannot exist out of associations. Of course and that is not what I meant either. One could even says that ultimately, if you look at low level how all those languages are implemented any including relationships is built on .attribute-like. data structure. So, implementation doesn.t sound as a valuable argument here. This is irrelevant for the modeling concerns pertaining to systems engineering. Why pretend it doesn't exist at M1 when you can perfectly represent it as an association between Wheel & Tire with tire as one of the association ends? [BERNARD, Yves] I never said it is not possible, just that it is not desirable in all cases Desirable for what purpose? Is the asymmetry in verification complexity something you find acceptable? If conversely I choose to model it using an association, I.m going to create, in addition to the .tire. property, one new classifier for the association and another property for the opposite end of the association. What is the rationale for such extra data? If you were to create a bunch of instances of Wheel & Tire objects, without the association, then you can't tell to which Wheel a particular Tire belongs. [BERNARD, Yves] That.s not true. The tire .cannot know. which wheel it belongs to, but you can. And indeed, if you consider the tires of your car you will see that they actually have no intrinsic property allowing them to know what instance of a wheel they are related to. No more than a wheel has an intrinsic property to know what instance of a tire is related to it. All of this is only engineering information. Of course; a model is inherently information that represents an abstraction of something. The point is: how to model and organize this information from an engineering perspective to describe without ambiguity what has to been produced and to be able to prove that the required Design Assurance Level has been reached. Based on the abstract syntax/semantics of CMOF models and based on OCL as the official language for querying such models, we also need to consider the complexity of verifying such models. As explained above, the choices made w.r.t. how to model structural relationships incl. parts does have a significant consequence on the verification complexity. It so happens that the SysML approach specified awkwardly in constraint [4] corresponds precisely to the most efficient form of modeling representation we could possibly achieve for CMOF models. Now, try to think with the Certification Authorities viewpoint: how can you justify creating the second property (opposite side) in your specification since it is obviously not required according to the need? It's the basis on which you can verify consistency of part/role relationships! Without the associations, you simply have insufficient information to verify that your model of part structure makes sense! [BERNARD, Yves] Certification Authorities just don.t care about part/role relationships. They care about requirements management. According to Micouin.s theory about Property-based Requirements, any specification of a property is a requirement constraining the owner of that property. That's fine. Therefore, creating an association instead of a simple attribute will generate two requirements instead of one. No! You've misunderstood the intent of SysML [4] -- the unlabeled association-owned end semantically represents the *inverse* of the labeled association end shown in a BDD diagram. Have you asked Micouin whether he considers a property P and its inverse P^-1 to be *two* properties in his theory? - Nicolas. From: "BERNARD, Yves" To: "Rouquette, Nicolas F (313K)" , Juergen Boldt CC: TANGUY Yann 176637 , "sysml-rtf@omg.org" , GERARD Sebastien 166342 , Alain LEGUENNEC Date: Mon, 5 Dec 2011 08:26:43 +0100 Subject: RE: Is a property typed by Block necessary an association end ? Thread-Topic: Is a property typed by Block necessary an association end ? Thread-Index: AcyxYhdp0FOeJCKCR1aY94SNq67OtQBvPTvQ Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Nicolas, Juergen, You don.t need to, because we already have one about it: #16726 Yves From: Rouquette, Nicolas F (313K) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: samedi 3 démbre 2011 03:20 To: Juergen Boldt Cc: TANGUY Yann 176637; sysml-rtf@omg.org; GERARD Sebastien 166342; BERNARD, Yves; Alain LEGUENNEC Subject: Re: Is a property typed by Block necessary an association end ? Yes; the spec should be clear on this question. - Nicolas. On Dec 2, 2011, at 1:35 PM, Juergen Boldt wrote: should I file as an issue? -Juergen At 10:32 AM 12/1/2011, TANGUY Yann 176637 wrote: Hi everyone, We had an interesting discussion recently with Yves related to Papyrus SysML support, and in particular, related to this 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.) From Yves point of view this constraint is an obvious specification mistake as the same kind of constraint does not exist in UML. Is this opinion shared by the SysML team? Is the constraint incorrectly written or is it totally invalid? I was wondering if there was some kind of simplification means behind this constraint, after all if the same constraint already existed in UML adding it in SysML would have been pointless anyway. In UML a Property related to a Classifier by ownedAttribute represent an attribute and may also represent an association end. UML allows an .association-like. notation for attributes, and an .attribute-like. notation for association end. Always defining property typed by block as defined in the constraint could be a voluntary simplification which legitimates both representations with a common modeling. Best regards, Yann Tanguy Juergen Boldt Director, Member Services 140 Kendrick Street, Building A Suite 300 Needham, MA 02494 USA Tel: 781 444 0404 x 132 fax: 781 444 0320 www.omg.org From: "BERNARD, Yves" To: "Rouquette, Nicolas F (313K)" , TANGUY Yann 176637 CC: "sysml-rtf@omg.org" , GERARD 166342 , Alain LEGUENNEC , Pete Rivett Date: Mon, 5 Dec 2011 09:30:31 +0100 Subject: RE: Is a property typed by Block necessary an association end ? Thread-Topic: Is a property typed by Block necessary an association end ? Thread-Index: AcyxONLkzqPQrRvyRiifWzm4D3AWXwB5orPQ Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Nicolas, Pete, You misunderstood my point about CMOF, I wanted to say that CMOF is a technology which intend to transform ideas and concept (i.e. immaterial things) in something concrete and manageable. This transformation is made according to some technical choices. Anyway, the focus of this discussion is not on CMOF. Nicolas, it is clear to me that your point of view is driven by methodological consideration. You write: This simplicity is deceptive because it comes at very expensive price: asymmetric verification complexity. I agree that the verification of the owner of a part would require more computing resources without an association but: · one could argue that what can be automated is not so costly: the most expensive tasks are those which cannot be, like the justification of hundreds of .derived. requirements (as DO178 understands it) · If there is no property in your model to specify a requirement on the part about its owner, you will simply not have to verify it. So what is expensive and what is not, mainly depend on your needs and on your methodology. The asymmetry in verification complexity can be perfectly acceptable for the reasons given above. Therefore, I don.t want to be enforced to use associations when I don.t need them. You may prefer another approach and you can perfectly constrain it through your method, it.s up to you but there is no reason to impose it through the SysML specification. Regarding your question about .inverse. property, and according to his paper, Micouin clearly considers them as two requirements coupled by a .de re. dependency. Yves