面向对象的软件设计方法

1、第四章 面向对象的软件设计方法,主要内容,基于UML的分析与设计过程 用例分析与设计 概念模型和顶层架构设计 用户界面设计 数据模型设计 设计精化 类设计 部署模型设计,4.1基于UML的分析与设计过程,用例分析与设计,概念模型与顶层 架构设计,用户界面设计,数据模型设计,设计精化,类设计,部署模型设计,UML设计模型,类图,包图,构件图,用例图,交互图,活动图,类图,包图,交互图,构件图,部署图,类图,包图,构件图,类图,状态图,活动图,用例分析与设计： 需求获取，分析和描述的过程，它将利用例及用例图表示需求。 概念模型与顶层架构设计： 在用户需求和相关的业务领域中，概念及概念关系的抽取 用

2、户界面设计： 设计每个界面中的所有界面元素，确定初步的界面布局，定义用户界面动作对软件系统中设计元素的要求 数据模型的设计： 确定设计模型中需要持久保存的类的对象及其属性，定义持久持久存储数据之间的组织方式，并明确数据模型中的操作行为。 设计的精化： 对上面的逻辑、界面、数据模型等不同侧重点的设计结果进行整理，合并相似的类，保证各模型之间的一到处性，并消除冗余，为了提高整全后模型的质量，可能需要引入继承、聚集等关系对类设计进行组织和精化，并可能需要引入新的关键类和控制类。交互图等设计模型进行精华，以更具体地描述场景交互过程。,类设计： 对类进行细化设计，精化类之间的关系以及类的操作和属性，使它

3、们能够直接提交给软件构造阶段进行编码实现。对重要控制类，采用状态图描述类的实例在生存周期中对外部事件的响应笔状态变化过程，并可以采用活动图对重要的方法过程开算法进行描述。 部署模型设计： 对软件最终的元素结构以及运行的具体环境进行描述，包括刻画最终可能生成的运行文件、库文件或软件包以及这些元素之间的静态关系，软件最终运行的物理平台拓朴结构，描述其中的物理节点以及它们之间的通信和交互方式，并说明软件包、运行文件，子系统等元素在物理节点上的部署方案,4.2 用例分析与设计,确定用例 生成用例图 用例设计描述,银行ATM自动柜员机需求简述,提供以下服务： 取款。顾客用银行卡从对应的账户中支取现金，现

4、金必须是 存款。顾客可以把现金存入银行卡对应的账户中 转账。顾客可以把一个银行卡对应的赂中的款项转账到另一个银行账户中 查询。顾客能够查询一个银行卡对应的账户中的余额 该ATM系统包括以下组成部分： 读卡器 交互的控制台 存款的插槽 打印机 启动和关闭ATM系统的开关键盘 ATM系统与银行服务通过特定的网络连接进行通信,ATM系统在提供以上服务的过程中，必须满足以下要求 一个顾客可以在最终确认前放弃一项交易 ATM在执行交易过程中将与银行系统进行通信，对是否允许交易进行验证 ATM为每次成功的交易提供一个打印回执 ATM需要维护一个内部日志，对每次交易进行记录,确定用例确定场景,从业务需求出发

5、获取参与者（Actor)和场景，对场景进行汇总、分类、抽象，形成用例 场景是用户与系统之间进行交互的一组具体的动作 获取场景 目标软件有哪些参与者 参与者希望系统执行的任务有哪些？ 参与者希望获得哪些信息？这些信息由谁生成？由谁修改？ 参与者城要通知系统哪些事件？系统响应这些事件时会表现出哪些外部行为？ 系统将通告参与者哪些事件？,确定用例确认参与者和责任,不同的参与者 系统管理员、程序员、会计、出纳员 与系统通信的其他系统 不同的责任 系统配置、程序设计、财务管理、现金管理 分析参与者的工作：使用案例 各种使用过程、步骤,用例的确认,围绕系统的一个工作过程，确认参与交互过程的参与者 如：系统

6、管理员、域控制器（计算机） 用系列动作步骤描述交互过程 参与者的动作、系统的执行步骤 要点 忽略内部细节，仅考虑外部因素,ATM案例参与者,顾客（Customer） 操作管理员（Operator） 银行服务员（Bank System） 读卡器（Card Reader） 存款器（Cash Acceptor） 打印机（Printer）,ATM系统用例,取款（Withdrawal） 存款（Deposit） 转账（Transfer） 查询余额（Inquiry） 开机（System Startup） 关机（System Shutdown）,用例建模步骤,1) 描述各种使用案例 描述交互过程的动作序列 模

7、拟系统工作的交互过程 2）确认动作 检查使用案例，引入并描述动作 覆盖所有可能发生的动作,用例建模步骤,3) 跟踪执行过程 为每个使用案例制作序列图 描述对象之间的消息传送过程 4) 构造状态转移图 为每个对象构造的状态转移图 反映对象接受和发送的消息 考虑所有使用案例中的所有消息,ATM系统初步用例图,用例设计描述,用例名称：Withdrawal 参与者：Cudtomer,kBankSystem,Card Reader,Cash Dispenser,Printer 前置条件：顾客已插入银行卡，密码验证正确，顾客按下“取款”按钮 主事件流： （1）顾客输入取款金额，并确认。 （2）系统认可取款

