第三部软件设计与建模(8-).ppt

2020 1 3 第三部分软件设计与建模 范锐广东海洋大学软件学院2014年3月 fanrui nc2020 1 3 第9讲软件设计 软件设计概述模块化设计软件体系结构与模式 fanrui nc2020 1 3 第9讲软件设计 软件设计概述模块化设计软件体系结构与模式 fanrui nc2020 1 3 软件设计概述 软件设计阶段的基本目标是构造系统 怎么做 的模型描述 设计先于编码 这是软件工程 推迟实现 基本原则软件系统设计是把软件需求 变换 为用于构造软件的蓝图 输入 是需求分析各种模型元素 输出 是软件设计模型和表示软件设计的目标是对将要实现的软件系统的体系结构 系统的数据 系统模块间的接口 以及所采用的算法给出详尽的描述 fanrui nc2020 1 3 软件设计三类活动 总体设计 也称概要设计 软件结构设计 或高层设计 分析需求规格说明模块划分 形成具有预定功能的模块组成结构表示出模块间的控制关系给出模块之间的接口软件详细设计 也称为 模块 过程设计 或低层设计 设计模块细节确定模块所需的算法和数据结构等测试和复审 fanrui nc2020 1 3 概要设计说明书 fanrui nc2020 1 3 详细设计说明书 fanrui nc2020 1 3 软件模块化设计 模块是一个独立命名的 拥有明确定义的输入 输出和特性的程序实体 把一个大型软件系统的全部功能 按照一定的原则合理地划分为若干个模块 每个模块完成一个特定子功能 所有的这些模块以某种结构形式组成一个整体 这就是软件的模块化设计 ModularDesign 软件模块化设计可以简化软件的设计和实现 提高软件的可理解性和可测试性 并使软件更容易得到维护 分解 抽象 逐步求精 信息隐蔽和模块独立性 是软件模块化设计的指导思想 fanrui nc2020 1 3 模块数与开发工作量 fanrui nc2020 1 3 抽象 分解必然需要抽象的支持 抽象是抓住主要问题 隐藏细节 这样才能容易分解 抽象具有不同的级别 人类解决复杂问题的基本方法之一 只有抓住事物的本质 才能准确分析和处理问题 找到合理的解决方案 fanrui nc2020 1 3 信息隐藏 信息隐蔽原则建议模块应该具有的特征是 每个模块对其他所有模块都隐蔽自己的设计决策 信息隐蔽意味着通过一系列独立的模块可以得到有效的模块化 独立的构件或模块之间的 接口 简单而清晰 fanrui nc2020 1 3 模块的独立性 模块的独立性 ModuleIndependence 是模块化 抽象 信息隐蔽等概念的直接结果 也是判断模块化结构是否合理的标准 模块独立性是指开发具有独立功能而和其他模块没有过多关联的模块 模块独立性两大优点 独立的模块由于分解了功能 简化了接口 使得软件比较容易开发 独立的模块比较容易测试和维护 模块独立性由两个定性标准度量 模块自身的内聚 Cohesion 也称为块内联系或模块强度 模块之间的耦合 Coupling 也称为块间联系 模块独立性愈高 则块内联系越强 块间联系越弱 fanrui nc2020 1 3 内聚性分类 fanrui nc2020 1 3 耦合性分类 fanrui nc2020 1 3 逐步求精 逐步求精 或称逐步细化 是一种自顶向下的设计策略 逐步求精是人类采用抽象到具体的过程把一个复杂问题趋于简单化控制和管理的有效策略 抽象和精化是互补的概念 fanrui nc2020 1 3 重构 重构是一种重新组织的技术 可以简化构件或模块的设计或编码而无需改变其功能或行为 重构是一种改进程序内部结构但不改变代码或设计的外部行为 先使它转起来 再使它快起来 fanrui nc2020 1 3 软件结构图 软件结构图 StructureChart 简称SC 是软件系统的模块层次结构 反映了整个系统的功能实现 软件结构以层次表示程序的系统结构 即一种控制的层次体系 并不表示软件的具体过程 件结构一般用树状或网状结构的图形来表示 软件结构图的主要元素有 模块 模块用带有名字的方框表示 名称应体现模块的功能 控制关系 控制关系用单向箭头或直线表示模块间的调用关系 信息传递 用带注释的短箭头表示模块调用过程中传递的信息 循环调用和选择调用 在上部模块底部加一个菱形符号表示选择调用 在上部模块的下方家一个弧形箭头 表示循环调用 fanrui nc2020 1 3 软件结构图 fanrui nc2020 1 3 模块化设计的优化 改进软件结构提高模块独立性在满足模块化要求的前提下尽量减少模块数量 在满足信息需求的前提下尽可能减少复杂的数据结构模块规模应适中软件结构的深度 宽度 扇入数和扇出数都要适当模块的作用域应该在控制域之内力求降低模块接口的复杂程度 设计单入口 单出口的模块 fanrui nc2020 1 3 软件体系结构模型 软件体系结构是一种表达 使软件工程师能够分析设计是否满足需求 选择合理的方案和降低风险 大型软件系统总是被分解成一系列子系统 由子系统提供一些相关的服务 软件体系结构设计过程就是识别出这些子系统 并建立子系统控制和通信的框架 最后给出软件体系结构的一个描述 两类结构模型 系统构成模型系统控制模型 fanrui nc2020 1 3 系统构成模型 以数据为中心的结构模型数据流结构模型客户机 服务器结构模型抽象机结构模型 fanrui nc2020 1 3 以数据为中心的结构模型 由一组子系统构成 子系统交换信息 协调工作有两种基本方法 全部共享数据放在一个中央数据库中 所有子系统都能从中存取数据 每个子系统用各自的数据库与其他子系统进行数据交互 通过消息传递来实现 共享数据模型的优点是能够高效地共享大量的数据 生产数据的子系统不需要关心数据如何被其他子系统使用 可以集中进行如备份 保密性 访问控制和错误恢复等活动 缺点是子系统一定要与以数据为中心的体系结构模型一致 系统变更或进化比较困难 子系统的需求会不同 难以集成 以及很难将数据分布到多台机器上 fanrui nc2020 1 3 数据流体系结构模型 当输入数据经过一系列的计算和操作构件或模块的变换形成输出数据时 可以应用数据流体系结构 管道和过滤器结构通过一组由管道连接的过滤器来变换数据 并向下传递 fanrui nc2020 1 3 管道和过滤器结构 fanrui nc2020 1 3 客户机 服务器结构模型 客户机 服务器结构模型的主组要成部分是 一组给其他子系统提供服务的单机服务器一组向服务器请求服务的客户机一个连接客户机和服务器的网络 可选 服务器模型能实现以数据为中心的体系结构模型的系统客户机 服务器模型的最大优势在于可以是一个分布式结构 fanrui nc2020 1 3 多媒体服务系统结构 fanrui nc2020 1 3 抽象机模型 抽象机模型也称为分层模型 是建立子系统的接口模型 它把子系统组织成一系列的层次 每一层提供一组服务 每一层定义为一个抽象机 例如 网络协议OSI参考模型 fanrui nc2020 1 3 系统控制模型 集中式控制模型调用 返回模型 这是一个自上而下的子过程模型 控制始于系统 程序 的顶层 在子系统 程序 调用过程中 控制逐步传递到更低的层次中 该模型适用于顺序执行的系统 管理者模型 这是一种适用于并发系统的模型 一个系统组件被指定为系统管理者 控制其他系统过程的启动 终止和协调 一个过程就是一个能和其他过程并发执行的子系统或模块 fanrui nc2020 1 3 并发系统的集中式控制模型 fanrui nc2020 1 3 系统控制模型 事件驱动系统广播模型 发生的事件广播到所有子系统 任何能处理该事件的子系统都会响应 该模型适用于基于网络的分布式系统 广播模型中的子系统注册其感兴趣的特别事件广播模型的优点是进化比较简单缺点是子系统都知道是否和什么时候处理事件 这可能会引起冲突 中断驱动模型 由中断处理器对来自外部的中断进行检测 然后在其他组件中处理这些中断 该模型适用于对定时有严格要求的实时系统 只用在硬件实时系统中 要求对一些事件能做出及时响应 fanrui nc2020 1 3 软件的体系结构模式 软件的体系结构模式定义了处理系统某些行为特征的方法并发性系统必须以一种模拟并行的方式来操作多个任务操作系统进程管理模式任务调度器模式包括一组含有tick 操作的活动对象持久性如果数据从创建它的进程执行以来一直存在 则该数据是持久性存在的数据 数据库管理系统模式将DBMS的存储和存取能力用于应用系统的体系结构中 应用级的持久模式在应用体系结构中建立了持久性特征 分布性强调系统或系统中构件或模块在一个分布的环境中相互通信的方式 分布性问题有两个元素 一是实体间连接方式二是实体间通信的特性代理模式是一种普遍的体系结构模式CORBA就是代理模式的一个范例 fanrui nc2020 1 3 小结 设计的基本原理和概念包括模块化 抽象 体系结构 信息隐蔽 模块独立 逐步求精和重构等 这些原理和概念描述了计算机软件的属性 所使用的设计方法和所使用的编程语言 设计通常被描述为一个多步过程 其主要任务是从需求信息中综合出数据的表示 程序结构 接口特征和过程细节 软件体系结构提供了待建系统的整体视图 它描述软件构件或模块的结构和组织 构件或模块的性质以及他们之间的连接 fanrui nc2020 1 3 第10讲结构化设计方法 1 结构化设计阶段数据流设计方法 fanrui nc2020 1 3 结构化设计概述 设计先于编码 这是软件工程 推迟实现 基本原则的又一体现 结构化设计方法 StructuredDesign SD 是基于模块化 自顶向下细化 结构化程序设计等程序设计技术基础上发展起来的 结构化设计方法用模块结构图来表达程序模块之间的关系 软件设计分为两个阶段 概要设计详细设计 fanrui nc2020 1 3 概要设计 概要设计也称总体设计 确定软件的结构以及各组成成分 子系统或模块 之间的相互关系 概要设计的主要任务是 将系统划分成模块 决定每个模块的功能 决定模块的调用关系 决定模块的界面 即模块间传递的数据 概要设计阶段的主要任务是通过数据流图来确定系统的结构图 并且对这些结构图进行分析和细化 在概要设计阶段 结构化设计主要采用面向数据流的设计方法 fanrui nc2020 1 3 详细设计 详细设计就是在概要设计的基础上决定如何具体实现各模块的内部细节 直到对系统中的每个模块给出足够详细的过程描述 在编码实现阶段就可以完全按照详细设计的细节过程来映射到代码 最终实现整个系统 一般使用结构化程序设计工具来描述 fanrui nc2020 1 3 数据流类型 根据基本系统模型 数据信息必须以 外部 信息形式进入软件系统 经过内部处理以后再以 外部 的形式离开系统 有三种数据流类型 变换型数据流事务型数据流混合型数据流 fanrui nc2020 1 3 变换型数据流 信息可以通过各种路径进入系统 信息在 流 入系统的过程中由外部形式变换成内部数据形式 这被标识为输入流 在软件的核心 输入数据经过一系列加工处理 这被标识为变换流 通过变换处理后的输出数据 沿各种路径转换为外部形式 流 出软件 这被标识为输出流 整个数据流体现了以输入 变换 输出的顺序方式 沿一定路径前行的特征 这就是变换型数据流 简称变换流 fanrui nc2020 1 3 变换型数据流 fanrui nc2020 1 3 事务型数据流 当数据流经过一个具有 事务中心 特征的数据处理时 它可以根据事务类型从多条路径的数据流中选择一条活动通路 这种具有根据条件选择处理不同事务的数据流 就是事务型数据流 简称事务流 fanrui nc2020 1 3 事务型数据流 fanrui nc2020 1 3 混合型数据流 在一个大型系统的DFD中 变换流和事务流往往会同时出现 例如 在一个事务型的DFD中 分支动作路径上的信息流也可能会体现出变换流的特征 这种具有将事务流和变换流组合出现 就是混合型数据流 简称混合流 fanrui nc2020 1 3 混合型数据流 fanrui nc2020 1 3 混合型数据流 fanrui nc2020 1 3 数据流设计方法 面向数据流分析 DFA DataFlowAnalysis 的设计是一种结构化的软件体系结构设计方法 面向数据流分析的设计能与大多数需求规格说明技术配合 可以使模块达到高内聚性 顺序性内聚 这一设计技术是从数据流图 DFD 分析模型映射为软件模块组成结构设计的描述 所以也称为结构化设计 SD StructuredDesign 方法 fanrui nc2020 1 3 数据流映射步骤 复查基本系统模型 并精化系统数据流图分析数据流类型 确定数据流具有变换流特征还是事务流特征如果是变换流特征 确定输入流和输出流的边界 也分别称为最高输入 输出抽象点 输入流边界和输出流边界之间就是变换流 也称为 变换中心 变换流加工处理的是某些形式的内部数据 如果是事务流特征 则可确定一个接收分支和一个发送分支 其中发送分支包含一个 事务中心 和各个事务动作流 采用自顶向下 逐步求精的方式完成模块分解 确定相应的软件组成结构根据模块独立性原理和运用设计度量标准 对导出的软件结构进行优化 fanrui nc2020 1 3 变换流设计 变换流设计的要点是分析数据流图 确定输入流 输出流边界 根据输入 变换 输出三个数据流分支将软件映射成一个标准的 树型 体系结构 在有多个输入流和多个输出流时 应分别找出各个输入流和输出流的边界 即最高抽象点 然后分别连接这些输入流的最高抽象点和输出流的最高抽象点 分别形成输入边界和输出边界 下面设计一个 统计输入文件中单词数目 程序 fanrui nc2020 1 3 第一次分解 fanrui nc2020 1 3 第二次分解 fanrui nc2020 1 3 事务流设计 事务流分析设计是把事务流映射成包含一个接收分支和一个发送分支的软件结构 接收分支的映射方法和变换流设计映射出输入结构的方法相似 即从事务中心的边界开始 把沿着接收流通路的处理映射成一个个模块 发送分支结构包含了一个分类控制模块和它下层的各个动作模块 数据流图的每一个事务动作流路径应映射成与其自身信息流特征相一致的结构 fanrui nc2020 1 3 事务流设计 fanrui nc2020 1 3 ATM机系统结构 fanrui nc2020 1 3 混合流设计 fanrui nc2020 1 3 混合流设计 fanrui nc2020 1 3 第11讲结构化设计方法 2 结构化程序设计案例分析 fanrui nc2020 1 3 结构化程序设计方法 结构化程序设计的理念是在20世纪60年代 由Dijkstra等人提出并加以完善的 结构化的程序一般只需要用三种基本的逻辑结构就能实现 这三种基本逻辑结构是顺序结构 选择结构和循环结构 结构化程序设计是一种设计程序的技术 它采用自顶向下逐步求精的设计方法和单入口单出口的控制结构 fanrui nc2020 1 3 结构化程序设计工具 图形工具 把过程的细节表示成一个图的组成部分 在这个图上 逻辑构造用具体的图形来表示 列表工具 用一个表来表示过程的细节 这个表列出了各种操作及其相应的条件 也即 描述了输入 处理和输出信息 语言工具 用类语言来表示过程的细节 这种类语言很接近于编程语言 fanrui nc2020 1 3 程序流程图 程序流程图又称为程序框图 Goldstine于1946年首先采用 它的主要优点是对控制流程的描绘很直观 便于初学者掌握 程序流程图的主要缺点 程序流程图本质上不是逐步求精的好工具 它诱使程序员过早地考虑程序的控制流程 而不去考虑程序的全局结构 程序流程图中用箭头代表控制流 因此程序员不受任何约束 可以完全不顾结构程序设计的精神 随意转移控制 程序流程图不易表示数据结构 fanrui nc2020 1 3 程序流程图符号 fanrui nc2020 1 3 盒图 盒图是由Nassi和Shneiderman提出的 所以又称为N S图 每个处理步骤都用一个盒子来表示 这些处理步骤可以是语句或语句序列 在需要时 盒子中还可以嵌套另一个盒子 嵌套深度一般没有限制 盒图具有下述特点 功能域 即 一个特定控制结构的作用域 明确 可以从盒图上一眼就看出来 由于只能从上边进入盒子然后从下面走出盒子 除此之外没有其它的入口和出口 所以盒图限制了任意的控制转移 保证程序有良好的结构 很容易确定局部和全程数据的作用域 很容易表现嵌套关系 也可以表示模块的层次结构 盒图很容易表示程序结构化的层次结构 确定局部和全局数据的作用域 由于没有箭头 因此不允许随意转移控制 fanrui nc2020 1 3 盒图符号 fanrui nc2020 1 3 PAD图 PAD是问题分析图 ProblemAnalysisDiagram 的英文缩写 自1973年由日本日立公司发明 它是由程序流程图演化而来 用二维树形结构的图来表示程序的控制流 将这种图翻译成程序代码比较容易 PAD图的基本原理 采用自顶向下 逐步细化和结构化设计的原则 力求将模糊的问题解的概念逐步转换为确定的和详尽的过程 使之最终可采用计算机直接进行处理 fanrui nc2020 1 3 PAD图符号 fanrui nc2020 1 3 PAD图举例 fanrui nc2020 1 3 HIPO图 HIPO HiberarchyPlusInput Process Output 层次加输入 处理 输出 图是根据IBM公司研制的软件设计与文件编制技术发展而来的 HIPO图采用功能框图和PDL来描述程序逻辑 它由两部分组成 可视目录表给出程序的层次关系体系框图 又称层次图 H图 是可视目录表的主体 用它表明各个功能的隶属关系图例 图形符号说明描述说明 每一框的补充说明IPO图则为程序各部分提供具体的工作细节 fanrui nc2020 1 3 盘存 销售系统工作流程图 fanrui nc2020 1 3 层次图 fanrui nc2020 1 3 说明 fanrui nc2020 1 3 IPO图 fanrui nc2020 1 3 详细的IPO图 fanrui nc2020 1 3 图书馆系统 fanrui nc2020 1 3 图书馆系统 fanrui nc2020 1 3 维护管理系统 fanrui nc2020 1 3 第12讲面向对象设计 面向对象设计构件设计设计模式 fanrui nc2020 1 3 系统模型描述 模型就是为了理解事物而对事物所做的一种抽象 是对事物规范的 无歧义描述的一种工具 系统模型主要建立三种模型 功能模型 指明了系统应该 做什么 动态模型 规定在何种状态下 接受什么事件的触发而 做什么 对象模型 定义了 做什么 的实体统一建模语言 UML 从不同视角为系统建模 用例模型结构 逻辑 模型行为模型实现模型实施模型 fanrui nc2020 1 3 逻辑架构 逻辑架构是软件类的宏观组织结构 它将软件类组织为包 或命名空间 子系统和层等 层是对类 包或子系统的甚为粗粒度的分组 具有对系统主要方面加以内聚的职责 通常包括的层有 用户界面层 处理用户交互信息 应用逻辑和领域对象 表示领域概念的软件对象 这些对象实现了应用需求 例如计算销售总额 技术服务 提供支持性技术服务的常用对象和子系统 UML包图通常用于描述系统得逻辑架构 层 子系统 包等 层可以建模为UML包 fanrui nc2020 1 3 对象识别 对象识别实际上是识别对象类 设计就是使用这些类来描述的 识别的方法 对系统的自然语言描述做文法分析 即名词标识技术 对象和属性是名词 操作和服务是动词 可以推理文本描述来识别候选类 然后分析去掉不能成为类的候选类 使用应用领域中的真实实体 职务 事件 交互 位置 机构等 在存在的系统中寻找对象 也可以通过识别存储结构 抽象数据结构 来识别对象 使用行为方法CRC 这种方法要求设计者了解系统的全部行为 了解各部分的各种不同的行为 对每个行为要了解是谁发起的 以及哪些实体参与了这个行为 参与一个行为 并在其中产生重要作用者即可视为对象 识别系统使用的各个脚本 并依次对其进行分析 fanrui nc2020 1 3 设计模型 面向对象设计模型是对系统中包含的对象或对象类 以及它们之间的不同类型关系的描述 面向对象的设计两类设计模型 静态模型 通过系统对象类及其之间的关系来描述系统的静态结构 在UML中常用类图 用例图 构件图 包图等描述系统中元素的关系 动态模型 描述系统的动态结构和系统对象之间的交互 在UML中常用时序图 协作图 状态图 活动图等来描述系统的行为 域类模型领域分析确定域类包模型 用包图表示 fanrui nc2020 1 3 域类模型 fanrui nc2020 1 3 包图 fanrui nc2020 1 3 对象接口描述 接口设计中应该避免涉及接口的具体表示正确的方式是将具体的接口实现方法隐藏起来 只提供对象操作来访问对象和修改数据接口可以用UML中的类图形式来描述UML的格式标记 interface 中必须包含名字部分 fanrui nc2020 1 3 图书馆系统中借书者的接口 interfaceborrower publicvoidborrower intborrowerid intbookid publicvoidsetborrower intborrowerid publicvoidaddload Loadloaditem publicvoidgetload publicvoidgetnoload publicvoidremoveload publicvoidwrite publicvoidread borrower fanrui nc2020 1 3 构件级设计 构件级设计定义了数据结构 算法 接口特征和分配给每个软件构件的通信机制 每个构件的类定义或者处理叙述都转化为一种详细设计 设计采用图形或基于文本的形式来详细说明内部的数据结构 局部接口细节和处理逻辑 设计符号包括UML图和一些辅助表示 通过一系列结构化编程结构来说明程序的设计 fanrui nc2020 1 3 构件类 构件是计算机软件中的一个模块化的构造块在OMGUML规范中将构件定义为 系统中某一定型化的 可配置的和可替换的部件 该部件封装了实现并暴露一系列接口 面向对象的观点 构件中的每一个类都被详细阐述 包括所有的属性和与其实现相关的操作 从分析模型开始 详细描述分析类 对于构件而言该类与问题域相关 和基础类 对于构件而言该类为问题域提供了支持性服务 传统观点 模块控制构件 协调问题域中所有其他构件的调用 问题域构件 完成部分或全部用户的需求 基础设施构件 负责完成问题域中所需要相关处理的功能 fanrui nc2020 1 3 构件级设计步骤 步骤1 标识出所有与问题域相对应的设计类步骤2 确定所有与基础设施相对应的设计类步骤3 细化所有不能作为复用构件的设计类在类或构件的协作时说明消息的细节为每一个构件确定适当的接口细化属性并且定义相应的数据类型和数据结构详细描述每个操作中的处理流步骤4 说明持久性数据源 数据库和文件 并确定管理数据源所需要的类步骤5 开发并且细化类或构件的行为表示步骤6 细化部署图以提供额外的实现细节步骤7 考虑每一个构件级设计表示 并且时刻考虑其他选择 fanrui nc2020 1 3 基于类的构件设计原则 开关原则 TheOpen ClosedPrinciple OCP 模块应该对外延具有开放性 对修改具有封闭性 替换原则 SubsitutionPrinciple SP 子类可以替换它们的基类 依赖倒置原则 DependencyInversionPrinciple DIP 依赖于抽象 而非具体实现接口分离原则 InterfaceSegregationPrinciple ISP 多个用户专用接口比一个通用接口要好 发布复用等价性原则 ReleaseReuseEquivalencyPrinciple REP 复用的粒度就是发布的粒度 共同封装原则 CommonClosurePrinciple CCP 一同变更的类应该和在一起 共同复用原则 CommonReusePrinciple CRP 不能一起复用的类不能被分到一组 fanrui nc2020 1 3 设计模式 有经验的软件开发者建立了既有通用原则又有惯用方案的指令系统来指导他们编制软件 如果以结构化形式对这些问题 解决方案和命名进行描述使其系统化 那么这些原则和习惯用法就可以称为模式 基于职责设计对象 GeneralResponsibilityAssignmentSoftwarePatterns GRASP 信息专家 创建者 控制器 高内聚 低耦合 多态 纯虚构 间接性和防止变异GoF GangofFour 模式23种设计模式 其中基本的有适配器 工厂 单实例类 策略 组合 外观和观察者等模式 fanrui nc2020 1 3 基于职责的设计 职责驱动设计也即基于职责的设计 在设计中软件对象具有职责 即对其所作所为进行抽象 UML把职责定义为 类元的契约或义务 就对象的角色而言 职责与对象的义务和行为相关 职责分为以下两种类型 对象的行为职责包括 自身执行一些行为 如创建对象或计算初始化其他对象中的动作控制和协调其他对象中的活动对象的认知职责包括 对私有封装数据的认知对相关对象的认知对其能够导出或计算的事物得认知职责的粒度会影响职责到类和方法的转换 fanrui nc2020 1 3 GRASP 职责不同于方法 职责是一种抽象 而方法实现了职责 绘制UML交互图时 就是在决定职责的分配 通过GRASP中的基本原则来指导如果分配职责给一个对象 五种基本的GRASP模式 创建者模式信息专家模式控制器模式低耦合模式高内聚模式 fanrui nc2020 1 3 职责与方法 fanrui nc2020 1 3 创建者模式 问题 一个对象由谁 哪个对象 创建 指导原则是 将创建一个对象A的职责分配给对象B的条件是B 包含 或组成聚集了A B记录A B紧密地使用A或者B具有A初始化数据并且在创建A时会将这些数据传递给A 简而言之 就是一个对象要由拥有或者使用其信息的 与其有密切关系的另一个已存在的对象创建 例如在POS机系统中的Sale对象是由那个对象类创建 对于对象Sale由谁创建 分析一下领域模型就会发现 可以认为Register是记录Sale的类 因此Register对象是创建Sale对象的合理选择 fanrui nc2020 1 3 POS机系统中谁创建Sale对象 fanrui nc2020 1 3 信息专家模式 信息专家 通常称为专家 模式是最基本的职责分配原则之一 创建者是对象的行为职责 而信息专家常常指的是对象的认知职责 指导原则是 给对象分配职责时 应该把职责分配给具有完成该职责所需要信息的那个类 例如在POS机系统中 销售的总额该如果确定 决定总额的一些元素应该是属于哪些对象的信息 按照信息专家的建议 这里应当寻找具有确定总额所需信息的那个对象类 分析领域模型和设计模型得到 要计算总额应该知道销售的所有SalesLineItem实例及其小计之和 Sale实例包含了上述信息 为了确定商品的小计 这里需要SalesLineItem quantity 和ProductDescription price SalesLineItem知道其数量和与其关联的ProductDescription fanrui nc2020 1 3 计算销售总额 fanrui nc2020 1 3 控制器模式 根据MVS ModelViewSeparation 原则 UI对象不应当包含应用逻辑或业务逻辑 应该把UI层的操作或者请求委派给一个协调者 由协调者把任务转发给领域层的领域对象 控制器就是这样一个协调者 例如在POS机系统中 enterItem和endSale这样的系统事件 应使用谁作为控制器 指导原则是 控制器是UI层之上的第一个对象 它负责接收和处理系统操作消息 控制器的选择原则是 代表全部 系统 根对象 运行软件的设备或主要的子系统 如 外观控制器 代表发生系统操作的用例场景 如 会话控制器 在用例场景中发生的系统事件通常命名为Handler Coordinator或Session 对于用同一用例场景的所有系统事件使用相同的控制器类 fanrui nc2020 1 3 控制器类 fanrui nc2020 1 3 低耦合模式 低耦合模式是一个评价模式 低耦合原则适用于软件开发的很多方面 它是构件软件最重要的目标之一 指导原则是 分配职责以使耦合保持在较低的水平 在真实世界领域中 Register记录了Payment 所以创建者模式建议将Register作为创建Payment的候选者 Register实例会把addPayment消息发送给Sale 并把新的Payment作为参数传递给它 这种职责分配使Register类和Payment类之间产生了耦合 即Register类要知道Payment类 fanrui nc2020 1 3 高耦合问题 fanrui nc2020 1 3 低耦合解决方案 fanrui nc2020 1 3 高内聚模式 高内聚模式是一个评价模式 内聚是软件设计中的一种基本品质 内聚可以非正式地用于度量软件元素操作在功能上的相关程度 也可以用于度量软件元素完成的工作量 指导原则是 分配职责可保持较高的内聚性 fanrui nc2020 1 3 低内聚问题 fanrui nc2020 1 3 高内聚解决方案 fanrui nc2020 1 3 第13讲面向对象设计方法 面向对象详细设计案例分析 fanrui nc2020 1 3 面向对象详细设计 面向对象详细设计的目的就是不断精化设计类领域模型也称为概念模型 领域对象模型和分析对象模型 领域模型的精化对类图和交互图的精化起了至关重要的作用 也是设计个良好系统的关键 使用泛化 特化 关联类 时间间隔 组合和包等概念精化领域模型 fanrui nc2020 1 3 泛化和特化 泛化是在多个概念中识别共性和定义超类 普遍概念 与子类 具体概念 关系的活动 例如在POS机系统中CashPayment CreditPayment和ChequePayment 在领域中识别父类和子类是一个有价值的活动 这样可以使我们对概念有更概括 精炼和抽象的描述 fanrui nc2020 1 3 POS机系统中Payment fanrui nc2020 1 3 定义概念超类和子类 概念超类的定义较子类的定义更为概括或包含范围更广 例如 在POS机系统中 考虑超类Payment和它的子类 将概念类划分为子类的动机有 子类有额外的有意义的属性 子类有额外的有意义的关联 子类概念的操作 处理 反应或使用的方式不同于其超类或其他子类 而这些方式是我们所关注的 子类概念表示了一个活动体 其行为与超类或者其他子类不同 而这些行为是我们所关注的 泛化和定义概念超类的动机 潜在的概念子类表示的是相似概念的不同变体 子类满足100 准则 即概念超类的定义必须100 适用于子类 子类必须100 与超类一致 所有子类都具有相同的属性 可以将其解析出来并在超类中表达 所有子类都具有相同的关联 可以将其解析出来并与超类关联 fanrui nc2020 1 3 Payment类层次划分 fanrui nc2020 1 3 关联类 原则 在领域模型中 如果类A可能同时有多个相同的属性B 则不要将属性B置于A之中 应该将属性B放在另一个类C中 并且将其与类A关联 这样就得出一个关联类C 在POS机系统中 授权服务给每个商店分配一个商业ID 商店发送授权服务的支付授权请求需要商业ID标识商店 商店对于每个服务有不同的商业ID Store可能有多个merchantID值 所以将merchantID作为Store的属性是不正确的 同理 放入AuthorizationService中也不正确 可以用一个关联类ServiceContract来拥有属性merchantID关联类的增加具有原则 有某个属性与关联相关 关联类的实例具有依赖于关联的生命期 两个概念之间有多对多关联 并且存在与关联自身相关的信息 fanrui nc2020 1 3 关联类 fanrui nc2020 1 3 聚合关系和组合关系 聚合是UML中的是UML中的一种模糊关联 其不明确的暗示了整体和部分关系 组合也称组成聚合 是一种强的整体 部分聚合关系 并且在某些模型中具有效用 组合关系意味着 在某一时刻 部分的一个实例只属于一个组成实例 部分必须总是属于组成 组成要负责创建和删除部分 可以自己创建和删除部分也可以和其它对象协作进行创建和删除部分 组成被销毁 其部分必须要销毁 组合关系的识别准则是 部分的生命期在组成的生命期之内 部分的创建饿删除依赖于整体 在物理或者逻辑组装上 有明确的整体 部分关系 组成的某些属性会传递给部分 对组成的操作可能传递给部分 fanrui nc2020 1 3 识别和显示组合关系 好处 有利于澄清部分对整体的依赖的领域约束 有助于使用GRASP创建者模式识别创建者 对整体的复制 拷贝这些操作经常会传递给部分 在POS机系统中 SalesLineItems可以被视为Sale的组成部分 ProductCatalog是ProductDescriptions的一个组成 fanrui nc2020 1 3 组合关系 fanrui nc2020 1 3 时间间隔 例如 POS机系统在初始设计时 SalesLineItems与ProductDescriptions关联 记录了销售项的价格 在精化过程中 需要关注与信息 合同等相关的时间间隔问题 如果SalesLineItems从ProductDescriptions取得当前价格 当价格改变时 以前的销售将指向新的价格 这很显然是不正确的 需要区别销售发生时的历史价格和当前价格 基于信息需求 可以采用两种方法对此问题解决 一是可以在ProductDescriptions中保存当前价格 仅将销售发生时的价格写入SalesLineItem 二是将一组ProductPrices与ProductDescriptions关联 每个ProductPrices关联适用的时间间隔 fanrui nc2020 1 3 区别历史价格和当前价格 fanrui nc2020 1 3 使用包来组织领域模型 将领域模型划分成包结构时 将满足下述条件的元素放在一起 在同一个主题领域 概念或目标密切相关的元素 在同一个类层次结构中的关系 参与同一个用例的元素 有很强的关联性的元素 例如 在POS机系统领域模型中包的结构 fanrui nc2020 1 3 POS机系统领域模型 fanrui nc2020 1 3 包嵌套 fanrui nc2020 1 3 逻辑架构精化 在逻辑架构精化设计中主要更细化各层内部元素 层与层之间关系和分层架构中一些模式的应用 遵循模型 视图 控制器 MVC 三层模型 在精化逻辑模型时首先要进一步指出个系统层之间 包之间的关系 可以用依赖线来表达包或者包内类型之间的耦合 依赖线可以由一个包发出例如在POS机系统中从Sale包指向POSRuleEngineFacade类 从Domain包指向Log4J包 fanrui nc2020 1 3 fanrui nc2020 1 3 简单包和子系统 fanrui nc2020 1 3 外观和控制器 fanrui nc2020 1 3 模型 视图分离和 向上 通信 fanrui nc2020 1 3 包设计准则 包在水平和垂直划分上的功能性内聚由一族接口组成的包正式包和聚集不稳定类的包职责越多的包越需要稳定将不相关的类型分离出去使用工厂模式减少对具体包的依赖 fanrui nc2020 1 3 分离不相关的类型 fanrui nc2020 1 3 具体包的依赖 fanrui nc2020 1 3 工厂模式减少对具体包的依赖 fanrui nc2020 1 3 精化的交互图 在交互图中 领域模型指出了需要设计的软件对象 设计模型中的设计类是以领域模型的类为基础的 在顺序图和协作图精化设计中 一些类直接来自前面的分析模型中的类 还有一些针对软件系统的更好的实现虚构出来的 例如设计makeNewSale操作 要处理一次新的销售 首先必须创建软件对象Sale 根据控制器模式我们还需要设计一个转发makeNewSale请求的对象Register Register是记录Sale的类 又根据创建者模式得出应该由Register创建Sale 在销售过程中必须设计一个集合来存储一系列的商品 所有由Sale对象创建了记录所有将来会添加的集合SalesLineItem实例 fanrui nc2020 1 3 精化设计类 fanrui nc2020 1 3 输入商品 fanrui nc2020 1 3 结束销售 fanrui nc2020 1 3 获取总价 fanrui nc2020 1 3 处理支付 fanrui nc2020 1 3 计算找零 fanrui nc2020 1 3 精化的类图 类图和对象图是设计阶段的主要制品顺序图和协作图中的消息映射为类图中的方法 交互消息的对象映射为类的对象 每个消息的交互实现映射为类图和对象图中方法的实现 在类图的精化设计中不仅要得到每个类中的属性和方法 还要有方法的粗略实现 也即方法的实现过程 fanrui nc2020 1 3 可见性的设计 可见性的设计主要有四种 属性可见性参数可见性局部可见性全局可见性 classRegister privateProductCalatogcatalog publicvoidenterItem itemID qty desc catalog getProductDesc itemID fanrui nc2020 1 3 类图的细化 类图的设计是以交互图的设计为基础的 类图中的元素也是从交互图中抽象提取出来的 通过交互图中对象之间的交互 找出对象所属的类以及类之间的关系 通过对交互图中对象之间消息的交互的分析和细化得到类图中的属性和方法 对类图进行分析的时候也必须理解类图和类之间的关系如何映射得到具体的实现类 fanrui nc2020 1 3 输入商品条目的类图 fanrui nc2020 1 3 细化的类图 fanrui nc2020 1 3 实现 publicclassRegister privateProductCatalogcatalog privateSalecurrentSale publicRegister ProductCatalogpc publicvoide