|Previous||UML Classes||Table of Contents||UML Packages||Next|
A port is a property of a classifier that specifies a distinct interaction point between that classifier and its environment
or between the (behavior of the) classifier and its internal parts. Ports are connected to properties of the classifier by
connectors through which requests can be made to invoke the behavioral features of a classifier. A Port may specify the services
a classifier provides (offers) to its environment as well as the services that a classifier expects (requires) of its environment.
Property (from InternalStructures ) on page 190
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.
• 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.
• 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)
 The required interfaces of a port must be provided by elements to which the port is connected.
 Port.aggregation must be composite.
 When a port is destroyed, all connectors attached to this port will be destroyed also.
 A defaultValue for port cannot be specified when the type of the Port is an Interface.
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.
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).
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.
p: powertrain 
Figure 9.16 - Port notation
A behavior port is indicated by a port being connected through a line to a small state symbol drawn inside the symbol representing
the containing classifier
. (The small state symbol indicates the behavior of the containing classifier.) Figure
shows the behavior port p, as indicated by its connection to the state symbol representing the behavior of the Engine class.
Its provided interface is powertrain. In addition, a required interface, power, is shown also.
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
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.
Figure 9.18 - Port notation showing multiple provided interfaces
|rear : Wheel ||axle||p||e : Engine|
|: Propeller||shaft||p||e : Engine|
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.)
The required and provided interfaces of a port specify everything that is necessary for interactions through that interaction
point. If all interactions of a classifier with its environment are achieved through ports, then the internals of the classifier
are fully isolated from the environment. This allows such a classifier to be used in any context that satisfies the constraints
specified by its ports.
This metaclass has been added to UML.