8、金额，并发送指令给取款器 （3）取款器把相应金额的现金送出 （4）打印机打印回执 辅事件流： （1）如果取款金额不是100的整数倍，则显示信息“输入金额必须是100的整数倍，请重新输入”，并返回主事件流中步骤（1） （2）如果取款金额超过2000元，则显示信息“输入金额不能超2000元，请重新输入”，并返回主事件流中步骤（1） （3）如果账户余额小于取款金额，则显示信息“账户余额不足，请重新输入”，并返回主事件流中步骤（1） （4）顾客在确认取款金额前右以选择取消交易。 后置条件：如果取款成功，系统从账户余额中减去相应数额，并返回等待状态；如果顾客取消交易，则返回等待状态,Startup用例的

9、顺序图描述,Session用例的顺序图描述,Traction用例的顺序图描述,Withdrawal用例的顺序图描述,4.3 概念模型和顶层架构,概念模型的设计 标识领域概念模型 分析类：直接服务于用户功能性需求的概念层面的类，与具体技术没有关系 顶层架构的设计 目的：为后续的分析和设计活动建立一种结构和划分,概念模型设计,关键概念来源 业务需求描述 业务领域中的相关规范、标准、述评呼定义 反映业务领域知识的既往经验 分析类： （1）边界类：负责目标软件系统与参与者之间的交互。 （2）控制类：完成用例任务的责任承担者，负责协调、控制其他类共同完成用例规定的功能 或行为。 （3）实体类：负责保存目

10、标软件系统中具有持久意义的信息项并向其他类提供读、写信息项内容的必要操作接口，一般不涉及业务逻辑。,边界类：其职责包括： 边界控制： 包括定义数据的格式及内容转换，输出结果的呈现，软件运行过程中界面的变化与切换等。 外部接口： 实现目标软件系统与外部系统或外部设备之间的信息交流和互操作，主要关注跨越目标软件系统边界的通信协议 环境隔离： 对目标软件系统与操作系统、数据库管理系统、中间件等环境软件进行交互的功能与特性进行封装，使目标软件系统的其余部分尽右能独立于环境软件。,ATM系统的概念模型分析模型图,顶层架构设计,顶层架构是分析和设计阶段成果的承载体 可以把体系结构设计方法与上述概念模型得到

11、的结果结合起来考虑，利用一定的体系结构模式（例如分层模式、模型-视图控制器MVC模式等）对概念模型中的相关元素进行组织，同时需要考虑目标软件系统与其他参与者的外部系统之间的联系和交互方式。,ATM系统的顶层架构图,4.4用户界面设计,用户在使用软件过程中所需的各种元素 屏幕 窗口：屏幕的组成部分 良好的外观和布局 用户界面结构可以用UML类图表示，屏幕和窗口用类进行表示，并给出它们之间的关系 可根据用例来分别设计相应的屏幕切换状态图和结构图,CustomerConsole,用户通过控制台使用ATM的过程中，可分为5个相对独立的过程 （1）插入银行卡到输入正确密码并进入选择交易类型的屏幕 （2）

12、选择“取款”交易，并到完成后退出或返回选择交易类型的屏幕 （3）选择“存款”交易，并到完成后退出或返回选择交易类型的屏幕 （4）选择“转帐”交易，并到完成后退出或返回选择交易类型的屏幕 （5）选择“查询”交易，并到完成后退出或返回选择交易类型的屏幕,屏幕结构类图,屏幕变化的状态图,InputPIN屏幕结构类图,CustomConsole UserInterface包的结构,CIardInserted UserInterface,4.5数据模型设计,数据模型设计包括数据结构设计数据库设计、数据文件设计等，主要关注持久存储数据的设计。 持久数据模型设计主要包括以下几个步骤 （1）确定设计模型中需要

13、持久保存的类的对象及属性，其中实体类是主要关注对象 （2）确定持久存储数据之间的组织方式 （3）确定数据模型中的操作行为，例如数据完整性验证、数据读取、存储与更新、数据求和、求数据平均值等 （4）进一步优化持久数据操作的性能，例如使用数据索引、存储过程、触发器等方式 类对应于关系数据模型中的表格，对象对应于记录，属性对应 于表格中的字段或者列 派生属性不持久存储 关键字字段,用类图进行关系数据库表格设计,Receipt,4.6设计精化,精化任务： 精化软件架构 调整软件构成的类 精化交互模型 精化类之间关系,精化软件架构,目的：寻找理想的包划分方案，包中类数量适中，边界清晰的，自然，耦合度低

