面向对象分析案例：银行储蓄系统

《面向对象分析案例：银行储蓄系统》由会员分享，可在线阅读，更多相关《面向对象分析案例：银行储蓄系统（82页珍藏版）》请在装配图网上搜索。

1、面向对象分析 1 基本过程 2 需求陈述 3 建立对象模型 4 建立动态模型 5 建立功能模型 6 定义服务 1 面向对象分析的基本过程 面向对象分析，就是抽取和整理用户 需求并建立问题域精确模型的过程。 通常，面向对象分析过程从分析陈述 用户需求的文件开始； 接下来，系统分析员应该深入理解用 户需求，抽象出目标系统的本质属性，并 用模型准确地表示出来。 在面向对象建模的过程中，系统分析员必 须认真向领域专家学习。 在面向对象建模的过程中，还应该仔细研 究以前针对相同的或类似的问题域进行面向对 象分析所得到的结果。由于面向对象分析结果 的稳定性和可重用性，这些结果在当前项目中 往往有许多是可以

2、重用的。 面向对象建模得到的模型包含系统的 3个 要素，即静态结构 (对象模型 )、交互次序 (动 态模型 )和数据变换 (功能模型 )。动态模型和 功能模型中都包含了对象模型中的操作 (即服 务或方法 )。 复杂问题（大型系统）的对象模型通常由下 述 5个层次组成： 主题层、类与对象层、结 构层、属性层和服务层。 3个子模型与 5个层次 复杂问题的对象模型的 5个层次 在概念上可以认为，面向对象分析大体上按 照下列顺序进行：寻找类与对象，识别结构， 识别主题，定义属性，建立动态模型，建立功 能模型，定义服务。 通常，需求陈述的内容包括：问题范 围，功能需求，性能需求，应用环境及假设 条件等。

3、总之，需求陈述应该阐明 “ 做什 么 ” 而不是 “ 怎样做 ” 。它应该描述用户的 需求而不是提出解决问题的方法。应该指出 哪些是系统必要的性质，哪些是任选的性 质。 2 需求陈述 2.1 书写要点 对系统性能及系统与外界环境交互协议的描 述，是合适的需求。此外，对采用的软件工程标 准、模块构造准则、将来可能做的扩充以及可维护 性要求等方面的描述，也都是适当的需求。 系统分析员必须与用户及领域专家密切配合协同 工作，共同提炼和整理用户需求。在这个过程中， 很可能需要快速建立起原型系统，以便与用户更有 效地交流。 2.2 ATM系统案例 ATM系统 某银行拟开发一个自动取款机系统，它是一个由

4、自动取款机、中央计算机、分行计算机及柜员终端组 成的网络系统。 ATM和中央计算机由总行投资购买。 总行拥有多台 ATM，分别设在全市各主要街道上。分 行负责提供分行计算机和柜员终端。柜员终端设在分 行营业厅及分行下属的各个储蓄所内。该系统的软件 开发成本由各个分行分摊。 银行柜员使用柜员终端处理储户提交的储蓄事务。 储户可以用现金或支票向自己拥有的某个账户内存款 或开新账户。储户也可以从自己的账户中取款。通常， 一个储户可能拥有多个账户。柜员负责把储户提交的 存款或取款事务输进柜员终端，接收储户交来的现金 或支票，或付给储户现金。 柜员终端与相应的分行计算机通信，分行 计算机具体处理针对某个

5、账户的事务并且维护 账户。 拥有银行账户的储户有权申请领取现金兑 换卡。使用现金兑换卡可以通过 ATM访问自 己的账户。目前仅限于用现金兑换卡在 ATM 上提取现金 (即取款 )，或查询有关自己账户的 信息 (例如，某个指定账户上的余额 )。 所谓现金兑换卡就是一张特制的磁卡，上 面有分行代码和卡号。分行代码惟一标识总行 下属的一个分行，卡号确定了这张卡可以访问 哪些账户。通常，一张卡可以访问储户的若干 个账户，但是不一定能访问这个储户的全部账 户。每张现金兑换卡仅属于一个储户所有，但 是，同一张卡可能有多个副本，因此，必须考 虑同时在若干台 ATM上使用同样的现金兑换 卡的可能性。也就是说，

