Concepts: Structured Class
Topics
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
Artifact: Capsule and Guidelines:
Capsule for more information on this topic).
If your tool supports only UML 1.5, an alternative representation is also discussed
in Artifact: Capsule and Guidelines:
Capsule.
Refer to Differences Between UML
1.x and UML 2.0 for more information.
|