Definition
According to UML ([UML04]), a Class is a subtype of both EncapsulatedClassifier and
metaclass Class, which brings to a Class the capability to have an internal structure and ports. Also, a
component is defined by UML as a subtype of Class. Therefore, within RUP context, we refer to both
components and classes as being structured classes.
Part
An instance of a structured class contains an object or set of objects corresponding to each part. All such
instances are destroyed when the containing structured class instance is destroyed.
The example below shows two possible views of the Car class:
In figure (a), Car is shown as having a composition association with role name
rear to a class Wheel and a composition association with role name
e to a class Engine. Any instance of class Engine
can be linked to an arbitrary number of instances of class Wheel.
In figure (b), the same is specified. However, in addition, in figure (b) it is specified that:
-
rear and e belong to the internal structure of the class
Car. This allows specification of detail that holds only for instances of the
Wheel and Engine classes within the context of the class
Car, but which does not hold for wheels and
engines in general.
-
within the context of class Car, the instance playing the role of
e may only be connected to two instances playing the role of
rear. In addition, the instances playing the e and
rear roles may only be linked if they are roles of the same instance of class
Car.
-
In other words, additional constraints apply on the instances of the classes Wheel
and Engine, when they are playing the respective roles within an instance of class
Car. These constraints are not true for instances of Wheel and
Engine in general. Other wheels and engines may
be arbitrarily linked as specified in the figure (a).
Example: Parts playing their roles inside a structured class
Connector
A connector is an instance of relationship between two parts in a structured class. It is a link to allow
communication. Connectors may be implemented by ordinary associations or by transient relationships, such
as procedure parameters, variables, global values, or other mechanisms.
The internal "wiring" of a structured class is specified with assembly connectors and delegation
connectors:
-
Within the implementation of a structured class, assembly connectors connect ports of
different parts. A message sent on a port of one structured class is received on a connected port of
another structured class. A set of parts may be wired together through their ports. A part need not
know anything about other parts, except that they exist and satisfy the constraints on connected ports.
Communication among structured classes is modeled by their ports.
-
-
A delegation connector connects an external port of a structured class with a port on
one of its internal parts. A message received by the external port is passed to the port on the
internal part; a message sent by the internal port is passed to the external port and then to the
structured class connected to it.
Port
A port is a structural feature of a structured class. Encapsulation can be increased by forcing
communications from outside the structured class to pass through ports obeying declared interfaces, which
brings additional precision in specification and interconnection for that structured 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 structured class with its environment are achieved
through ports, then the internals of the structured class are fully isolated from the environment. This
allows such a structured class to be used in any context that satisfies the constraints specified by its
ports.
There is no assumption about how a port is implemented. It might be implemented as an explicit object, or
it might be merely a virtual concept that does not explicitly appear in the implementation.
Examples of ports are provided below:
Example 1
Port of an Engine being used by a Car and a Boat
The figure above shows a class Engine with a port p and two interfaces:
-
A provided interface powertrain, which 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).
-
A required interface power, which 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.
To illustrate that, two uses of the Engine class are shown in this example:
-
The Car class connects port p of the engine to a set of wheels by
means of the axle.
-
The Boat class connects port p of the engine to a propeller by means
of 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.
Furthermore, even if Engine had other declared ports, such as a port f
for Fuel Consumption, the wheels of a car and the propeller of a boat would still access
the Engine through port p. Port f would be of interest
of a fuel meter, regardless of what kind of fuel is being used and what kind of fuel meter cars and boats
might have.
Example 2
This example of ports is based on Java Logging API ([JAV03]), which is a package that provides the following classes and
interfaces of the Java 2 platform's core logging facilities, among others:
-
Logger is the main entity on which applications make logging calls. It is used to log
messages for a specific system or application component
-
Level gives a guide to the importance and urgency of a log message
-
Filter provides fine grain control of what is logged, beyond the control provided by
the log levels
-
Handler takes messages from a Logger and exports them to different destinations
(memory, output streams, consoles, files and sockets)
-
Formatter provides support for formatting log records
Those classes and interfaces are involved in two important kinds of collaborations. Some classes and
interfaces are used to write to the log while others are used to administrate the log. The figure below
shows two different collaborations that clients and administrators have with the log, modeled as UML
collaborations:
-
Writing collaboration, where the LogClient role connects to the
LogWriter role in order to write to the log.
-
Administration collaboration, where the LogAdministrator role
connects to the LogController role in order to access the log and change log
settings.
Different collaborations that clients and administrators have with the log
One possible UML 2.0 representation to model the logging services and its collaborations would be using a
component with ports and declared interfaces, as shown in the figure below:
Java Logging API package being implemented as a component with provided interfaces grouped into ports
In the Java Logging API specification, some of the logging services were implemented as classes and others
as interfaces. In this example, we model each of those services as provided interfaces, which could be
realized by parts inside the component. The two different kinds of behavior related to
Writing and Administration collaborations mentioned above could be
represented by interfaces logically grouped into ports. Therefore, we have:
-
Logger and Level interfaces grouped into LogWriter
port. Those interfaces are accessed by log clients to write to the
log.
-
Handler, Filter and Formatter interfaces grouped
into LogController port. Those interfaces are accessed by log administrators to access
the log and change log settings.
This modeling alternative brings a separation of concerns, by logically grouping interfaces into different
ports. We have additional precision for the component specification and the interconnection it can have
with the external world.
Modeling
During design, classes and components may be decomposed into collections of connected parts that may be
further decomposed in turn.
A composite structure diagram can be used to show the decomposition of a structured class.
As an example, the figure below shows a composite structure diagram for the box office in the ticketing
system. This class is decomposed into three parts:
-
A ticket seller interface
-
A performance guide that retrieves performances according to date and other criteria
-
A set of databases that contain the data on the performances and the tickets.
Each part interacts through a well-defined interface specified by its ports. The entire box office
interacts with the outside through a port. Messages on this port are dispatched to the ticket seller class,
but the internal structure of the box office class is hidden from outside clients.
Example: Composite structure diagram for a ticketing system.
UML 1.x Representation
Note that Structured Class is a new concept in UML 2.0.
Much of what RUP defines as Capsule can be represented using Structured Class
as notation (see Work Product: Capsule and Guideline: Capsule for more information
on this topic).
If your tool supports only UML 1.5, an alternative representation is also discussed in Work Product: Capsule and Guideline: Capsule.
Refer to Differences Between UML 1.x and UML 2.0 for more information.
|