6、系统应该能够处理并 发的访问。 当用户把现金兑换卡插入 ATM之后， ATM就 与用户交互，以获取有关这次事务的信息，并与中 央计算机交换关于事务的信息。首先， ATM要求用 户输入密码，接下来 ATM把从这张卡上读到的信息 以及用户输入的密码传给中央计算机，请求中央计 算机核对这些信息并处理这次事务。中央计算机根 据卡上的分行代码确定这次事务与分行的对应关 系，并且委托相应的分行计算机验证用户密码。如 果用户输入的密码是正确的， ATM就要求用户选择 事务类型 (取款、查询等 )。当用户选择取款时， ATM请求用户输入取款额。最后， ATM从现金出 口吐出现金，并且打印出账单交给用户。 3

7、建立对象模型 3.1 确定类与对象 1. 找出候选的类与对象 对象是对问题域中有意义的事物的抽象，它 们既可能是物理实体，也可能是抽象概念。 具体地说，大多数客观事物可分为下述 5类： (1) 可感知的物理实体，例如，飞机、汽车、书、 房屋等等。 (2) 人或组织的角色，例如，医生、教师、雇主、 雇员、计算机系、财务处等等。 (3) 应该记忆的事件，例如，飞行、演出、访问、 交通事故等等。 (4) 两个或多个对象的相互作用，通常具有交易或 接触的性质，例如，购买、纳税、结婚等等。 (5) 需要说明的概念，例如，政策、保险政策、版 权法等等。 在分析所面临的问题时，可以参照上列 5类常见事 物，

8、找出在当前问题域中的候选类与对象。 非正式分析：这种分析方法以用自然语言书写 的需求陈述为依据，把陈述中的名词作为类与 对象的候选者，用形容词作为确定属性的线索， 把动词作为服务 (操作 )的候选者。 下面以 ATM系统为例，可以把它们作为类与 对象的初步的候选者： 银行，自动取款机 (ATM)，系统，中央计算机， 分行计算机，柜员终端，网络，总行，分行， 软件，成本，市，街道，营业厅，储蓄所，柜 员，储户，现金，支票，账户，事务，现金兑 换卡，余额，磁卡，分行代码，卡号，用户， 副本，信息，密码，类型，取款额，账单，访 问。 通常，在需求陈述中不会一个不漏地写出 问题域中所有有关的类与对象，

9、因此，分析员 应该根据领域知识或常识进一步把隐含的类与 对象提取出来。例如，在 ATM系统的需求陈述 中虽然没写 “ 通信链路 ” 和 “ 事务日志 ” ，但 是，根据领域知识和常识可以知道，在 ATM系 统中应该包含这两个实体。 2. 筛选出正确的类与对象 筛选时主要依据下列标准，删除不正确或 不必要的类与对象： (1) 冗余 如果两个类表达了同样的信息，则应该保留 在此问题域中最富于描述力的名称。 以 ATM系统为例，上面用非正式分析法得出了 34个候选的类，其中储户与用户，现金兑换卡与 磁卡及副本分别描述了相同的两类信息，因此， 应该去掉 “ 用户 ” 、 “ 磁卡 ” 、 “ 副本 ”

10、 等冗余 的类，仅保留 “ 储户 ” 和 “ 现金兑换卡 ” 这两个 类。 (2) 无关 现实世界中存在许多对象，不能把它们都纳入到 系统中去，仅需要把与本问题密切相关的类与对象 放进目标系统中。有些类在其他问题中可能很重 要，但与当前要解决的问题无关，同样也应该把它 们删掉。 以 ATM系统为例，这个系统并不处理分摊软件开 发成本的问题，而且 ATM和柜员终端放置的地点与 本软件的关系也不大。因此，应该去掉候选类 “ 成 本 ” 、 “ 市 ” 、 “ 街道 ” 、 “ 营业厅 ” 和 “ 储蓄 所 ” 。 (3) 笼统 在需求陈述中常常使用一些笼统的、泛指的名 词，虽然在初步分析时把它们作

