Interfaces with external systems should be consistently handled throughout the system, so markers need to be identified
in the architecture to make sure that the team develop the coherant software. The architecture need not include a
specific, detailed design for each system interface. It is often enough to simply identify the existence of the
interfacre as a significant part of the architecture and create a subsystem to encapsulate the detail, so that it can
be developed later.
The Entity-Control-Boundary Pattern provides the basis for a useful technique to
If the system communicates with another system, define one or more boundary classes to describe the communication
protocol. An external 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 that mediates the communication with
the external system will be identified.
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 the customer has sufficient funds to withdrawal the requested amount. The
ATM network is an external system (from the perspective of the ATM); therefore, you would use a
boundary class to represent it in a use-case analysis.
If the interfaces with 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 by 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 models the system interfaces more appropriately.
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 hidden as the system evolves.