14、降低耦合度 拆分成子包 调整类的摆放位置，移到另外的包 合并包或合并后重新划分 原则 避免包间的循环依赖 位于较低层次的通用包不应当依赖于较高层次中的专用包 在层次结构中，较高层次的包可以依赖较低层次的包，但应尽量在相邻的层次间发生 如果针对某些子系统专门划分了接口包和实现包，那么，其他与该子系统相关的包吸能依赖于接口包，不能依赖于实现包,用户交互层包精化后的模型,用户交互层中子包精化后的模型,调整软件构成类,增加辅助类 引入 新类以弥补不足 合并相互通信频繁的类 若类的属性和操作简单，但与其他类通信非常用频繁，即耦合度很高，这样的类可以合并到其他类中 分拆规模过大的类 若一个类的属性可以区分

15、为常用和罕用，为提高效率，拆分为“常用”类和数个“罕用”类，建立聚合关系 若一个类既要负责业务逻辑，又要实现与外部数据通信，那么可以拆分为，业务逻辑类和通信类,精化过程中新增加的类,精化交互模型,交互图进行精化时，需要考虑以下内容 软件架构的组成类被迫调整之后对交互模型产生的影响，新出现的对象可拆分后的对象如何参与交互过程，在其中起到什么样的作用 对象在交互过程中的消息传递需要哪些参数和返回值 交互过程是否需要细化，例如如增加必要的消息，或对局部引用 一个更加具体的交互图,精化后的Withdrawal顺序图,精化类之间的关系,详细研究类之间的连接关系 精确判定关系：依赖、关联、聚合、构成 确定

16、连接的方向吸参与连接的类对象之间的数量对应关系 根据软件复用的要求及软件结构简洁化、清晰化的要求，优化类之间的关系 连接关系，主要是构筑消息通道。面向对象的程序设计机制提供4种手段： 引用全局对象：obj1直接引用 作为全局对象的obj2 通过参数传递: obj2作为obj1的某项操作的实际参数 引用局部对象：在obj1的 某项操作的 数数体中创建或获取obj2 通过类的成员变量： obj2作为 obj1所属类的司性的取值 利用继承关系精化设计模型 寻找类之间的公共属性和操作，引进父类捕获公共性，简化模型 将类划分为集合，针对每个集合特性设计一个父类，让集合中的所有类成为该父类的子类 可能需要

17、将多重继承化解为间重继承 对业务逻辑、界面、数据模型等不同的设计模型进行整理和融合 合交相似类 消除设计模型之间的冗余 保证一致性,4.7类设计,对类的属性和操作进行精化 对类的对象实例在其生存周期中对外部消息的响应和状态变化过程进行建模 对类中重要操作的实现过程或算法进行描述,精化类的属性与操作,属性：名称、类型号、初始值、取值范围、属性说明 操作：名称、参数表（含义参数的名称和类型、返回类型功能描述 作用范围： public:对软件系统中的所有类均可见 protected:仅对本类及其子类可见 private:仅对本类可见 确定作用范围的基本原则： 尽量缩小作用范围，每个类仅公开那些为直接

18、响应消息所必需的操作。 原则上，属性不宜公开 为了实现 类之间的关系，可能需要在类中设置相应忏悔 如果存在A到B之间的一对一关联或聚合关系，可在A中设置B的指针或引用 如果存在A到B的一多关联或聚合（非构成）关系，可在A中设置一个集合类型的属性，集合元素的类型为B的指针或引用 对构成关系，那么可考虑在A中类似于普通聚合关系，但是属性的类应修改为B而非B的引用。,为了提高运行效率，有时需要在对象的生存同期中保存计算生成的一些中间结果，以免重复计算，用空间换时间。此时可引入导出属性作为类的私有属性。 类的操作主要来源于各种设计模型和方案中对类的职责（即类的对象必须响应的消息，以及在处理这些消息的过

19、程中必须履行的职责）的规定。针对每个类的特征考虑是否添加以下操作： 对象创建 对象删除 对象比较 对象复制,类的行为模型设计,类的行为可以在两个层次上用不同方式建模： 针对整个类使用UML状态图描述其行为 针对类中某些重要的方法，用UML活动图描述其执行过程或步骤 状态图描述 状态图适于表示跨越多个用例、具有较为复杂控制行为的U单个对象的行为 明显的状态特征并且具有比较复杂的状态事件响应行为的类设计状态图 对控制类建立状态图 每个状态应该是对象在生存周期中相对比较稳定的时间段 状态图中节点表示相对稳定的状态。 活动图描述 执行比较重要的任务且控制流程较为复杂的方法 活动图中的结点主要是动作，并不维持稳定。,Withdrawal类中方法Check()执行过程的活动图,4.8 部署模型设计,部署图用来描述软件开发过程中形成哪些软件制品，软件包运行平台 中存在哪些物理节点和通信方式，以及软件制品到相应硬件节点的部署或映射。 部署模型设计一般需要考虑以下几点： 最终开发完成的软件包括哪些制品形式 软件运行环境存在哪些类型的物理节点 不同节点之间的连接和通信形式是什么 软件制品应该如何在物理节点上进行部署，即它们的部署映射关系。,1.3 漫谈设计模式 20世纪90年代，面向对象（Object-Oriented）方法与技术在国内软件业界十分火爆，人们热衷于谈论“对象”并引以为