Handle implicit specializations from standard libraries for Usages/Definitions

[AxelRICHARD]

Usages/Definitions have implicit specializations, depending on their related types or depending on where they are located in a model:

7.6.1 Definition and Usage Overview

A usage can also be contained directly in an owning package. In this case, the usage element is considered to be an implicit feature of the most general kernel type Anything. That is, a package-level usage is essentially a generic feature that can be applied in any context, or further specialized in specific contexts (as described under Specialization below).

7.6.8 Implicit Specialization

In particular, if a definition or usage, as explicitly declared, does not directly or indirectly specialize the required base definition or usage, then the declaration is considered to include an implicit subclassification or subsetting of the appropriate base definition or usage.

7.16.7 Send Action Usages

The base send action usage is sendActions from the Actions library model (see 9.2.9), which is defined by SendAction.

7.16.8 Accept Action Usages

The base accept action usage is acceptActions from the Actions library model (see 9.2.9), which is defined by AcceptAction.

7.16.9 Assignment Action Usages

The base assignment action usage is assignmentActions from the Actions library model (see 9.2.9).

7.16.10 If Action Usages

An if action usage is an action usage that is implicitly defined by one of the action definitions IfThenAction or IfThenElseAction from the Actions model (see 9.2.9).

7.16.11 Loop Action Usages

A loop action usage is an action usage that is implicitly defined by one of the concrete specializations of the abstract action definition LoopAction from the Actions model (see 9.2.9).

7.17.3 Transition Usages

A transition usage is implicitly defined by the action definition StateTransitionAction from the States library model (see 7.17).

8.3.11.3 PartUsage

A PartUsage must directly or indirectly specialize the PartUsage Parts::parts from the Systems Model Library.

A composite PartUsage whose owningType is a ItemDefinition or ItemUsage must directly or indirectly specialize the PartUsage Items::Item::subparts from the Systems Model Library.

8.3.12.6 PortUsage

A PortUsage must directly or indirectly specialize the PortUsage Ports::ports from the Systems Model Library.

A composite PortUsage with an owningType that is a PortDefinition or PortUsage must directly or indirectly specialize the PortUsage Ports::Port::subports from the Systems Model Library.

8.3.13.4 ConnectionUsage

A ConnectionUsage must directly or indirectly specialize the ConnectionUsage Connections::connections from the Systems Model Library.

8.3.13.7 FlowConnectionUsage

If a FlowConnectionUsage has no itemFlowEnds, then it must directly or indirectly specialize the base FlowConnectionUsage Connections::messageConnections from the Systems Library model. Otherwise, it must directly or indirectly specialize the FlowConnectionUsage Connections::flowConnections.

8.3.13.9 SuccessionFlowConnectionUsage

A SuccessionFlowConnectionUsage must directly or indirectly specialize the base FlowConnectionUsage Connections::successionFlowConnections from the Systems Library model.

8.3.14.3 InterfaceUsage

An InterfaceUsage must directly or indirectly specialize the InterfaceUsage Interfaces::interfaces from the Systems Model Library.

8.3.15.3 AllocationUsage

An AllocationUsage must directly or indirectly specialize the AllocationUsage Allocations::allocations from the Systems Model Library.

8.3.16.2 AcceptActionUsage

An AcceptActionUsage that is the triggerAction of TransitionUsage must directly or indirectly specialize the ActionUsage Actions::TransitionAction::accepter from the Systems Model Library.

An AcceptActionUsage that is not the triggerAction of a TransitionUsage must directly or indirectly specialize the ActionUsage Actions::acceptActions from the Systems Model Library. ...