Guideline: Representing Interfaces to External Systems |
This guideline introduces system level interfaces.
Relationships
Related Elements | Architecture
Main Description
If the system communicates with another system, there will be one or more boundary classes identified in Design the Solution 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. 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 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.
More Information
Concepts | Entity-Control-Boundary Pattern
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright