4面向对象的软件设计方法

精化后的Withdrawal顺序图
详细研究类之间的连接关系 精确判定关系：依赖、关联、聚合、构成
精化类之间的关系
确定连接的方向吸参与连接的类对象之间的数量对应关系 根据软件复用的要求及软件结构简洁化、清晰化的要求，优化类之间的关系 连接关系，主要是构筑消息通道。面向对象的程序设计机制提供4种手段： 引用全局对象：obj1直接引用 作为全局对象的obj2 通过参数传递: obj2作为obj1的某项操作的实际参数 引用局部对象：在obj1的 某项操作的 数数体中创建或获取obj2 通过类的成员变量： obj2作为 obj1所属类的司性的取值 利用继承关系精化设计模型 寻找类之间的公共属性和操作，引进父类捕获公共性，简化模型 将类划分为集合，针对每个集合特性设计一个父类，让集合中的所有类成为该父 类的子类 可能需要将多重继承化解为间重继承 对业务逻辑、界面、数据模型等不同的设计模型进行整理和融合 合交相似类 消除设计模型之间的冗余 保证一致性
精化过程中新增加的类
精化交互模型
交互图进行精化时，需要考虑以下内容 软件架构的组成类被迫调整之后对交互模型产生的影响，新 出现的对象可拆分后的对象如何参与交互过程，在其中起到 什么样的作用 对象在交互过程中的消息传递需要哪些参数和返回值 交互过程是否需要细化，例如如增加必要的消息，或对局部 引用 一个更加具体的交互图
பைடு நூலகம்
类设计： 对类进行细化设计，精化类之间的关系以及类的操作和属性，使 它们能够直接提交给软件构造阶段进行编码实现。对重要控制类， 采用状态图描述类的实例在生存周期中对外部事件的响应笔状态 变化过程，并可以采用活动图对重要的方法过程开算法进行描述。 部署模型设计： 对软件最终的元素结构以及运行的具体环境进行描述，包括刻画 最终可能生成的运行文件、库文件或软件包以及这些元素之间的 静态关系，软件最终运行的物理平台拓朴结构，描述其中的物理 节点以及它们之间的通信和交互方式，并说明软件包、运行文件， 子系统等元素在物理节点上的部署方案
4.2 用例分析与设计
确定用例 生成用例图 用例设计描述
银行ATM自动柜员机需求简述
提供以下服务： 取款。顾客用银行卡从对应的账户中支取现金，现金必须是 存款。顾客可以把现金存入银行卡对应的账户中 转账。顾客可以把一个银行卡对应的赂中的款项转账到另一个银行 账户中 查询。顾客能够查询一个银行卡对应的账户中的余额 该ATM系统包括以下组成部分： 读卡器 交互的控制台 存款的插槽 打印机 启动和关闭ATM系统的开关键盘 ATM系统与银行服务通过特定的网络连接进行通信
确定用例—确认参与者和责任 确认参与者和责任
不同的参与者 系统管理员、程序员、会计、 系统管理员、程序员、会计、出纳员 与系统通信的其他系统 不同的责任 系统配置、程序设计、财务管理、 系统配置、程序设计、财务管理、现金管理 分析参与者的工作： 分析参与者的工作：使用案例 各种使用过程、 各种使用过程、步骤
边界类：其职责包括： 边界控制： 包括定义数据的格式及内容转换，输出结果的呈现，软件运行过 程中界面的变化与切换等。 外部接口： 实现目标软件系统与外部系统或外部设备之间的信息交流和互操 作，主要关注跨越目标软件系统边界的通信协议 环境隔离： 对目标软件系统与操作系统、数据库管理系统、中间件等环境软 件进行交互的功能与特性进行封装，使目标软件系统的其余部分 尽右能独立于环境软件。
ATM系统的顶层架构图
4.4用户界面设计
用户在使用软件过程中所需的各种元素 屏幕 窗口：屏幕的组成部分 良好的外观和布局 用户界面结构可以用UML类图表示，屏幕和窗口用类进行表 示，并给出它们之间的关系 可根据用例来分别设计相应的屏幕切换状态图和结构图
CustomerConsole
用户通过控制台使用ATM的过程中，可分为5个相对独立的过程 （1）插入银行卡到输入正确密码并进入选择交易类型的屏幕 （2）选择“取款”交易，并到完成后退出或返回选择交易类 型的屏幕 （3）选择“存款”交易，并到完成后退出或返回选择交易类 型的屏幕 （4）选择“转帐”交易，并到完成后退出或返回选择交易类 型的屏幕 （5）选择“查询”交易，并到完成后退出或返回选择交易类 型的屏幕
ATM系统的概念模型——分析模型图
顶层架构设计
顶层架构是分析和设计阶段成果的承载体 可以把体系结构设计方法与上述概念模型得到的结果结合起 来考虑，利用一定的体系结构模式（例如分层模式、模型视图—控制器MVC模式等）对概念模型中的相关元素进行 组织，同时需要考虑目标软件系统与其他参与者的外部系统 之间的联系和交互方式。
顾客（Customer） 操作管理员（Operator） 银行服务员（Bank System） 读卡器（Card Reader） 存款器（Cash Acceptor） 打印机（Printer）
ATM系统—用例
取款（Withdrawal） 存款（Deposit） 转账（Transfer） 查询余额（Inquiry） 开机（System Startup） 关机（System Shutdown）
用类图进行关系数据库表格设计
Receipt
4.6设计精化
精化任务： 精化软件架构 调整软件构成的类 精化交互模型 精化类之间关系
精化软件架构
目的：寻找理想的包划分方案，包中类数量适中，边界清晰的，自然，耦合 度低 降低耦合度 拆分成子包 调整类的摆放位置，移到另外的包 合并包或合并后重新划分 原则 避免包间的循环依赖 位于较低层次的通用包不应当依赖于较高层次中的专用包 在层次结构中，较高层次的包可以依赖较低层次的包，但应尽量在相邻的 层次间发生 如果针对某些子系统专门划分了接口包和实现包，那么，其他与该子系统 相关的包吸能依赖于接口包，不能依赖于实现包
用户交互层包精化后的模型
用户交互层中子包精化后的模型
调整软件构成类
增加辅助类 引入 新类以弥补不足 合并相互通信频繁的类 若类的属性和操作简单，但与其他类通信非常用频繁，即耦合度很 高，这样的类可以合并到其他类中 分拆规模过大的类 若一个类的属性可以区分为常用和罕用，为提高效率，拆分为“常 用”类和数个“罕用”类，建立聚合关系 若一个类既要负责业务逻辑，又要实现与外部数据通信，那么可以 拆分为，业务逻辑类和通信类
屏幕结构类图
屏幕变化的状态图
InputPIN屏幕结构类图
CustomConsole UserInterface包的结构
CIardInserted UserInterface
4.5数据模型设计
数据模型设计包括数据结构设计数据库设计、数据文件设计等，主要关注 持久存储数据的设计。 持久数据模型设计主要包括以下几个步骤 （1）确定设计模型中需要持久保存的类的对象及属性，其中实体类是 主要关注对象 （2）确定持久存储数据之间的组织方式 （3）确定数据模型中的操作行为，例如数据完整性验证、数据读取、 存储与更新、数据求和、求数据平均值等 （4）进一步优化持久数据操作的性能，例如使用数据索引、存储过程、 触发器等方式 类对应于关系数据模型中的表格，对象对应于记录，属性对应 于表格中的 字段或者列 派生属性不持久存储 关键字字段
用例的确认
围绕系统的一个工作过程， 围绕系统的一个工作过程，确认参与交互过程的参与者 如：系统管理员、域控制器（计算机） 系统管理员、域控制器（计算机） 用系列动作步骤描述交互过程 参与者的动作、 参与者的动作、系统的执行步骤 要点 忽略内部细节， 忽略内部细节，仅考虑外部因素
ATM案例——参与者
用例建模步骤 用例建模步骤 建模
1) 描述各种使用案例 描述交互过程的动作序列 描述交互过程的动作序列 模拟系统工作的交互过程 2）确认动作 ） 检查使用案例， 检查使用案例，引入并描述动作 覆盖所有可能发生的动作 覆盖所有可能发生的动作
用例建模步骤 用例建模步骤 建模
3) 跟踪执行过程 跟踪执行 执行过程 为每个使用案例制作序列图 为每个使用案例制作序列图 使用案例制作 描述对象之间的消息传送过程 描述对象之间的消息传送过程 消息 4) 构造状态转移图 为每个对象构造的状态转移图 每个对象构造的状态转移图 构造 反映对象接受和发送的消息 反映对象接受和发送的消息 考虑所有使用案例中的所有消息 考虑所有使用案例中的所有消息 使用案例中的所有
Startup用例的顺序图描述
Session用例的顺序图描述
Traction用例的顺序图描述
Withdrawal用例的顺序图描述
4.3 概念模型和顶层架构
概念模型的设计 标识领域概念模型 分析类：直接服务于用户功能性需求的概念层面的类， 与具体技术没有关系 顶层架构的设计 目的：为后续的分析和设计活动建立一种结构和划分
第四章 面向对象的软件设计方法
主要内容
基于UML的分析与设计过程 用例分析与设计 概念模型和顶层架构设计 用户界面设计 数据模型设计 设计精化 类设计 部署模型设计
4.1基于UML的分析与设计过程
用例图 交互图 用例分析与设计 概念模型与顶层 架构设计 用户界面设计 数据模型设计 类图 设计精化 类设计 部署模型设计 UML设计模型 构件图 部署图 包图 交互图 类图 状态图 活动图 活动图 类图 包图 构件图 类图 包图
ATM系统初步用例图
用例名称：Withdrawal
用例设计描述
参与者：Cudtomer,kBankSystem,Card Reader,Cash Dispenser,Printer 前置条件：顾客已插入银行卡，密码验证正确，顾客按下“取款”按钮 主事件流： （1）顾客输入取款金额，并确认。 （2）系统认可取款金额，并发送指令给取款器 （3）取款器把相应金额的现金送出 （4）打印机打印回执 辅事件流： （1）如果取款金额不是100的整数倍，则显示信息“输入金额必须是100的整数倍， 请重新输入”，并返回主事件流中步骤（1） （2）如果取款金额超过2000元，则显示信息“输入金额不能超2000元，请重新输 入”，并返回主事件流中步骤（1） （3）如果账户余额小于取款金额，则显示信息“账户余额不足，请重新输入”， 并返回主事件流中步骤（1） （4）顾客在确认取款金额前右以选择取消交易。 后置条件：如果取款成功，系统从账户余额中减去相应数额，并返回等待状态；如果 顾客取消交易，则返回等待状态
ATM系统在提供以上服务的过程中，必须满足以下要求 一个顾客可以在最终确认前放弃一项交易 ATM在执行交易过程中将与银行系统进行通信，对是否 允许交易进行验证 ATM为每次成功的交易提供一个打印回执 ATM需要维护一个内部日志，对每次交易进行记录
确定用例—确定场景
从业务需求出发获取参与者（Actor)和场景，对场景进行汇 总、分类、抽象，形成用例 场景是用户与系统之间进行交互的一组具体的动作 获取场景 目标软件有哪些参与者 参与者希望系统执行的任务有哪些？ 参与者希望获得哪些信息？这些信息由谁生成？由谁修改？ 参与者城要通知系统哪些事件？系统响应这些事件时会表现 出哪些外部行为？ 系统将通告参与者哪些事件？
构件图
用例分析与设计： 需求获取，分析和描述的过程，它将利用例及用例图表示需求。 概念模型与顶层架构设计： 在用户需求和相关的业务领域中，概念及概念关系的抽取 用户界面设计： 设计每个界面中的所有界面元素，确定初步的界面布局，定义用户界面动作对软 件系统中设计元素的要求 数据模型的设计： 确定设计模型中需要持久保存的类的对象及其属性，定义持久持久存储数据之间 的组织方式，并明确数据模型中的操作行为。 设计的精化： 对上面的逻辑、界面、数据模型等不同侧重点的设计结果进行整理，合并相似的 类，保证各模型之间的一到处性，并消除冗余，为了提高整全后模型的质量，可 能需要引入继承、聚集等关系对类设计进行组织和精化，并可能需要引入新的关 键类和控制类。交互图等设计模型进行精华，以更具体地描述场景交互过程。
概念模型设计
关键概念来源 业务需求描述 业务领域中的相关规范、标准、述评呼定义 反映业务领域知识的既往经验 分析类： （1）边界类：负责目标软件系统与参与者之间的交互。 （2）控制类：完成用例任务的责任承担者，负责协调、控制其他类 共同完成用例规定的功能 或行为。 （3）实体类：负责保存目标软件系统中具有持久意义的信息项并向 其他类提供读、写信息项内容的必要操作接口，一般不涉及业务逻 辑。