Specification of an Architecture Meta-Model - SPES 2020
Specification of an Architecture Meta-Model - SPES 2020
Specification of an Architecture Meta-Model - SPES 2020
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Specification</strong> <strong>of</strong> <strong>an</strong> <strong>Architecture</strong> <strong>Meta</strong>-<strong>Model</strong><br />
context Port<strong>Specification</strong> inv notEmptyUnlessRealization:<br />
self .interactionPoint→isEmpty() implies self .isRealization()<br />
2. A Port<strong>Specification</strong> owns either Services or Flows as its interaction point, but<br />
not both.<br />
Formal OCL constraint TBD.<br />
2.1.17.2 InteractionPoint {abstract}<br />
InteractionPoint is <strong>an</strong> abstract class. It has two sub-classes: Flow <strong>an</strong>d Service. Interaction<br />
points aggregate together in a port specification, which is used to type a port. For<br />
<strong>an</strong>y rich component that owns such a port, we also informally say that this component<br />
owns the interaction points: flows <strong>an</strong>d services, <strong>of</strong> the corresponding port specification.<br />
An interaction point c<strong>an</strong> be referred to as <strong>an</strong> end <strong>of</strong> a binding that binds other<br />
ends referring to other interaction points. We say these interaction points are bound.<br />
There are two types <strong>of</strong> bindings: flow bindings <strong>an</strong>d service bindings, to bind flows to<br />
flows, <strong>an</strong>d services to services respectively. For the sem<strong>an</strong>tics <strong>of</strong> bound interaction<br />
points, please refer to individual sub-classes.<br />
Moreover, <strong>an</strong> interaction point c<strong>an</strong> also be referred to as <strong>an</strong> end <strong>of</strong> a link where the<br />
other end referring to a block pin with compatible meta-type, namely flow to flow pin<br />
<strong>an</strong>d service to service pin. In this case, the behavior <strong>of</strong> the owning component on the<br />
interaction point is the same as the behavior <strong>of</strong> the block on the pin. An interaction<br />
point is a named element.<br />
Generalizations: NamedElement<br />
Aggregations<br />
• port<strong>Specification</strong> : Port<strong>Specification</strong> [1] The port specification that owns the<br />
interaction points.<br />
2.1.17.3 Flow<br />
A flow specifies <strong>an</strong> interaction point. A flow is characterized by its data type, its kind,<br />
<strong>an</strong>d its direction. The data type defines the type <strong>of</strong> values that appear on the flow. The<br />
kind defines when values are available on the flow, <strong>an</strong>d how they ch<strong>an</strong>ge. And the<br />
direction defines whether the owning rich component does input/output/both on the<br />
flow.<br />
Bound flows c<strong>an</strong> be considered as one shared communication point among the owning<br />
components. As a consequence, bound flows always have the same values at <strong>an</strong>y<br />
time.<br />
A flow inherits from NavigableFeature. This allows it to initialize flows within the<br />
body <strong>of</strong> <strong>an</strong> Initializer.<br />
42/135