11、为候选的类与对象 列出来了，但是，要么系统无须记忆有关它们的信 息，要么在需求陈述中有更明确更具体的名词对应 它们所暗示的事务，因此，通常把这些笼统的或模 糊的类去掉。 以 ATM系统为例， “ 银行 ” 实际指总行或分行， “ 访问 ” 在这里实际指事务， “ 信息 ” 的具体内容 在需求陈述中随后就指明了。此外还有一些笼统含 糊的名词。总之，在本例中应该去掉 “ 银行 ” 、 “ 网络 ” 、 “ 系统 ” 、 “ 软件 ” 、 “ 信息 ” 、 “ 访 问 ” 等候选类。 (4) 属性 在需求陈述中有些名词实际上描述的是其他对象的 属性，应该把这些名词从候选类与对象中去掉。当 然，如果某

12、个性质具有很强的独立性，则应把它作为 类而不是作为属性。 在 ATM系统的例子中， “ 现金 ” 、 “ 支票 ” 、 “ 取款额 ” 、 “ 账单 ” 、 “ 余额 ” 、 “ 分行代码 ” 、 “ 卡号 ” 、 “ 密码 ” 、 “ 类型 ” 等，实际上都应该作 为属性对待。 (5) 操作 在需求陈述中有时可能使用一些既可作为名词，又 可作为动词的词，应该慎重考虑它们在本问题中的含 义，以便正确地决定把它们作为类还是作为类中定义 的操作。 例如，谈到电话时通常把 “ 拨号 ” 当作动词，当构 造电话模型时确实应该把它作为一个操作，而不是一 个类。但是，在开发电话的自动记账系统时， “ 拨

13、号 ” 需要有自己的属性 (例如日期、时间、受话地点 等 )，因此应该把它作为一个类。总之，本身具有属 性需独立存在的操作，应该作为类与对象。 (6) 实现 在分析阶段不应该过早地考虑怎样实现目标系统。 因此，应该去掉仅和实现有关的候选的类与对象。在 设计和实现阶段，这些类与对象可能是重要的，但在 分析阶段过早地考虑它们反而会分散我们的注意力。 在 ATM系统的例子中， “ 事务日志 ” 无非是对一 系列事务的记录，它的确切表示方式是面向对象设计 的议题； “ 通信链路 ” 在逻辑上是一种联系，在系统 实现时它是关联类的物理实现。总之，应该暂时去掉 “ 事务日志 ” 和 “ 通信链路 ” 这两

14、个类，在设计或实 现时再考虑它们。 在 ATM系统的例子中，经过初步筛选， 剩下下列类与对象： ATM、中央计算机、 分行计算机、柜员终端、总行、分行、柜 员、储户、账户、事务、现金兑换卡。 3.2 确定关联 1. 初步确定关联 在需求陈述中使用的描述性动词或动词词组， 通常表示关联关系。因此，在初步确定关联时，大 多数关联可以通过直接提取需求陈述中的动词词组 而得出。通过分析需求陈述，还能发现一些在陈述 中隐含的关联。最后，分析员还应该与用户及领域 专家讨论问题域实体间的相互依赖、相互作用关 系，根据领域知识再进一步补充一些关联。 以 ATM系统为例，经过分析初步确定出下列关 联： (1)

15、直接提取动词短语得出的关联 ATM、中央计算机、分行计算机及柜员终端组成 网络。 总行拥有多台 ATM。 ATM设在主要街道上。 分行提供分行计算机和柜员终端。 柜员终端设在分行营业厅及储蓄所内。 分行分摊软件开发成本。 储户拥有账户。 分行计算机处理针对账户的事务。 分行计算机维护账户。 柜员终端与分行计算机通信。 柜员输入针对账户的事务。 ATM与中央计算机交换关于事务的信息。 中央计算机确定事务与分行的对应关系。 ATM读现金兑换卡。 ATM与用户交互。 ATM吐出现金。 ATM打印账单。 系统处理并发的访问。 (2) 需求陈述中隐含的关联 总行由各个分行组成。 分行保管账户。 总行拥有

16、中央计算机。 系统维护事务日志。 系统提供必要的安全性。 储户拥有现金兑换卡。 (3) 根据问题域知识得出的关联 现金兑换卡访问账户。 分行雇用柜员。 2. 筛选 (1) 已删去的类之间的关联 如果在分析确定类与对象的过程中已经删掉了某个 候选类，则与这个类有关的关联也应该删去，或用其 他类重新表达这个关联。 以 ATM系统为例，由于已经删去了 “ 系统 ” 、 “ 网 络 ” 、 “ 市 ” 、 “ 街道 ” 、 “ 成本 ” 、 “ 软件 ” 、 “ 事务日志 ” 、 “ 现金 ” 、 “ 营业厅 ” 、 “ 储蓄 所 ” 、 “ 账单 ” 等候选类，因此，与这些类有关的下 列 8个关联也

17、应该删去： ATM、中央计算机、分行计算机及柜员 终 端组成网络。 ATM设在主要街道上。 分行分摊软件开发成本。 系统提供必要的安全性。 系统维护事务日志。 ATM吐出现金。 ATM打印账单。 柜员终端设在分行营业厅及储蓄所内。 (2) 与问题无关的或应在实现阶段考虑的关联 应该把处在本问题域之外的关联或与实现密切相 关的关联删去。 例如，在 ATM系统的例子中， “ 系统处理并发的 访问 ” 并没有标明对象之间的新关联，它只不过提 醒我们在实现阶段需要使用实现并发访问的算法， 以处理并发事务。删掉： 系统处理并发的访问 (3) 瞬时事件 关联应该描述问题域的静态结构，而不应该是一个 瞬时事

18、件。 以 ATM系统为例， “ ATM读现金兑换卡 ” 描述了 ATM与用户交互周期中的一个动作，它并不是 ATM与 现金兑换卡之间的固有关系，因此应该删去。类似地， 还应该删去 “ ATM与用户交互 ” 这个候选的关联。 如果用动作表述的需求隐含了问题域的某种基本结构， 则应该用适当的动词词组重新表示这个关联。例如， 在 ATM系统的需求陈述中， “ 中央计算机确定事务与 分行的对应关系 ” 隐含了结构上 “ 中央计算机与分行 通信 ” 的关系。 (4) 三元关联 三个或三个以上对象之间的关联，大多可以分解 为二元关联或用词组描述成限定的关联。 在 ATM系统的例子中， “ 柜员输入针对账户

19、的事 务 ” 可以分解成 “ 柜员输入事务 ” 和 “ 事务修改账 户 ” 这样两个二元关联。而 “ 分行计算机处理针对账 户的事务 ” 也可以做类似的分解。 “ ATM与中央计算 机交换关于事务的信息 ” 这个候选的关联，实际上隐 含了 “ ATM与中央计算机通信 ” 和 “ 在 ATM上输入事 务 ” 这两个二元关联。 (5) 派生关联 应该去掉那些可以用其他关联定义的冗余关联。 例如，在 ATM系统的例子中， “ 总行拥有多台 ATM”实质上是 “ 总行拥有中央计算机 ” 和 “ ATM与 中央计算机通信 ” 这两个关联组合的结果。而 “ 分 行计算机维护账户 ” 的实际含义是 “ 分行

20、保管账 户 ” 和 “ 事务修改账户 ” 。 3. 进一步完善 应该进一步完善经筛选后余下的关联，通常从下述 几个方面进行改进： (1) 正名 好的名字是帮助读者理解的关键因素之一。因此， 应该仔细选择含义更明确的名字作为关联名。 例如， “ 分行提供分行计算机和柜员终端 ” 不如改 为 “ 分行拥有分行计算机 ” 和 “ 分行拥有柜员终 端 ” 。 (2) 分解 为了能够适用于不同的关联，必要时应该分解以前 确定的类与对象。 例如，在 ATM系统中，应该把 “ 事务 ” 分解成 “ 远程事务 ” 和 “ 柜员事务 ” 。 (3) 补充 发现了遗漏的关联就应该及时补上。 例如，在 ATM系统中

21、把 “ 事务 ” 分解成上述两类 之后，需要补充 “ 柜员输入柜员事务 ” 、 “ 柜员事 务输进柜员终端 ” 、 “ 在 ATM上输入远程事务 ” 和 “ 远程事务由现金兑换卡授权 ” 等关联。 (4) 标明重数 应该初步判定各个关联的类型，并粗略地确定关联 的重数。但是，无须为此花费过多精力，因为在分 析过程中随着认识的逐渐深入，重数也会经常改 动。 下图是经上述分析过程之后得出的 ATM系统原始 的类图。 总行拥有中央计算机 。 中央计算机与 ATM通信。 在 ATM上输入远程事务。 远程事务由现金兑换卡授权。 现金兑换卡访问帐户。 中央计算机与分行计算机通信。 总行由各个分行组成。 分

22、行拥有分行计算机。 分行拥有柜员终端。 分行计算机与柜员终端通信。 分行雇用柜员。 储户拥有账户。 储户拥有现金兑换卡。 分行保管账户。 柜员终端输入柜员事务。 柜员输入柜员事务。 柜员事务修改帐户 远程事务修改帐户。 ATM系统原始的类图 3.3 划分主题 Coad/Yourdon方法中主题的概念： 主题是把一组具有较强联系的类组织在一 起而得到的类的集合。 主题概念及其用途 主题是一种比类和对象抽象层次更高、粒度 更大的概念，用以建立系统的高层抽象视 图； 主题有助于指导系统设计者或用户等理解一 个大的系统模型 , 有助于组织一个大项目的 工作。 主题层是在 OOA基本模型 (类图 )之上

23、建立 一个能帮助人们从不同的认识层次来理解系 统的补充模型； 主题概念的特点 是由一组类构成的集合 一个主题内部的对象类应具有某种意义上的 内在联系 描述系统中相对独立的组成部分（如一个 子系统） 描述系统中某一方面的事物（如人员、设 备） 解决系统中某一方面的问题（如输入输 出） 主题的划分有一定的灵活性和随意性 主题的表示法 三种表示方式 :压缩方式 半展开方式 全展开方式 编号 主题名 压缩方式 编号 主题名 半展开方式： 类名 类名 类名 主题名 主题名 下层 主题 主题的表示法 全展开方式： 编号 编号 编号 编号 类图上原有的全部内容 如何划分主题 把每个结构作为一个主题； (选取

24、结构中最上层的类作为一主题 ) 通过实例连接互相联系的类可划分到一个 主题； 把不属于任何结构，也没有实例连接的类 作为一个主题。 如何精练主题 从 问题域 和 接口复杂性 两方面入手 : 使用问题域精练主题 ,即用整体 /部分结构对 问题域进行划分 ,而不是按功能分解方法划分 . 按高内聚低偶合原则 ,通过使主题间依赖性和 交互性最小原则保留能反映子问题域的主题 . 主题数目 7个左右 ,则进一步精练主题 . 何时引入主题 依赖于模型自身复杂性 小系统 : 不需引入主题 ; 中等系统 :先标识类及对象 , 然后引入主题 ; 大系统 : 先标识主题 ,对问题域进行 划分 ,分给不同的任务组 ;

25、 主题层次的控制 中小型系统可只设一层主题，最多 不超过两层； 大型系统可只设两层主题，最多不 超过三层。 以 ATM系统为例，可以把它划分成总行（包含总 行和中央计算机这两个类）、分行（包含分行、分 行计算机、柜员终端、柜员事务、柜员和账户等 类）和 ATM（包含 ATM、远程事务、现金兑换卡和 储户等类）等 3个主题。事实上，我们描述的是一个 简化的 ATM系统，为了简单起见，在下面讨论这个 例子时将忽略主题层。 3.4 确定属性 1. 分析 通常，在需求陈述中用名词词组表示属性，例如， “ 汽车的 颜色 ” 或 “ 光标的位置 ” 。往往用形容词表示可枚举的具体属 性，例如， “ 红色的

26、 ” 、 “ 打开的 ” 。 属性的确定既与问题域有关，也和目标系统的任务有关。应 该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要 解决的问题范围的属性。在分析过程中应该首先找出最重要的 属性，以后再逐渐把其余属性增添进去。在分析阶段不要考虑 那些纯粹用于实现的属性。 2. 选择 通常有以下几种常见情况： (1) 误把对象当作属性 如果某个实体的独立存在比它的值更重要， 则应把它作为一个对象而不是对象的属性。在 具体应用领域中具有自身性质的实体，必然是 对象。同一个实体在不同应用领域中，到底应 该作为对象还是属性，需要具体分析才能确 定。例如，在邮政目录中， “ 城市 ” 是一个属 性

27、，而在人口普查中却应该把 “ 城市 ” 当作对 象。 （ 2） 误把关联类的属性当作一般对象的属 性 如果某个性质依赖于某个关联链的存在，则该性质 是关联类的属性，在分析阶段不应该把它作为一般 对象的属性。特别是在多对多关联中，关联类属性 很明显，即使在以后的开发阶段中，也不能把它归 并成相互关联的两个对象中任一个的属性。 （ 3） 把限定误当成属性 正确使用限定词往往可以减少关联的重数。如果把 某个属性值固定下来以后能减少关联的重数，则应 该考虑把这个属性重新表述成一个限定词。在 ATM 系统的例子中， “ 分行代码 ” 、 “ 账号 ” 、 “ 雇员 号 ” 、 “ 站号 ” 等都是限定词

28、 。 (4) 误把内部状态当成了属性 如果某个性质是对象的非公开的内部状态，则应该 从对象模型中删掉这个属性。 (5) 过于细化 在分析阶段应该忽略那些对大多数操作都没有影响 的属性。 (6) 存在不一致的属性 类应该是简单而且一致的。如果得出一些看起来与 其他属性毫不相关的属性，则应该考虑把该类分解 成两个不同的类。 经过筛选之后，得到 ATM系统中各个类的属性， 如 P235图 10.4所示。 确定了类中应该定义的属性之后，就可以利 用继承机制共享公共性质，并对系统中众多的 类加以组织。正如以前曾经强调指出过的，继 承关系的建立实质上是知识抽取过程，它应该 反映出一定深度的领域知识，因此必

29、须有领域 专家密切配合才能完成。通常，许多归纳关系 都是根据客观世界现有的分类模式建立起来的， 只要可能，就应该使用现有的概念。 3.5 识别继承关系 一般说来，可以使用两种方式建立继承 (即泛 化 )关系： (1) 自底向上： 抽象出现有类的共同性质泛 化出父类，这个过程实质上模拟了人类归纳思 维过程。例如，在 ATM系统中， “ 远程事务 ” 和 “ 柜员事务 ” 是类似的，可以泛化出父类 “ 事务 ” ；类似地，可以从 “ ATM”和 “ 柜员 终端 ” 泛化出父类 “ 输入站 ” 。 (2) 自顶向下： 把现有类细化成更具体的子类，这 模拟了人类的演绎思维过程。从应用域中常常能明 显看

30、出应该做的自顶向下的具体化工作。例如，带 有形容词修饰的名词词组往往暗示了一些具体类。 但是，在分析阶段应该避免过度细化。 利用多重继承可以提高共享程度，但是同时也增加 了概念上以及实现时的复杂程度。使用多重继承机 制时，通常应该指定一个主要父类，从它继承大部 分属性和行为；次要父类只补充一些属性和行为。 图 10.5（见书 237页） 是增加了继承关系之后的 ATM对象模型。 3.6 反复修改 下面以 ATM系统为例，讨论可能做的修改： 1. 分解 “ 现金兑换卡 ” 类 实际上， “ 现金兑换卡 ” 有两个相对独立的功能， 它既是鉴别储户使用 ATM的权限的卡，又是 ATM获 得分行代码和

31、卡号等数据的数据载体。因此，把 “ 现金兑换卡 ” 类分解为 “ 卡权限 ” 和 “ 现金兑换 卡 ” 两个类，将使每个类的功能更单一：前一个类 标志储户访问账户的权限，后一个类是含有分行代 码和卡号的数据载体。多张现金兑换卡可能对应着 相同的访问权限。 2. “事务 ” 由 “ 更新 ” 组成 通常，一个事务包含对账户的若干次更新，这里所 说的更新，指的是对账户所做的一个动作 (取款、存 款或查询 )。 “ 更新 ” 虽然代表一个动作，但是它有 自己的属性 (类型、金额等 )，应该独立存在，因此应 该把它作为类。 3. 把 “ 分行 ” 与 “ 分行计算机 ” 合并 区分 “ 分行 ” 与

32、“ 分行计算机 ” ，对于分析这个系 统来说，并没有多大意义，为简单起见，应该把它 们合并。类似地，应该合并 “ 总行 ” 和 “ 中央计算 机 ” 。 图 10.6（见书 238页） 给出了修改后的 ATM对象 模型，与修改前比较起来，它更简单、更清晰。 第一步，编写典型交互行为的脚本。 第二步，从脚本中提取出事件，确定触发每个事件的 动作对象以及接受事件的目标对象。 第三步，排列事件发生的次序，确定每个对象可能有 的状态及状态间的转换关系，并用状态图描绘它们。 最后，比较各个对象的状态图，检查它们之间的一致 性，确保事件之间的匹配。 4 建立动态模型 在建立动态模型的过程中， 脚本是指系统

33、在某一执 行期间内出现的一系列事件。 脚本描述用户 (或其他外 部设备 )与目标系统之间的一个或多个典型的交互过 程，以便对目标系统的行为有更具体的认识。编写脚本 的目的，是保证不遗漏重要的交互步骤，它有助于确保 整个交互过程的正确性和清晰性。 编写脚本的过程，实质上就是分析用户对系统交互 行为的要求的过程。在编写脚本的过程中，需要与用户 充分交换意见，编写后还应该经过他们审查与修改。 4.1 编写脚本 编写脚本时，首先编写正常情况的脚本。然后， 考虑特殊情况，例如输入或输出的数据为最大值 (或 最小值 )。最后，考虑出错情况，例如，输入的值为 非法值或响应失败。对大多数交互式系统来说，出 错

34、处理都是最难实现的部分。如果可能，应该允许 用户 “ 异常中止 ” 一个操作或 “ 取消 ” 一个操作。 此外，还应该提供诸如 “ 帮助 ” 和状态查询之类的 在基本交互行为之上的 “ 通用 ” 交互行为。 脚本描述事件序列。每当系统中的对象与用户 (或其他外部设备 )交换信息时，就发生一个事件。所 交换的信息值就是该事件的参数 (例如， “ 输入密 码 ” 事件的参数是所输入的密码 )。也有许多事件是 无参数的，这样的事件仅传递一个信息 该事件 已经发生了。 对于每个事件，都应该指明触发该事件的动作对 象 (例如，系统、用户或其他外部事物 )、接受事件的 目标对象以及该事件的参数。 表 10

35、.1和表 10.2（见书 240页）分别给出了 ATM 系统的正常情况脚本和异常情况脚本。 大多数交互行为都可以分为应用逻辑和用户界面两部分。 通常，系统分析员首先集中精力考虑系统的信息流和控制流， 而不是首先考虑用户界面。事实上，采用不同界面 (例如，命令 行或图形用户界面 )，可以实现同样的程序逻辑。应用逻辑是内 在的、本质的内容，用户界面是外在的表现形式。动态模型着 重表示应用系统的控制逻辑。 软件开发人员往往快速地建立起用户界面的原型，供 用户试用与评价。下图初步设想出的 ATM界面格式。 4.2 设想用户界面 ATM的界面格式 完整、正确的脚本为建立动态模型奠定了必 要的基础。但是，

36、用自然语言书写的脚本往往 不够简明，而且有时在阅读时会有二义性。为 了有助于建立动态模型，通常在画状态图之前 先画出事件跟踪图。为此首先需要进一步明确 事件及事件与对象的关系。 4.3 画事件跟踪图 1. 确定事件 应该仔细分析每个脚本，以便从中提取出所有外部 事件。 事件包括系统与用户 (或外部设备 )交互的所有 信号、输入、输出、中断、动作等等 。 传递信息的 对象的动作也是事件 。 大多数对象到对象的交互行为都对应着事件 。例 如，储户插入现金兑换卡、储户输入密码、 ATM吐 出现金等都是事件。 区分出 每类事件的发送对象和接受对象 。 2. 画出事件跟踪图 事件跟踪图把事件序列以及事件

37、与对象的关系 表示出来。事件跟踪图实质上是扩充的脚本， 可以认为事件跟踪图是简化的 UML顺序图。 图 10.8（见书 242页）是 ATM系统正常情况 下的事件跟踪图。 状态图描绘事件与对象状态的关系。 系统分析员应该 集中精力仅考虑具有重要交互 行为的那些类 。 4.4 画状态图 图 10.9（见书 243页），图 10.10和图 10.11分别是 “ ATM”、 “ 总行 ” 和 “ 分行 ” 的 状态图。这些状态图都是简化的，尤其对异常 情况和出错情况的考虑是相当粗略的 (例如，图 10.9并没有表示在网络通信链路不通时的系统 行为，实际上，在这种情况下 ATM停止处理储 户事务 )。

