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".

Rational Unified Process   2003.06.15