Concepts:  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.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process