38、 总行类的状态图 分行类的状态图 各个类的状态图通过共享事件合并起来，构成了系 统的动态模型。在完成了每个具有重要交互行为的 类的状态图之后，应该检查系统级的完整性和一致 性。一般说来，每个事件都应该既有发送对象又有 接受对象，当然，有时发送者和接受者是同一个对 象。对于没有前驱或没有后继的状态应该着重审 查，如果这个状态既不是交互序列的起点也不是终 点，则发现了一个错误。 4.5 审查动态模型 应该审查每个事件，跟踪它对系统中各个对象所产 生的效果，以保证它们与每个脚本都匹配。 以 ATM系统为例。在总行类的状态图中，事件 “ 分行代码错 ” 是由总行发出的，但是在 ATM类的 状态图中并没

39、有一个状态接受这个事件。因此，在 ATM类的状态图中应该再补充一个状态 “ do/显示 分行代码错信息 ” ，它接受由前驱状态 “ do/验证账 户 ” 发出的事件 “ 分行代码错 ” ，它的后续状态是 “ 退卡 ” 。 由一组数据流图组成。其中的处理功能可以用 IPO 图 (或表 )、伪码等多种方式进一步描述。 通常在建立了对象模型和动态模型之后再建立功能 模型。 5 建立功能模型 ATM系统的基本系统模型 6 定义服务 1. 常规行为 在分析阶段可以认为，类中定义的每个属性都是可 以访问的，也就是说，假设在每个类中都定义了 读、写该类每个属性的操作。但是，通常无需在类 图中显式表示这些常规

40、操作。 2. 从事件导出的操作 状态图中发往对象的事件也就是该对象接收到的 消息，因此该对象必须有由消息选择符指定的操作， 这个操作修改对象状态 (即属性值 )并启动相应的服 务。例如，在 ATM系统中，发往 ATM对象的事件 “ 中 止取消 ” ，启动该对象的服务 “ 打印账单 ” ；发往分 行的事件 “ 请分行验卡 ” 启动该对象的服务 “ 验证卡 号 ” ；而事件 “ 处理分行事务 ” 启动分行对象的服务 “ 更新账户 ” 。可以看出，所启动的这些服务通常就 是接受事件的对象在相应状态的行为。 3. 与数据流图中处理框对应的操作 数据流图中的每个处理框都与一个对象 (也 可能是若干个对象

41、 )上的操作相对应。应该仔细 对照状态图和数据流图，以便更正确地确定对 象应该提供的服务。例如，在 ATM系统中，从 状态图上看出分行对象应该提供 “ 验证卡号 ” 服务，而在数据流图上与之对应的处理框是 “ 验卡 ” ，根据实际应该完成的功能看，该对 象提供的这个服务应该是 “ 验卡 ” 。 4. 利用继承减少冗余操作 应该尽量利用继承机制以减少所需定义的服 务数目。只要不违背领域知识和常识，就尽量 抽取出相似类的公共属性和操作，以建立这些 类的新父类，并在类等级的不同层次中正确地 定义各个服务。 分析就是提取系统需求并建立问题域精确模 型的过程，它包括理解、表达和验证等 3项主 要工作内容

42、。面向对象分析的关键工作，是分 析、确定问题域中的对象及对象间的关系，并 建立起问题域的对象模型。 大型、复杂系统的对象模型通常由下述 5个 层次组成：主题层、类与对象层、结构层、属 性层和服务层。它们对应着在建立对象模型的 过程中所应完成的 5项工作。 小结 大多数分析模型都不是一次完成的，为了理 解问题域的全部含义，必须反复多次地进行分 析。因此，分析工作不可能严格地按照预定顺 序进行；分析工作也不是机械地把需求陈述转 变为分析模型的过程。分析员必须与用户及领 域专家反复交流、多次磋商，及时纠正错误认 识并补充缺少的信息。 分析模型是同用户及领域专家交流时有效的 通信手段。最终的模型必须得到用户和领域专 家的确认。在交流和确认的过程中，原型往往 能起很大的促进作用。 一个好的分析模型应该正确完整地反映问题 的本质属性，且不包含与问题无关的内容。分 析的目标是全面深入地理解问题域，其中不应 该涉及具体实现的考虑。但是，在实际的分析 过程中完全不受与实现有关的影响也是不现实 的。虽然分析的目的是用分析模型取代需求陈 述，并把分析模型作为设计的基础，但是事实 上，在分析与设计之间并不存在绝对的界线。