Guideline : Representing
Interfaces to External Systems
If the system communicates with another system, there will be one or more
boundary classes identified in
Activity: Use-Case Analysis
to describe the communication protocol. Another system may
be anything from software to hardware units that the current system will use,
such as printers, terminals, alarm devices, and sensors. In each case, a
boundary class will be identified whose purpose is to mediate the communication
with the other system.
Example
An Automated Teller Machine (ATM) must communicate with the
ATM Network to ascertain whether a customer's bank number and PIN are correct,
and whether they have sufficient funds in their account to effect a withdrawal.
Since the ATM Network is an external system (from the perspective of the ATM),
we would use a boundary class to represent it in Use Case
Analysis.
If the interface(s) to the system are simple and well-defined, a single class
may be sufficient to represent the external system. Often, however, these
interfaces are too complex to be represented using a single class; they often
require complex collaborations of many classes. Moreover, interfaces between
systems are often highly reusable across applications. As a result, in many
cases, a subsystem more appropriately models the system interfaces.
The use of a subsystem allows the interface to the external system to be defined
and stabilized, while leaving the design details of the system interface to
remain hidden while its definition evolves.
Design Refinement
A requirement to interface to other systems or devices imposes the need to
be formal in the specification and realization of (UML)
interfaces. In such cases, it is useful to be
very precise about the boundaries of the
system and context in which the system operates. Whereas the
Use-Case Model
shows the behavioral context for the system, a logical model of the system in
its environment, will show:
- The interfaces to be realized and provided by the system (in terms
of the services the system provides-as
operations
or signal
receptions
-the associated protocols supported, and the information exchanged)
- The interfaces required by the system (to be realized by the external
systems that interact with the system) for correct performance. Often, when
the external system exists already, these required and provided interfaces
simply reflect constraints imposed by that other system, because its behavior
cannot be changed
A context diagram can be created to show the top-level collaboration between
the system and other systems or devices. This is the structural analog to the
Use-Case Model for the system. The system services compose to support the use
cases-for example, you can construct a set of
sequence diagrams
showing the interactions between external systems and the system under construction,
to illustrate the messages that are exchanged in the execution of a use case,
and map the messages to operations (or receptions)-note that this is not
the same as a sequence diagram showing a use-case realization, because we do
not show any system internals. The performance of a use-case scenario will typically
involve several system invocations and responses.
This identification of services and their realizations within the system does
not necessarily proceed strictly top-down: in Use-Case Analysis (performed by
the Designer) an initial model of the realizing classes (including the boundary
classes) and collaborations is constructed, taking account of the work done
by the Software Architect in the
Activity: Architectural Analysis. We may iterate
over this analysis and later refine the boundary classes and
the messages that flow across the system boundary-assuming we have the
freedom to do so. When the interface is with an existing external system that
is difficult or impossible to change, the details of the interface (hence the
services to support it) are essentially fixed from the outset, and all we can
do is refine our realization of the interface.
At this top level, the system can be represented as a (UML)
component
(or in UML 2.0 as a
structured class) that realizes interfaces,
defined formally in UML, in support of the external
systems or devices. Further, in UML 2.0, these interfaces can be assigned to
defined interaction points or
ports
on the system boundary. The use of ports allows the Software Architect and Designer
to show how the system's internal components or classes are 'wired' to support
the interfaces. This forms a natural bridge to boundary classes that were identified
in analysis: in the simple case these can be connected to the interfaces they
realize through the ports at the system boundary. In UML 2.0, a further level
of precision is available through
protocol state machines: a protocol state machine
may be associated with an interface or port, and
specifies the legal sequences of invocation of the behavioral features specified
by the interface or supported by the port.
In cases where, as described above, a collaboration is needed to support a
complex interface, that collaboration (evolving from the boundary class originally
identified) can itself be encapsulated as a component (or structured class)
internal to the system-acting as the subsystem described in the first
section-and connected to the port supporting the required interface.
For a detailed treatment of how interfaces may be provided and realized in
a Service-Oriented Architecture, see the white paper "Using
Service-Oriented Architecture and Component-Based
Development to Build Web Service Applications".
|