指南:针对外部系统的表示接口
如果该系统与另一个系统通信,将有一个或多个在活动:用例分析中确定的边界类来描述通信协议。另一系统可能是当前系统将要使用的、从软件部件到硬件部件的任何事物,例如打印机、终端设备、警报设备和传感器。在每种情况下,都将确定一个边界类,作为与其它系统通信的媒介。
示例
自动提款机(ATM)必须与 ATM 网络进行通信,以确定客户的银行号码和 PIN 号码正确,以及客户帐户中是否有足够的金额使提款生效。
由于 ATM 网络是外部系统(从 ATM 的角度来看),我们将在“用例分析”中使用边界类来表示 ATM 网络。
如果系统的接口简单而明确,单个类可能就足以代表外部系统。但是,这些接口常常过于复杂而无法使用单个类来表示它们;它们常常需要许多类的复杂协作。此外,系统之间的接口在众多应用程序中常常是高度可重用的。因此,在许多情况下,子系统更适合对系统接口建模。
子系统的使用允许定义和稳定外部系统的接口,在改进系统定义的同时使系统接口的设计详细信息保持隐藏状态。
设计改进
如果需要与其它系统或设备的接口,则会强制需要在(UML)接口的规范和实现中正式化。在这样的情况下,使系统和系统所处环境的边界非常精确是很有用的。用例模型显示系统的行为环境,而系统环境中的系统逻辑模型将显示:
- 由系统实现和提供的接口(从系统作为操作或信号接收提供的服务、支持的关联协议和交换的信息方面)
- 为使性能正确,系统所需的接口(由与该系统交互的外部系统实现)。通常,当外部系统已存在时,这些所需和提供的接口只反映其它系统强加的约束,因为它的行为不能更改
可以创建环境图来显示系统和其它系统或设备之间的顶级协作。这是按照系统用例模型的结构模拟。系统服务组合在一起以支持用例,例如可以构造一组显示外部系统和被构建系统之间的交互的序列图,以说明用例执行过程中交换的消息,并将这些消息映射到操作(或接收)- 请注意,这与显示用例实现的序列图不同,因为我们不显示任何系统内部成分。用例场景的性能通常将涉及几个系统调用和响应。
服务的这种确定以及服务在系统中的实现不必严格按自顶向下的方式进行:在用例分析(由设计人员执行)中,会构造实现类(包括边界类)和协作的初始模型,在这中同时考虑到软件设计人员在活动:体系结构分析中所做的工作。我们可以重复此分析,然后优化边界类和流经系统边界的消息(假设我们有权这样做)。当接口属于很难或不可能改变的现有外部系统时,接口(因而也包括支持它的服务)的详细信息从一开始就基本固定了,我们所能做的就是优化接口的实现。
在这个顶级,系统可表示为实现接口的(UML)组件(或在 UML 2.0 中表示为结构化的类),正式地定义在 UML 中,并支持外部系统或设备。此外,在 UML 2.0 中,这些接口可分配给在系统边界上定义的交互点或端口。端口的使用使软件设计人员和设计人员能够显示系统的内部组件或类是如何“连接”以支持接口的。这很自然地连接了在分析中确定的边界类:简单的情况下,可通过系统边界处的端口将这些类连接到它们实现的接口。在 UML 2.0 中,通过协议状态机可进一步提供精确性,协议状态机可与接口或端口关联,并可指定由接口指定或端口支持的行为特性的合法调用顺序。
在上述情况下,需要用协作来支持复杂接口,可将协作(由初始确定的边界类发展而来)作为系统内部的组件(或结构化的类)来加以包含 - 作为在第一节中描述的子系统,并连接到支持所需接口的端口。
有关在面向服务的体系结构中可如何提供和实现接口的详细处理,请参阅白皮书"使用面向服务的体系结构和基于组件的开发来构建 Web 服务应用程序。"
|