Test 2 / SysML : Basic Component Interface

Overview

This test is designed to assess the tool's ability to exchange information about interfaces between components. Type constraints that ensure compatibility among the things conveyed between connected ports is essential to tasks such as system-of-systems analysis. The test is a first step toward assessment of that ability.

Test Data

The following SysML diagrams describe the information to be exchanged. Modeling of the ValueType 'Torque,' (possibly in the 'ValueTypes' package depicted below) is not critical to the exercise.

Constraints (9.3.2.5)

[1] A FlowPort must be typed by a FlowSpecification, Block, Signal, DataType, or ValueType.

[2] If the FlowPort is Atomic (i.e., typed by a Block, Signal, DataType, or ValueType), then isAtomic=True, the multiplicity of Direction is one, and the multiplicity of isConjugated is zero.

[3] If the FlowPort is Non-Atomic (i.e., typed by a FlowSpecification), then isAtomic=False, the multiplicity of Direction is zero, and the multiplicity of isConjugated is one.

[4] A Flow Port can be connected (via connectors) to one or more flow ports that have matching flow properties. The matching of flow properties is done in the following steps:

1. Type Matching: The type being sent is the same type or a sub-type of the type being received
2. Direction Matching: If the connector connects two parts that are external to one another then the direction of the flow properties must by opposite, or at least one of the ends should be inout. If the connector is internal to the owner of one of the flow ports, then the direction should be the same or at least one of the ends should be inout
3. Name Matching: In case there is type and direction match to several flow properties at the other end, the property that have the same name at the other end is selected. If there is no such property then the connection is ambiguous (ill-formed)

Plugfest notes

Normative OCL for the constraints described above does not exist. The Validator will implement the following, (which will be validated, and possibly, recommended to the SysML RTF). Note that it currently is *not* validated, and participants shouldn't worry too much if their exchange files don't pass these constraints. (Update: As of 2007-05-14 these constraints have not been implemented in the Validator.)

• [1] A FlowPort must be typed by a FlowSpecification, Block, Signal, DataType, or ValueType.
  On FlowPort :
  type.oclIsKindOf(FlowSpecification) or type.oclIsKindOf(Block) or type.oclIsKindOf(Signal) or type.oclIsKindOf(DataType) or type.oclIsKindOf(ValueType)
• [2] If the FlowPort is Atomic (i.e., typed by a Block, Signal, DataType, or ValueType), then isAtomic=True, the multiplicity of Direction is one, and the multiplicity of isConjugated is zero.
  On FlowPort :
  self.isAtomic() implies self.direction.size() = 1 and self.isConjugated.size() = 0
• [3] If the FlowPort is Non-Atomic (i.e., typed by a FlowSpecification), then isAtomic=False, the multiplicity of Direction is zero, and the multiplicity of isConjugated is one.
  On FlowPort :
  not self.isAtomic() implies self.direction.size() = 0 and self.isConjugated.size() = 1
• [4.1] The type being sent is the same type or a sub-type of the type being received.
  On ItemFlow :
  self.informationSource.type.oclAt(1).oclIsKindOf(oclType(self.informationTarget.oclAt(1).type))
  Note: Limitations: (1) This only checks that both source and target use just one of FlowSpecification, Signal, DataType, or ValueType. We could further check, for example, if it were a ValueType, that the types had the same dimension and units. (2) This only checks one FlowPort in the source (the first) against one FlowPort in the target. (3) It is not clear whether oclType is a method in the current version of OCL.
• [4.2.a] If the connector connects two parts that are external to one another, then the direction of the flow properties must by opposite, or at least one of the ends should be INOUT.
  It is unclear why realizingConnector is (0,*). Shouldn't it be (1,*)?
  
  N.B, The following only pertains to Connectors with exactly two .end ConnectorEnds.
  
  On ItemFlow :
  let end1 : ConnectorEnd = self.realizingConnector.end.oclAt(1) in
  let end2 : ConnectorEnd = self.realizingConnector.end.oclAt(2) in
  self.realizingConnector.end.size() = 2 implies
  (not end1.role.owner.containsBlock(end2.role.owner)) and
  (not end2.role.owner.containsBlock(end1.role.owner)) implies
  (end1.role.direction = IN and end2.role.direction = OUT) or
  (end1.role.direction = OUT and end2.role.direction = IN) or
  end1.role.direction = INOUT OR
  end2.role.direction = INOUT
• [4.2.b] If the connector is internal to the owner of one of the flow ports, then the direction should be the same or at least one of the ends should be inout.
  N.B, The following only pertains to Connectors with exactly two .end ConnectorEnds.
  
  On ItemFlow :
  let end1 : ConnectorEnd = self.realizingConnector.end.oclAt(1) in
  let end2 : ConnectorEnd = self.realizingConnector.end.oclAt(2) in
  self.realizingConnector.end.size() = 2 implies
  end1.role.owner.containsBlock(end2.role.owner) or
  end2.role.owner.containsBlock(end1.role.owner)
  implies
  (end1.role.direction = IN and end2.role.direction = IN) or
  (end1.role.direction = OUT and end2.role.direction = OUT) or
  end1.role.direction = INOUT OR
  end2.role.direction = INOUT
• [4.3] In case there is type and direction match to several flow properties at the other end, the property that have the same name at the other end is selected.
  That is a note about the semantics, not a constraint specification. A constraint we might suggest here is (roughly!) 'If the end.role.direction is OUT or INOUT, there must either be a single IN or INOUT end to which it connects, or there must be a IN or INOUT end of the Connector of the same name as that of the subject end.'
• Constraint [4] above uses a function containsBlock defined as:
  
  On Block :
  def containsBlock(b : Block;) : Boolean
  (not self = b) and self.isOrContainsBlock(b)
  
  def isOrContainsBlock(b : Block) : Boolean
  self = b or
  self.ownedAttribute->select(bp : bp.oclIsKindOf(BlockProperty))
  ->select(p : p.type.oclIsKindOf(Block))->exists(child : child.isOrContainsBlock(b)))
• The derivation of FlowPort.isAtomic() is:
  type.oclIsKindOf(Block) or type.oclIsKindOf(Signal) or type.oclIsKindOf(DataType) or type.oclIsKindOf(ValueType)
• The UML metamodel declares that EncapsulatedClassifier.ownedPort is derived. It does not provide a derivation. The UML used in the Validator assumes it is not derived. Report possible bug to UML RTF

---

Send questions or comments to se-interop@nist.gov.
Date Created: April 24, 2006
Last Modified: July 27, 2009