| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>\openup_basic\guidances\guidelines\repres_interfaces_to_ext_systems.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: repres_interfaces_to_ext_systems.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_0gjdYMlgEdmt3adZL5Dmdw CRC: 196640360 -->Representing Interfaces to External Systems<!-- END:presentationName,_0gjdYMlgEdmt3adZL5Dmdw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_0gjdYMlgEdmt3adZL5Dmdw CRC: 307037135 -->This guideline introduces system level interfaces.<!-- END:briefDescription,_0gjdYMlgEdmt3adZL5Dmdw --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,_iCwb8MM3EdmSIPI87WLu3g CRC: 2615218417 --><p> |
| 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. |
| </p> |
| <p> |
| The <a class="elementLink" |
| href="./../../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" |
| guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> provides the basis for a useful technique to |
| support this. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| Example: |
| </p> |
| <blockquote> |
| <p> |
| 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 |
| <strong>boundary</strong> class to represent it in a use-case analysis. |
| </p> |
| </blockquote> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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.<br /> |
| </p><!-- END:mainDescription,_iCwb8MM3EdmSIPI87WLu3g --> |
| </body> |
| </html> |
