基于Rhapsody和VxWorks的自动取款机系统
第三步：设计子系统图。
??下一步是如何把模型分割成子系统。在UML中，一个子系统作为一个封装显示，即主要是一个类的集合。图4的子系统图表明自动取款机系统已经被分解成两个基本的部分：自动柜员机封装(AtmerPkg)和硬件封装(HardharePkg)。同时也表明：自动柜员机封装是完全独立于实际的硬件和硬件封装的，并且实现了Ihardware接口能够用于连接自动柜员机封装。接口类Ihardware描述了对自动柜员机封装的所有必需的操作，实现了应用与硬件环境的隔离。
??一旦在自动柜员机封装和硬件封装之间定义了接口类，每一个子系统就能同步和独立地细化为更多的子系统。每一个子系统都知道它和其它子系统之间的接口。例如，我们可以开始分析自动柜员机子系统图，而不需要知道关于硬件的更多情况。
第四步：设计对象模型图。
??对自动柜员机封装而言，我们设想有一个AtmerController类，其中包含Keypad类、Card类、LCD类和Cash类，这些类表示如图5所示。
??图5表明：AtmerController类作为一个聚合类，包含了其它类的实例。我们也能看出，我们能选择显示“Keypad”类的不同的操作和属性。在上面的例子中，假如一个实例被AtmerControlle类创建，那么它将创建Keypad类的一个实例theKeypad、LCD类的一个实例theLCD、Cash类的一个实例theCash以及Card类的一个实例theCard。假如AtmerController类的实例被删除，这些包含的实例也同时被删除。
??Ihardware类也有一些纯虚函数，所以为了测试AtmerController类，必须忽略这些操作。图6表示：ATM包含了AtmerController类的一个实例和从Ihardware类继承并忽略了其操作的Hw类的一个实例。
第五步：生成白匣子场景。
??生成了一个新类AtmerController后，就可以开始为每一个黑匣子场景生成白匣子场景。消息序列表将用于获取以上不同场景的类的实例之间的通信行为。例如，图7消息序列描述了顾客输入支取现金数额并取出现金的场景。
??消息通常对应于对象模型中操作和操作的返回值。消息值对应于类的属性或是类操作的返回值。消息可以是同步的，也可以是异步的。从图中可以看出，这些类都有动态行为：它们正在处理定时事件；调用其它类的操作；接受事件。对UML来说，这些动态行为都可以用一个状态图来表示。
第六步：创建状态图。
??以顾客输入密码过程为例，创建状态图，如图8所示。通常，当一个问题很复杂时，它往往被分解成一些简单的问题，这也正是对顾客输入密码过程要做的事情。图8所示的状态图描述了顾客输入密码过程中的行为。
图7 顾客输入支取数据并取出现金的白匣子场景
2.3 属性、操作和事件
??属性来源于需求文档中定义的数据，应该简单，不考虑设计和实现的细节。每个类都可能有定义在其上的事件和操作。事件对应于明确的瞬时发生的影响类的动态行为。操作对应于类的服务和功能。Rhapsody中有3种事件。
① 信号事件：对应于实例间的异步通信。
② 时间事件：这种事件在进入一个状态并且经过一个指定的时间后触发。
③ 触发操作：触发操作是同步的操作，通过能够迅速得到响应的事件得到执行。触发操作没有实现代码，却可以作为类的状态图转移的触发器。当调用触发操作时，同时产生响应的事件。
2.4 生成代码
??一般嵌入式应用中有60%~90%的代码用于内务处理（如状态图的实现、任务间的通信等），这些代码在设计新的系统时一般都可以重用。这种重用一般是通过实时框架来实现的。Rhapsody就提供了这样一个实
《基于Rhapsody和VxWorks的自动取款机系统(第2页)》
★读了本文的人也读了：