Issue 18171: Section 11: feature inheritance should be orthogonal to the topology of well-formed connections in a structured classifi (uml25-ftf) Source: NASA (Dr. Nicolas F. Rouquette, nicolas.f.rouquette(at)jpl.nasa.gov) Nature: Uncategorized Issue Severity: Summary: Title: UML2.5, section 11: feature inheritance (of attribute properties, ports and connectors) should be orthogonal to the topology of well-formed connections in a structured classifier Summary: SysML uses extensively UML's StructuredClassifiers. In UML 2.4.1, the well-formedness constraints for UML's StructuredClassifiers were written in English only. In UML 2.5, the well-formedness constraints have both English descriptions and OCL specifications. Unfortunately, the UML 2.5 OCL specifications for the well-formedness of UML's StructuredClassifiers are too restrictive for SysML in 3 areas: 1) StructuredClassifier::/role is a derived union that is subsetted only once by StructuredClassifier::ownedAttribute. This means that inherited attributes of a StructuredClassifier are not considered to be roles of that StructuredClassifier. 2) StructuredClassifier::/part is derived and the derivation is: ownedAttribute->select(isComposite) This means that inherited attributes of a StructuredClassifier are not considered to be parts of that StructuredClassifier. 3) Connector has a constraint, roles, stated as follows: The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier that owned the Connector, or they must be Ports of such roles. inv: structuredClassifier <> null and end->forAll( e | structuredClassifier.role->includes(e.role) or e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort)) There is a significant conceptual asymmetry between the two disjuncts of the forAll() clause. The first disjunct is: structuredClassifier.role->includes(e.role) This restricts the ConnectableElement to be a role of the StructuredClassifier owning the Connector; that is, the ConnectableElement must be an ownedAttribute of that StructuredClassifier. The second disjunct is: e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort) This also restricts the ConnectableElement::partWithPort to be a role of the StructuredClassifier owning the Connector; however, the ConnectableElement Port may be inherited! (see ConnectorEnd::role_and_part_with_port) The conceptual asymmetry is that it is OK to connect inherited ports of owned attributes but it is not OK to connect inherited attributes. >From a conceptual point of view, UML 2.5 does not provide a rationale for restricting the connectivity of UML StructuredClassifiers to owned attributes only. >From a conceptual point of view, feature inheritance (I.e., of attribute properties and of connectors) should be orthogonal to the topology of connections in a StructuredClassifier. Resolution: Revised Text: Actions taken: October 11, 2012: received issue Discussion: End of Annotations:===== m: "Rouquette, Nicolas F (313K)" To: Juergen Boldt CC: CUCCURU Arnaud , Steve Cook , "Bock, Conrad" , "Ed Seidewitz" , Burkhart Roger M , Bran Selic Subject: UML2.5, section 11: feature inheritance (of attribute properties, ports and connectors) should be orthogonal to the topology of well-formed connections in a structured classifier Thread-Topic: UML2.5, section 11: feature inheritance (of attribute properties, ports and connectors) should be orthogonal to the topology of well-formed connections in a structured classifier Thread-Index: AQHNp9Cf1LX2DS0tk0i6QDm1NUYQRQ== Date: Thu, 11 Oct 2012 16:51:12 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.149.137.114] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id q9BGqavn001830 Juergen, Can you please file the following issue against UML 2.5, section 11: Title: UML2.5, section 11: feature inheritance (of attribute properties, ports and connectors) should be orthogonal to the topology of well-formed connections in a structured classifier Summary: SysML uses extensively UML's StructuredClassifiers. In UML 2.4.1, the well-formedness constraints for UML's StructuredClassifiers were written in English only. In UML 2.5, the well-formedness constraints have both English descriptions and OCL specifications. Unfortunately, the UML 2.5 OCL specifications for the well-formedness of UML's StructuredClassifiers are too restrictive for SysML in 3 areas: 1) StructuredClassifier::/role is a derived union that is subsetted only once by StructuredClassifier::ownedAttribute. This means that inherited attributes of a StructuredClassifier are not considered to be roles of that StructuredClassifier. 2) StructuredClassifier::/part is derived and the derivation is: ownedAttribute->select(isComposite) This means that inherited attributes of a StructuredClassifier are not considered to be parts of that StructuredClassifier. 3) Connector has a constraint, roles, stated as follows: The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier that owned the Connector, or they must be Ports of such roles. inv: structuredClassifier <> null and end->forAll( e | structuredClassifier.role->includes(e.role) or e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort)) There is a significant conceptual asymmetry between the two disjuncts of the forAll() clause. The first disjunct is: structuredClassifier.role->includes(e.role) This restricts the ConnectableElement to be a role of the StructuredClassifier owning the Connector; that is, the ConnectableElement must be an ownedAttribute of that StructuredClassifier. The second disjunct is: e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort) This also restricts the ConnectableElement::partWithPort to be a role of the StructuredClassifier owning the Connector; however, the ConnectableElement Port may be inherited! (see ConnectorEnd::role_and_part_with_port) The conceptual asymmetry is that it is OK to connect inherited ports of owned attributes but it is not OK to connect inherited attributes. >From a conceptual point of view, UML 2.5 does not provide a rationale for restricting the connectivity of UML StructuredClassifiers to owned attributes only. >From a conceptual point of view, feature inheritance (I.e., of attribute properties and of connectors) should be orthogonal to the topology of connections in a StructuredClassifier. - Nicolas.