9.3.11 Port

*Generalizations

   •

    Property (from InternalStructures ) on page 190

*Description

   Ports represent interaction points between a classifier and its environment. The interfaces associated with a port specify the nature of the interactions that may occur over a port. The required interfaces of a port characterize the requests that may be made from the classifier to its environment through this port. The provided interfaces of a port characterize requests to the classifier that its environment may make through this port.

   A port has the ability to specify that any requests arriving at this port are handled by the behavior of the instance of the owning classifier, rather than being forwarded to any contained instances, if any.

*Attributes

• isService: Boolean If true, indicates that this port is used to provide the published functionality of a classifier. If false, this port is used to implement the classifier but is not part of the essential externally-visible functionality of the classifier and can, therefore, be altered or deleted along with the internal implementation of the classifier and other properties that are considered part of its implementation. The default value for this attribute is true.

• isBehavior: Boolean Specifies whether requests arriving at this port are sent to the classifier behavior of this classifier (see BehavioredClassifier (from BasicBehaviors , Communications ) on page 451). Such ports are referred to as behavior port. Any invocation of a behavioral feature targeted at a behavior port will be handled by the instance of the owning classifier itself, rather than by any instances that this classifier may contain. The default value is false.

*Associations

• required: Interface References the interfaces specifying the set of operations and receptions that the classifier expects its environment to handle. This association is derived as the set of interfaces required by the type of the port or its supertypes.

• provided: Interface References the interfaces specifying the set of operations and receptions that the classifier offers to its environment, and which it will handle either directly or by forwarding it to a part of its internal structure. This association is derived from the interfaces realized by the type of the port or by the type of the port, if the port was typed by an interface.

• redefinedPort: Port A port may be redefined when its containing classifier is specialized. The redefining port may have additional interfaces to those that are associated with the redefined port or it may replace an interface by one of its subtypes. (Subsets Element::redefinedElement)

*Constraints

   [1] The required interfaces of a port must be provided by elements to which the port is connected.

   [2] Port.aggregation must be composite.

   [3] When a port is destroyed, all connectors attached to this port will be destroyed also.

   [4] A defaultValue for port cannot be specified when the type of the Port is an Interface.

*Semantics

   A port represents an interaction point between a classifier instance and its environment or between a classifier instance and instances it may contain. A port by default has public visibility. However, a behavior port may be hidden but does not have to be.

   The required interfaces characterize services that the owning classifier expects from its environment and that it may access through this interaction point: Instances of this classifier expect that the features owned by its required interfaces will be offered by one or more instances in its environment. The provided interfaces characterize the behavioral features that the owning classifier offers to its environment at this interaction point. The owning classifier must offer the features owned by the provided interfaces.

   The provided and required interfaces completely characterize any interaction that may occur between a classifier and its environment at a port with respect to the data communicated at this port and the behaviors that may be invoked through this port. The interfaces do not necessarily establish the exact sequences of interactions across the port. When an instance of a classifier is created, instances corresponding to each of its ports are created and held in the slots specified by the ports, in accordance with its multiplicity. These instances are referred to as interaction points and provide unique references. A link from that instance to the instance of the owning classifier is created through which communication is forwarded to the instance of the owning classifier or through which the owning classifier communicates with its environment. It is, therefore, possible for an instance to differentiate between requests for the invocation of a behavioral feature targeted at its different ports. Similarly, it is possible to direct such requests at a port, and the requests will be routed as specified by the links corresponding to connectors attached to this port. (In the following, requests arriving at a port shall mean request occurrences arriving at the interaction point of this instance corresponding to this port.)

   The interaction point object must be an instance of a classifier that realizes the provided interfaces of the port. If the port was typed by an interface, the classifier typing the interaction point object realizes that interface. If the port was typed by a class, the interaction point object will be an instance of that class. The latter case allows elaborate specification of the communication over a port. For example, it may describe that communication is filtered, modified in some way, or routed to other parts depending on its contents as specified by the classifier that types the port.

   If connectors are attached to both the port when used on a property within the internal structure of a classifier and the port on the container of an internal structure, the instance of the owning classifier will forward any requests arriving at this port along the link specified by those connectors. If there is a connector attached to only one side of a port, any requests arriving at this port will terminate at this port.

   For a behavior port, the instance of the owning classifier will handle requests arriving at this port (as specified in the behavior of the classifier, see Chapter 13, Common Behaviors), if this classifier has any behavior. If there is no behavior defined for this classifier, any communication arriving at a behavior port is lost.

*Semantic Variation Points

   If several connectors are attached on one side of a port, then any request arriving at this port on a link derived from a connector on the other side of the port will be forwarded on links corresponding to these connectors. It is a semantic variation point whether these requests will be forwarded on all links, or on only one of those links. In the latter case, one possibility is that the link at which this request will be forwarded will be arbitrarily selected among those links leading to an instance that had been specified as being able to handle this request (i.e., this request is specified in a provided interface of the part corresponding to this instance).

*Notation

Issue 7973 -The placement of a port is independent of its visibility. Modifying text to reflect this.

   A port of a classifier is shown as a small square symbol. The name of the port is placed near the square symbol. The port symbol may be placed either operlapping the boundary of the rectangle symbol denoting that classifier or it may be shown inside the rectangle symbol.

   A port of a classifier may also be shown as a small square symbol overlapping the boundary of the rectangle symbol denoting a part typed by that classifier (see Figure 9.16). The name of the port is shown near the port; the multiplicity follows the name surrounded by brackets. Name and multiplicity may be elided.

   The type of a port may be shown following the port name, separated by colon (:). A provided interface may be shown using the lollipop notation (see Interface (from Interfaces ) on page 87) attached to the port. A required interface may be shown by the socket notation attached to the port. The presentation options shown there are also applicable to interfaces of ports. Figure 9.16 shows the notation for ports: p is a port on the Engine class. The provided interface (also its type) of port p is powertrain. The multiplicity of p is 1. In addition, a required interface, power, is shown also. The figure on the left shows the provided interface using the lollipop notation, while the figure on the right shows the interface as the type of the port.

   powertrain

   p [1]

*Presentation Options

   The name of a port may be suppressed. Every depiction of an unnamed port denotes a different port from any other port.

   If there are multiple interfaces associated with a port, these interfaces may be listed with the interface icon, separated by commas. Figure 9.18 below shows a port OnlineServices on the OrderProcess class with two provided interfaces, OrderEntry and Tracking, as well as a required interface Payment.

   Online

   OrderEntry,

   OrderProcess

   Figure 9.18 - Port notation showing multiple provided interfaces

*Examples

   Figure 9.19 - Port examples

    Figure 9.19 shows a class Engine with a port p with a provided interface powertrain. This interface specifies the services that the engine offers at this port (i.e., the operations and receptions that are accessible by communication arriving at this port). The interface power is the required interface of the engine. The required interface specifies the services that the engine expects its environment to provide. At port p, the Engine class is completely encapsulated; it can be specified without any knowledge of the environment the engine will be embedded in. As long as the environment obeys the constraints expressed by the provided and required interfaces of the engine, the engine will function properly.

   Two uses of the Engine class are depicted: Both a boat and a car contain a part that is an engine. The Car class connects port p of the engine to a set of wheels via the axle. The Boat class connects port p of the engine to a propeller via the shaft. As long as the interaction between the Engine and the part linked to its port p obeys the constraints specified by the provided and required interfaces, the engine will function as specified, whether it is an engine of a car or an engine of a boat. (This example also shows that connectors need not necessarily attach to parts via ports (as shown in the Car class.)

*Changes from previous UML

   This metaclass has been added to UML.