第三部软件设计与建模演示文稿

第三部软件设计与建模演示文稿2023/4/18现在是1页\一共有171页\编辑于星期四2023/4/18（优选）第三部软件设计与建模现在是2页\一共有171页\编辑于星期四第9讲软件设计软件设计概述模块化设计软件体系结构与模式现在是3页\一共有171页\编辑于星期四软件设计概述软件设计阶段的基本目标是构造系统“怎么做”的模型描述。“设计先于编码”，这是软件工程“推迟实现”基本原则软件系统设计是把软件需求“变换”为用于构造软件的蓝图。“输入”是需求分析各种模型元素“输出”是软件设计模型和表示软件设计的目标是对将要实现的软件系统的体系结构、系统的数据、系统模块间的接口，以及所采用的算法给出详尽的描述。现在是4页\一共有171页\编辑于星期四软件设计三类活动总体设计，也称概要设计，软件结构设计，或高层设计。分析需求规格说明模块划分，形成具有预定功能的模块组成结构表示出模块间的控制关系给出模块之间的接口软件详细设计，也称为（模块）过程设计，或低层设计。设计模块细节确定模块所需的算法和数据结构等测试和复审现在是5页\一共有171页\编辑于星期四概要设计说明书1范围1.1系统目标1.2主要软件需求1.3软件设计约束、限制2数据设计2.1数据对象和形成的数据结构2.2文件和数据库结构外部文件结构①逻辑结构②逻辑记录描述③访问方法全局数据文件和数据交叉索引3体系结构设计3.1数据和控制流复审3.2得出的程序结构4接口设计4.1人机界面规约4.2人机界面设计规约4.3外部接口设计外部数据接口外部系统或设备接口4.4内部接口设计规约5（每个模块）过程设计5.1处理说明5.2接口描述5.3设计语言描述5.4使用的模块5.5内部设计结构5.6注释/约束/限制6需求交叉索引7测试部分7.1测试方针7.2集成策略7.3特殊考虑8附录（包括特殊注解）现在是6页\一共有171页\编辑于星期四详细设计说明书1引言1.1编写目的：阐明编写详细设计说明书的目的，指明读者对象。1.2项目背景：应包括项目的来源和主管部门等。1.3定义：列出本文档中所用到的专门术语的定义和缩写词。●列出有关资料的作者、标题、编号、发表日期、出版单位或资料来源●文档所引用的资料、软件开发的标准或规范。1.4参考资料：项目经核准的计划任务书、合同或上级机关的批文；项目开发计划；需求规格说明书；概要设计说明书；测试计划（初稿）；用户操作手册。2总体设计2.1需求概述2.2软件结构：如给出软件系统的结构图。3程序描述3.1逐个模块给出以下说明：●性能●输出项目●功能●输入项目3.2算法：模块所选用的算法。3.3程序逻辑：详细描述模块实现的算法，可采用：标准流程图；PDL语言；N-S图；判定表等描述算法的图表。3.4接口●限制条件●存储分配3.5测试要点：给出测试模块的主要测试要求。现在是7页\一共有171页\编辑于星期四软件模块化设计模块是一个独立命名的，拥有明确定义的输入、输出和特性的程序实体。把一个大型软件系统的全部功能，按照一定的原则合理地划分为若干个模块，每个模块完成一个特定子功能，所有的这些模块以某种结构形式组成一个整体，这就是软件的模块化设计（ModularDesign）。软件模块化设计可以简化软件的设计和实现，提高软件的可理解性和可测试性，并使软件更容易得到维护。分解、抽象、逐步求精、信息隐蔽和模块独立性，是软件模块化设计的指导思想。现在是8页\一共有171页\编辑于星期四模块数与开发工作量开发工作量模块数最小成本区模块成本接口成本总成本现在是9页\一共有171页\编辑于星期四抽象分解必然需要抽象的支持。抽象是抓住主要问题，隐藏细节，这样才能容易分解。抽象具有不同的级别。人类解决复杂问题的基本方法之一。只有抓住事物的本质，才能准确分析和处理问题，找到合理的解决方案。现在是10页\一共有171页\编辑于星期四信息隐藏信息隐蔽原则建议模块应该具有的特征是：每个模块对其他所有模块都隐蔽自己的设计决策。信息隐蔽意味着通过一系列独立的模块可以得到有效的模块化。独立的构件或模块之间的“接口”简单而清晰。现在是11页\一共有171页\编辑于星期四模块的独立性模块的独立性（ModuleIndependence）是模块化、抽象、信息隐蔽等概念的直接结果，也是判断模块化结构是否合理的标准。模块独立性是指开发具有独立功能而和其他模块没有过多关联的模块。模块独立性两大优点：独立的模块由于分解了功能，简化了接口，使得软件比较容易开发；独立的模块比较容易测试和维护。模块独立性由两个定性标准度量：模块自身的内聚（Cohesion）），也称为块内联系或模块强度，模块之间的耦合（Coupling)，也称为块间联系。模块独立性愈高，则块内联系越强，块间联系越弱。现在是12页\一共有171页\编辑于星期四内聚性分类偶然性内聚弱逻辑性内聚时间性内聚过程性内聚通信性内聚顺序性内聚功能性内聚强低内聚中内聚高内聚现在是13页\一共有171页\编辑于星期四耦合性分类非直接耦合弱数据耦合特征耦合控制耦合外部耦合公共耦合内容耦合强弱耦合中耦合强耦合较强耦合现在是14页\一共有171页\编辑于星期四逐步求精逐步求精，或称逐步细化，是一种自顶向下的设计策略。逐步求精是人类采用抽象到具体的过程把一个复杂问题趋于简单化控制和管理的有效策略。抽象和精化是互补的概念。现在是15页\一共有171页\编辑于星期四重构重构是一种重新组织的技术，可以简化构件或模块的设计或编码而无需改变其功能或行为。重构是一种改进程序内部结构但不改变代码或设计的外部行为。“先使它转起来，再使它快起来”。现在是16页\一共有171页\编辑于星期四软件结构图软件结构图（StructureChart,简称SC）是软件系统的模块层次结构，反映了整个系统的功能实现。软件结构以层次表示程序的系统结构，即一种控制的层次体系，并不表示软件的具体过程。件结构一般用树状或网状结构的图形来表示。软件结构图的主要元素有：模块：模块用带有名字的方框表示，名称应体现模块的功能。控制关系：控制关系用单向箭头或直线表示模块间的调用关系。信息传递：用带注释的短箭头表示模块调用过程中传递的信息。循环调用和选择调用：在上部模块底部加一个菱形符号表示选择调用，在上部模块的下方家一个弧形箭头，表示循环调用。现在是17页\一共有171页\编辑于星期四软件结构图MNOPQGHICDATJKLEFBRS现在是18页\一共有171页\编辑于星期四模块化设计的优化改进软件结构提高模块独立性在满足模块化要求的前提下尽量减少模块数量，在满足信息需求的前提下尽可能减少复杂的数据结构模块规模应适中软件结构的深度、宽度、扇入数和扇出数都要适当模块的作用域应该在控制域之内力求降低模块接口的复杂程度，设计单入口、单出口的模块现在是19页\一共有171页\编辑于星期四软件体系结构模型软件体系结构是一种表达，使软件工程师能够分析设计是否满足需求、选择合理的方案和降低风险。大型软件系统总是被分解成一系列子系统，由子系统提供一些相关的服务。软件体系结构设计过程就是识别出这些子系统，并建立子系统控制和通信的框架，最后给出软件体系结构的一个描述。两类结构模型：系统构成模型系统控制模型现在是20页\一共有171页\编辑于星期四系统构成模型以数据为中心的结构模型数据流结构模型客户机/服务器结构模型抽象机结构模型现在是21页\一共有171页\编辑于星期四以数据为中心的结构模型由一组子系统构成，子系统交换信息，协调工作有两种基本方法：全部共享数据放在一个中央数据库中，所有子系统都能从中存取数据。每个子系统用各自的数据库与其他子系统进行数据交互，通过消息传递来实现。共享数据模型的优点是能够高效地共享大量的数据，生产数据的子系统不需要关心数据如何被其他子系统使用，可以集中进行如备份、保密性、访问控制和错误恢复等活动；缺点是子系统一定要与以数据为中心的体系结构模型一致，系统变更或进化比较困难，子系统的需求会不同，难以集成，以及很难将数据分布到多台机器上。现在是22页\一共有171页\编辑于星期四数据流体系结构模型当输入数据经过一系列的计算和操作构件或模块的变换形成输出数据时，可以应用数据流体系结构。管道和过滤器结构通过一组由管道连接的过滤器来变换数据，并向下传递。现在是23页\一共有171页\编辑于星期四管道和过滤器结构过滤器过滤器过滤器过滤器过滤器过滤器过滤器过滤器现在是24页\一共有171页\编辑于星期四客户机/服务器结构模型客户机/服务器结构模型的主组要成部分是：一组给其他子系统提供服务的单机服务器一组向服务器请求服务的客户机 一个连接客户机和服务器的网络（可选）服务器模型能实现以数据为中心的体系结构模型的系统客户机/服务器模型的最大优势在于可以是一个分布式结构现在是25页\一共有171页\编辑于星期四多媒体服务系统结构网络目录服务器目录视频服务器电影文件图片服务器图片文件web服务器超文本文件客户1客户2客户n………现在是26页\一共有171页\编辑于星期四抽象机模型抽象机模型也称为分层模型，是建立子系统的接口模型。它把子系统组织成一系列的层次，每一层提供一组服务，每一层定义为一个抽象机。例如：网络协议OSI参考模型通信介质应用层表示层会话层传输层网络层数据链路层物理层用户B应用层表示层会话层传输层网络层数据链路层物理层用户A现在是27页\一共有171页\编辑于星期四系统控制模型集中式控制模型调用—返回模型：这是一个自上而下的子过程模型。控制始于系统（程序）的顶层，在子系统（程序）调用过程中，控制逐步传递到更低的层次中。该模型适用于顺序执行的系统。管理者模型：这是一种适用于并发系统的模型。一个系统组件被指定为系统管理者，控制其他系统过程的启动、终止和协调。一个过程就是一个能和其他过程并发执行的子系统或模块。现在是28页\一共有171页\编辑于星期四并发系统的集中式控制模型系统控制器故障处理器用户界面传感器进程传动装置进程计算进程现在是29页\一共有171页\编辑于星期四系统控制模型事件驱动系统广播模型：发生的事件广播到所有子系统，任何能处理该事件的子系统都会响应。该模型适用于基于网络的分布式系统。广播模型中的子系统注册其感兴趣的特别事件广播模型的优点是进化比较简单缺点是子系统都知道是否和什么时候处理事件，这可能会引起冲突。中断驱动模型：由中断处理器对来自外部的中断进行检测，然后在其他组件中处理这些中断。该模型适用于对定时有严格要求的实时系统。只用在硬件实时系统中，要求对一些事件能做出及时响应现在是30页\一共有171页\编辑于星期四软件的体系结构模式软件的体系结构模式定义了处理系统某些行为特征的方法并发性系统必须以一种模拟并行的方式来操作多个任务操作系统进程管理模式任务调度器模式包括一组含有tick()操作的活动对象持久性如果数据从创建它的进程执行以来一直存在，则该数据是持久性存在的数据。数据库管理系统模式将DBMS的存储和存取能力用于应用系统的体系结构中。应用级的持久模式在应用体系结构中建立了持久性特征。分布性强调系统或系统中构件或模块在一个分布的环境中相互通信的方式。分布性问题有两个元素：一是实体间连接方式二是实体间通信的特性代理模式是一种普遍的体系结构模式CORBA就是代理模式的一个范例现在是31页\一共有171页\编辑于星期四小结设计的基本原理和概念包括模块化、抽象、体系结构、信息隐蔽、模块独立、逐步求精和重构等，这些原理和概念描述了计算机软件的属性、所使用的设计方法和所使用的编程语言。设计通常被描述为一个多步过程，其主要任务是从需求信息中综合出数据的表示、程序结构、接口特征和过程细节。软件体系结构提供了待建系统的整体视图，它描述软件构件或模块的结构和组织、构件或模块的性质以及他们之间的连接。现在是32页\一共有171页\编辑于星期四第10讲结构化设计方法（1）结构化设计阶段数据流设计方法现在是33页\一共有171页\编辑于星期四结构化设计概述设计先于编码”，这是软件工程“推迟实现”基本原则的又一体现。结构化设计方法（StructuredDesign,SD)是基于模块化、自顶向下细化、结构化程序设计等程序设计技术基础上发展起来的。结构化设计方法用模块结构图来表达程序模块之间的关系。软件设计分为两个阶段：概要设计详细设计现在是34页\一共有171页\编辑于星期四概要设计概要设计也称总体设计，确定软件的结构以及各组成成分(子系统或模块)之间的相互关系。概要设计的主要任务是：将系统划分成模块；决定每个模块的功能；决定模块的调用关系；决定模块的界面，即模块间传递的数据。概要设计阶段的主要任务是通过数据流图来确定系统的结构图，并且对这些结构图进行分析和细化。在概要设计阶段，结构化设计主要采用面向数据流的设计方法。现在是35页\一共有171页\编辑于星期四详细设计详细设计就是在概要设计的基础上决定如何具体实现各模块的内部细节，直到对系统中的每个模块给出足够详细的过程描述。在编码实现阶段就可以完全按照详细设计的细节过程来映射到代码，最终实现整个系统。一般使用结构化程序设计工具来描述现在是36页\一共有171页\编辑于星期四数据流类型根据基本系统模型，数据信息必须以“外部”信息形式进入软件系统，经过内部处理以后再以“外部”的形式离开系统。有三种数据流类型：变换型数据流事务型数据流混合型数据流现在是37页\一共有171页\编辑于星期四变换型数据流信息可以通过各种路径进入系统，信息在“流”入系统的过程中由外部形式变换成内部数据形式，这被标识为输入流。在软件的核心，输入数据经过一系列加工处理，这被标识为变换流。通过变换处理后的输出数据，沿各种路径转换为外部形式“流”出软件，这被标识为输出流。整个数据流体现了以输入、变换、输出的顺序方式，沿一定路径前行的特征，这就是变换型数据流，简称变换流。现在是38页\一共有171页\编辑于星期四变换型数据流时间输入流输出流变换流信息现在是39页\一共有171页\编辑于星期四事务型数据流当数据流经过一个具有“事务中心”特征的数据处理时，它可以根据事务类型从多条路径的数据流中选择一条活动通路。这种具有根据条件选择处理不同事务的数据流，就是事务型数据流，简称事务流。现在是40页\一共有171页\编辑于星期四事务型数据流……活动通路……………………事务中心⊕⊕⊕现在是41页\一共有171页\编辑于星期四混合型数据流在一个大型系统的DFD中，变换流和事务流往往会同时出现。例如，在一个事务型的DFD中，分支动作路径上的信息流也可能会体现出变换流的特征。这种具有将事务流和变换流组合出现，就是混合型数据流，简称混合流。现在是42页\一共有171页\编辑于星期四混合型数据流现在是43页\一共有171页\编辑于星期四混合型数据流变换3……变换2传出数据传入数据事务中心变换1结果现在是44页\一共有171页\编辑于星期四数据流设计方法面向数据流分析（DFA，DataFlowAnalysis）的设计是一种结构化的软件体系结构设计方法。面向数据流分析的设计能与大多数需求规格说明技术配合，可以使模块达到高内聚性（顺序性内聚）。这一设计技术是从数据流图（DFD）分析模型映射为软件模块组成结构设计的描述，所以也称为结构化设计（SD，StructuredDesign）方法。现在是45页\一共有171页\编辑于星期四数据流映射步骤复查基本系统模型，并精化系统数据流图分析数据流类型，确定数据流具有变换流特征还是事务流特征如果是变换流特征，确定输入流和输出流的边界（也分别称为最高输入/输出抽象点），输入流边界和输出流边界之间就是变换流，也称为“变换中心”。变换流加工处理的是某些形式的内部数据。如果是事务流特征，则可确定一个接收分支和一个发送分支。其中发送分支包含一个“事务中心”和各个事务动作流。采用自顶向下、逐步求精的方式完成模块分解，确定相应的软件组成结构根据模块独立性原理和运用设计度量标准，对导出的软件结构进行优化现在是46页\一共有171页\编辑于星期四变换流设计变换流设计的要点是分析数据流图，确定输入流、输出流边界，根据输入、变换、输出三个数据流分支将软件映射成一个标准的“树型”体系结构。在有多个输入流和多个输出流时，应分别找出各个输入流和输出流的边界，即最高抽象点，然后分别连接这些输入流的最高抽象点和输出流的最高抽象点，分别形成输入边界和输出边界。下面设计一个“统计输入文件中单词数目”程序。输入流边界输出流边界有效的文件名单词总数格式化单词数验证文件名统计单词数格式化单词数读文件名文件名单词总数显示单词数文件名现在是47页\一共有171页\编辑于星期四第一次分解文件单词数目统计读取和验证文件名统计单词数目格式化和显示单词数现在是48页\一共有171页\编辑于星期四第二次分解文件单词数目统计读取和验证文件名统计单词数目格式化和显示单词数格式化单词数显示单词数读文件名验证文件名现在是49页\一共有171页\编辑于星期四事务流设计事务流分析设计是把事务流映射成包含一个接收分支和一个发送分支的软件结构。接收分支的映射方法和变换流设计映射出输入结构的方法相似，即从事务中心的边界开始，把沿着接收流通路的处理映射成一个个模块。发送分支结构包含了一个分类控制模块和它下层的各个动作模块。数据流图的每一个事务动作流路径应映射成与其自身信息流特征相一致的结构。现在是50页\一共有171页\编辑于星期四事务流设计事务选择确定事务类型审计记录事务1事务2事务3事务4审计信息事务5更新事务v有效事务查询更新事务w有效事务存款更新事务x有效事务取款更新事务y有效事务转账更新事务z有效事务修改密码现在是51页\一共有171页\编辑于星期四ATM机系统结构ATM机处理事务主控调度器更新文件查询编辑事务分析器事务选择存款转账取款修改密码现在是52页\一共有171页\编辑于星期四混合流设计读入数据判别

订货处理

订货输入

提货发票进货输入

库存修改

进货票据

订单记录

分析统计生成统计表现在是53页\一共有171页\编辑于星期四混合流设计现在是54页\一共有171页\编辑于星期四第11讲结构化设计方法（2）结构化程序设计案例分析现在是55页\一共有171页\编辑于星期四结构化程序设计方法结构化程序设计的理念是在20世纪60年代，由Dijkstra等人提出并加以完善的。结构化的程序一般只需要用三种基本的逻辑结构就能实现。这三种基本逻辑结构是顺序结构、选择结构和循环结构。结构化程序设计是一种设计程序的技术，它采用自顶向下逐步求精的设计方法和单入口单出口的控制结构。现在是56页\一共有171页\编辑于星期四结构化程序设计工具图形工具：把过程的细节表示成一个图的组成部分，在这个图上，逻辑构造用具体的图形来表示。列表工具：用一个表来表示过程的细节，这个表列出了各种操作及其相应的条件。也即，描述了输入、处理和输出信息。语言工具：用类语言来表示过程的细节，这种类语言很接近于编程语言。现在是57页\一共有171页\编辑于星期四程序流程图程序流程图又称为程序框图，Goldstine于1946年首先采用。它的主要优点是对控制流程的描绘很直观，便于初学者掌握。程序流程图的主要缺点：程序流程图本质上不是逐步求精的好工具，它诱使程序员过早地考虑程序的控制流程，而不去考虑程序的全局结构；程序流程图中用箭头代表控制流，因此程序员不受任何约束，可以完全不顾结构程序设计的精神，随意转移控制；程序流程图不易表示数据结构。现在是58页\一共有171页\编辑于星期四程序流程图符号（a）预处理（b）选择（c）多分支（d）循环上界（e）循环下界（f）开始/结束（g）准备（h）注释（i）虚线（j）省略（k）并行方式（l）控制流现在是59页\一共有171页\编辑于星期四盒图盒图是由Nassi和Shneiderman提出的，所以又称为N-S图。每个处理步骤都用一个盒子来表示，这些处理步骤可以是语句或语句序列，在需要时，盒子中还可以嵌套另一个盒子，嵌套深度一般没有限制。盒图具有下述特点：功能域（即，一个特定控制结构的作用域）明确，可以从盒图上一眼就看出来。由于只能从上边进入盒子然后从下面走出盒子，除此之外没有其它的入口和出口，所以盒图限制了任意的控制转移，保证程序有良好的结构。很容易确定局部和全程数据的作用域。很容易表现嵌套关系，也可以表示模块的层次结构。盒图很容易表示程序结构化的层次结构，确定局部和全局数据的作用域。由于没有箭头，因此不允许随意转移控制。现在是60页\一共有171页\编辑于星期四盒图符号现在是61页\一共有171页\编辑于星期四PAD图PAD是问题分析图（ProblemAnalysisDiagram）的英文缩写，自1973年由日本日立公司发明。它是由程序流程图演化而来，用二维树形结构的图来表示程序的控制流，将这种图翻译成程序代码比较容易。PAD图的基本原理：采用自顶向下、逐步细化和结构化设计的原则，力求将模糊的问题解的概念逐步转换为确定的和详尽的过程，使之最终可采用计算机直接进行处理。现在是62页\一共有171页\编辑于星期四PAD图符号现在是63页\一共有171页\编辑于星期四PAD图举例现在是64页\一共有171页\编辑于星期四HIPO图HIPO（HiberarchyPlusInput-Process-Output,层次加输入-处理-输出）图是根据IBM公司研制的软件设计与文件编制技术发展而来的。HIPO图采用功能框图和PDL来描述程序逻辑，它由两部分组成：可视目录表给出程序的层次关系体系框图：又称层次图（H图），是可视目录表的主体，用它表明各个功能的隶属关系图例：图形符号说明描述说明：每一框的补充说明IPO图则为程序各部分提供具体的工作细节现在是65页\一共有171页\编辑于星期四盘存／销售系统工作流程图现在是66页\一共有171页\编辑于星期四层次图现在是67页\一共有171页\编辑于星期四说明现在是68页\一共有171页\编辑于星期四IPO图现在是69页\一共有171页\编辑于星期四详细的IPO图现在是70页\一共有171页\编辑于星期四图书馆系统现在是71页\一共有171页\编辑于星期四图书馆系统现在是72页\一共有171页\编辑于星期四维护管理系统现在是73页\一共有171页\编辑于星期四第12讲面向对象设计面向对象设计构件设计设计模式现在是74页\一共有171页\编辑于星期四系统模型描述模型就是为了理解事物而对事物所做的一种抽象，是对事物规范的、无歧义描述的一种工具。系统模型主要建立三种模型：功能模型：指明了系统应该“做什么”动态模型：规定在何种状态下，接受什么事件的触发而“做什么”对象模型：定义了“做什么”的实体统一建模语言（UML）从不同视角为系统建模。用例模型结构（逻辑）模型行为模型实现模型实施模型现在是75页\一共有171页\编辑于星期四逻辑架构逻辑架构是软件类的宏观组织结构，它将软件类组织为包（或命名空间）、子系统和层等。层是对类、包或子系统的甚为粗粒度的分组，具有对系统主要方面加以内聚的职责。通常包括的层有：用户界面层：处理用户交互信息。应用逻辑和领域对象：表示领域概念的软件对象，这些对象实现了应用需求。例如计算销售总额。 技术服务：提供支持性技术服务的常用对象和子系统。UML包图通常用于描述系统得逻辑架构—层、子系统、包等。层可以建模为UML包。现在是76页\一共有171页\编辑于星期四对象识别对象识别实际上是识别对象类，设计就是使用这些类来描述的。识别的方法：对系统的自然语言描述做文法分析，即名词标识技术。对象和属性是名词，操作和服务是动词，可以推理文本描述来识别候选类，然后分析去掉不能成为类的候选类。使用应用领域中的真实实体、职务、事件、交互、位置、机构等，在存在的系统中寻找对象。也可以通过识别存储结构（抽象数据结构）来识别对象。使用行为方法CRC：这种方法要求设计者了解系统的全部行为，了解各部分的各种不同的行为。对每个行为要了解是谁发起的，以及哪些实体参与了这个行为。参与一个行为，并在其中产生重要作用者即可视为对象。识别系统使用的各个脚本，并依次对其进行分析。现在是77页\一共有171页\编辑于星期四设计模型面向对象设计模型是对系统中包含的对象或对象类，以及它们之间的不同类型关系的描述。面向对象的设计两类设计模型:静态模型:通过系统对象类及其之间的关系来描述系统的静态结构。在UML中常用类图、用例图、构件图、包图等描述系统中元素的关系。动态模型:描述系统的动态结构和系统对象之间的交互。在UML中常用时序图、协作图、状态图、活动图等来描述系统的行为。域类模型领域分析确定域类包模型：用包图表示现在是78页\一共有171页\编辑于星期四域类模型<BusinessObject>Item-id:integer+findonTitle()+findonid()+findonReservation()create()destroy<BusinessObject>Loan-id:integer-borroweddate:date-returndate:date-borrowerid:integercreate()destroybeloanedina<BusinessObject>Borrower-borrowerid:integer-name:string-borrowednum:integer-fine:number+find()create()destroyhashasbereservedina<BusinessObject>Title-bookid:string-borrowednum:integer-reservatednum:integer+finde()create()destroy<BusinessObject>Reservation-reserveddate:date-noticedate:date-borrowerid:integer-isbn:string+find()create()destroycopyof现在是79页\一共有171页\编辑于星期四包图《子系统》图书流通《子系统》图书维护《子系统》信息查询图书流通《子系统》交互界面管理所有的与外部通信《子系统》标识图书标识图书并更新信息《子系统》标识借阅标识借阅者并更新信息现在是80页\一共有171页\编辑于星期四对象接口描述接口设计中应该避免涉及接口的具体表示正确的方式是将具体的接口实现方法隐藏起来，只提供对象操作来访问对象和修改数据接口可以用UML中的类图形式来描述UML的格式标记“interface”中必须包含名字部分现在是81页\一共有171页\编辑于星期四图书馆系统中借书者的接口interfaceborrower{ publicvoidborrower(intborrowerid,intbookid); publicvoidsetborrower(intborrowerid); publicvoidaddload(Loadloaditem); publicvoidgetload(); publicvoidgetnoload(); publicvoidremoveload(); publicvoidwrite(); publicvoidread(); …}//borrower现在是82页\一共有171页\编辑于星期四构件级设计构件级设计定义了数据结构、算法、接口特征和分配给每个软件构件的通信机制。每个构件的类定义或者处理叙述都转化为一种详细设计，设计采用图形或基于文本的形式来详细说明内部的数据结构、局部接口细节和处理逻辑。设计符号包括UML图和一些辅助表示。通过一系列结构化编程结构来说明程序的设计。现在是83页\一共有171页\编辑于星期四构件类构件是计算机软件中的一个模块化的构造块在OMGUML规范中将构件定义为“系统中某一定型化的、可配置的和可替换的部件，该部件封装了实现并暴露一系列接口”。面向对象的观点：构件中的每一个类都被详细阐述，包括所有的属性和与其实现相关的操作。从分析模型开始，详细描述分析类（对于构件而言该类与问题域相关）和基础类（对于构件而言该类为问题域提供了支持性服务）。传统观点：模块控制构件，协调问题域中所有其他构件的调用；问题域构件，完成部分或全部用户的需求；基础设施构件，负责完成问题域中所需要相关处理的功能。现在是84页\一共有171页\编辑于星期四构件级设计步骤步骤1：标识出所有与问题域相对应的设计类步骤2：确定所有与基础设施相对应的设计类步骤3：细化所有不能作为复用构件的设计类在类或构件的协作时说明消息的细节为每一个构件确定适当的接口细化属性并且定义相应的数据类型和数据结构详细描述每个操作中的处理流步骤4：说明持久性数据源（数据库和文件）并确定管理数据源所需要的类步骤5：开发并且细化类或构件的行为表示步骤6：细化部署图以提供额外的实现细节步骤7：考虑每一个构件级设计表示，并且时刻考虑其他选择现在是85页\一共有171页\编辑于星期四基于类的构件设计原则开关原则(TheOpen-ClosedPrinciple,OCP)：模块应该对外延具有开放性，对修改具有封闭性。替换原则(SubsitutionPrinciple,SP)：子类可以替换它们的基类。依赖倒置原则(DependencyInversionPrinciple,DIP)：依赖于抽象、而非具体实现接口分离原则(InterfaceSegregationPrinciple,ISP)：多个用户专用接口比一个通用接口要好。发布复用等价性原则（ReleaseReuseEquivalencyPrinciple,REP）：复用的粒度就是发布的粒度。共同封装原则（CommonClosurePrinciple,CCP）： 一同变更的类应该和在一起。共同复用原则（CommonReusePrinciple，CRP）：不能一起复用的类不能被分到一组。现在是86页\一共有171页\编辑于星期四设计模式有经验的软件开发者建立了既有通用原则又有惯用方案的指令系统来指导他们编制软件。如果以结构化形式对这些问题、解决方案和命名进行描述使其系统化，那么这些原则和习惯用法就可以称为模式。基于职责设计对象（GeneralResponsibilityAssignmentSoftwarePatterns,GRASP）信息专家、创建者、控制器、高内聚、低耦合、多态、纯虚构、间接性和防止变异GoF(GangofFour)模式23种设计模式，其中基本的有适配器、工厂、单实例类、策略、组合、外观和观察者等模式现在是87页\一共有171页\编辑于星期四基于职责的设计职责驱动设计也即基于职责的设计。在设计中软件对象具有职责，即对其所作所为进行抽象。UML把职责定义为“类元的契约或义务”。就对象的角色而言，职责与对象的义务和行为相关。职责分为以下两种类型：对象的行为职责包括：自身执行一些行为，如创建对象或计算初始化其他对象中的动作控制和协调其他对象中的活动对象的认知职责包括：对私有封装数据的认知对相关对象的认知对其能够导出或计算的事物得认知职责的粒度会影响职责到类和方法的转换现在是88页\一共有171页\编辑于星期四GRASP职责不同于方法，职责是一种抽象，而方法实现了职责。绘制UML交互图时，就是在决定职责的分配。通过GRASP中的基本原则来指导如果分配职责给一个对象。五种基本的GRASP模式：创建者模式信息专家模式控制器模式低耦合模式高内聚模式现在是89页\一共有171页\编辑于星期四职责与方法现在是90页\一共有171页\编辑于星期四创建者模式问题：一个对象由谁（哪个对象）创建？指导原则是：将创建一个对象A的职责分配给对象B的条件是B“包含”或组成聚集了A、B记录A、B紧密地使用A或者B具有A初始化数据并且在创建A时会将这些数据传递给A。简而言之，就是一个对象要由拥有或者使用其信息的、与其有密切关系的另一个已存在的对象创建。例如在POS机系统中的Sale对象是由那个对象类创建？对于对象Sale由谁创建，分析一下领域模型就会发现，可以认为Register是记录Sale的类。因此Register对象是创建Sale对象的合理选择。现在是91页\一共有171页\编辑于星期四POS机系统中谁创建Sale对象现在是92页\一共有171页\编辑于星期四信息专家模式信息专家（通常称为专家）模式是最基本的职责分配原则之一。创建者是对象的行为职责，而信息专家常常指的是对象的认知职责。指导原则是：给对象分配职责时，应该把职责分配给具有完成该职责所需要信息的那个类。例如在POS机系统中，销售的总额该如果确定？决定总额的一些元素应该是属于哪些对象的信息？按照信息专家的建议，这里应当寻找具有确定总额所需信息的那个对象类。分析领域模型和设计模型得到，要计算总额应该知道销售的所有SalesLineItem实例及其小计之和。Sale实例包含了上述信息。为了确定商品的小计，这里需要SalesLineItem.quantity、和ProductDescription.price。SalesLineItem知道其数量和与其关联的ProductDescription。现在是93页\一共有171页\编辑于星期四计算销售总额现在是94页\一共有171页\编辑于星期四控制器模式根据MVS（ModelViewSeparation）原则，UI对象不应当包含应用逻辑或业务逻辑。应该把UI层的操作或者请求委派给一个协调者，由协调者把任务转发给领域层的领域对象。控制器就是这样一个协调者。例如在POS机系统中，enterItem和endSale这样的系统事件，应使用谁作为控制器？指导原则是：控制器是UI层之上的第一个对象，它负责接收和处理系统操作消息。控制器的选择原则是：代表全部“系统”、“根对象”、运行软件的设备或主要的子系统（如，外观控制器）；代表发生系统操作的用例场景（如，会话控制器）。在用例场景中发生的系统事件通常命名为<UseCaseName>Handler、<UseCaseName>Coordinator或<UseCaseName>Session。对于用同一用例场景的所有系统事件使用相同的控制器类。现在是95页\一共有171页\编辑于星期四控制器类现在是96页\一共有171页\编辑于星期四低耦合模式低耦合模式是一个评价模式。低耦合原则适用于软件开发的很多方面，它是构件软件最重要的目标之一。指导原则是：分配职责以使耦合保持在较低的水平。在真实世界领域中，Register记录了Payment,所以创建者模式建议将Register作为创建Payment的候选者。Register实例会把addPayment消息发送给Sale，并把新的Payment作为参数传递给它。这种职责分配使Register类和Payment类之间产生了耦合，即Register类要知道Payment类。现在是97页\一共有171页\编辑于星期四高耦合问题现在是98页\一共有171页\编辑于星期四低耦合解决方案现在是99页\一共有171页\编辑于星期四高内聚模式高内聚模式是一个评价模式。内聚是软件设计中的一种基本品质，内聚可以非正式地用于度量软件元素操作在功能上的相关程度，也可以用于度量软件元素完成的工作量。指导原则是：分配职责可保持较高的内聚性。现在是100页\一共有171页\编辑于星期四低内聚问题现在是101页\一共有171页\编辑于星期四高内聚解决方案现在是102页\一共有171页\编辑于星期四第13讲面向对象设计方法面向对象详细设计案例分析现在是103页\一共有171页\编辑于星期四面向对象详细设计面向对象详细设计的目的就是不断精化设计类领域模型也称为概念模型、领域对象模型和分析对象模型。领域模型的精化对类图和交互图的精化起了至关重要的作用，也是设计个良好系统的关键。使用泛化、特化、关联类、时间间隔、组合和包等概念精化领域模型。现在是104页\一共有171页\编辑于星期四泛化和特化泛化是在多个概念中识别共性和定义超类（普遍概念）与子类（具体概念）关系的活动。例如在POS机系统中CashPayment,CreditPayment和ChequePayment。在领域中识别父类和子类是一个有价值的活动，这样可以使我们对概念有更概括、精炼和抽象的描述。现在是105页\一共有171页\编辑于星期四POS机系统中Payment现在是106页\一共有171页\编辑于星期四定义概念超类和子类概念超类的定义较子类的定义更为概括或包含范围更广。例如，在POS机系统中，考虑超类Payment和它的子类。将概念类划分为子类的动机有：子类有额外的有意义的属性；子类有额外的有意义的关联；子类概念的操作、处理、反应或使用的方式不同于其超类或其他子类，而这些方式是我们所关注的；子类概念表示了一个活动体，其行为与超类或者其他子类不同，而这些行为是我们所关注的。泛化和定义概念超类的动机：潜在的概念子类表示的是相似概念的不同变体；子类满足100%准则（即概念超类的定义必须100%适用于子类，子类必须100%与超类一致。）；所有子类都具有相同的属性，可以将其解析出来并在超类中表达；所有子类都具有相同的关联，可以将其解析出来并与超类关联。现在是107页\一共有171页\编辑于星期四Payment类层次划分现在是108页\一共有171页\编辑于星期四关联类原则：在领域模型中，如果类A可能同时有多个相同的属性B，则不要将属性B置于A之中。应该将属性B放在另一个类C中，并且将其与类A关联。这样就得出一个关联类C。在POS机系统中，授权服务给每个商店分配一个商业ID，商店发送授权服务的支付授权请求需要商业ID标识商店，商店对于每个服务有不同的商业ID。Store可能有多个merchantID值，所以将merchantID作为Store的属性是不正确的。同理，放入AuthorizationService中也不正确。可以用一个关联类ServiceContract来拥有属性merchantID关联类的增加具有原则：有某个属性与关联相关；关联类的实例具有依赖于关联的生命期；两个概念之间有多对多关联，并且存在与关联自身相关的信息。现在是109页\一共有171页\编辑于星期四关联类现在是110页\一共有171页\编辑于星期四聚合关系和组合关系聚合是UML中的是UML中的一种模糊关联，其不明确的暗示了整体和部分关系。组合也称组成聚合，是一种强的整体—部分聚合关系，并且在某些模型中具有效用。组合关系意味着：在某一时刻，部分的一个实例只属于一个组成实例；部分必须总是属于组成；组成要负责创建和删除部分，可以自己创建和删除部分也可以和其它对象协作进行创建和删除部分；组成被销毁，其部分必须要销毁。组合关系的识别准则是：部分的生命期在组成的生命期之内，部分的创建饿删除依赖于整体；在物理或者逻辑组装上，有明确的整体—部分关系；组成的某些属性会传递给部分；对组成的操作可能传递给部分。现在是111页\一共有171页\编辑于星期四识别和显示组合关系好处：有利于澄清部分对整体的依赖的领域约束；有助于使用GRASP创建者模式识别创建者；对整体的复制、拷贝这些操作经常会传递给部分。在POS机系统中，SalesLineItems可以被视为Sale的组成部分。ProductCatalog是ProductDescriptions的一个组成。现在是112页\一共有171页\编辑于星期四组合关系现在是113页\一共有171页\编辑于星期四时间间隔例如，POS机系统在初始设计时，SalesLineItems与ProductDescriptions关联，记录了销售项的价格。在精化过程中，需要关注与信息、合同等相关的时间间隔问题。如果SalesLineItems从ProductDescriptions取得当前价格，当价格改变时，以前的销售将指向新的价格，这很显然是不正确的。需要区别销售发生时的历史价格和当前价格。基于信息需求，可以采用两种方法对此问题解决：一是可以在ProductDescriptions中保存当前价格，仅将销售发生时的价格写入SalesLineItem；二是将一组ProductPrices与ProductDescriptions关联，每个ProductPrices关联适用的时间间隔。现在是114页\一共有171页\编辑于星期四区别历史价格和当前价格现在是115页\一共有171页\编辑于星期四使用包来组织领域模型将领域模型划分成包结构时，将满足下述条件的元素放在一起：在同一个主题领域，概念或目标密切相关的元素；在同一个类层次结构中的关系；参与同一个用例的元素；有很强的关联性的元素。例如，在POS机系统领域模型中包的结构现在是116页\一共有171页\编辑于星期四POS机系统领域模型现在是117页\一共有171页\编辑于星期四包嵌套现在是118页\一共有171页\编辑于星期四逻辑架构精化在逻辑架构精化设计中主要更细化各层内部元素、层与层之间关系和分层架构中一些模式的应用。遵循模型-视图-控制器（MVC）三层模型。在精化逻辑模型时首先要进一步指出个系统层之间、包之间的关系。可以用依赖线来表达包或者包内类型之间的耦合。依赖线可以由一个包发出例如在POS机系统中从Sale包指向POSRuleEngineFacade类，从Domain包指向Log4J包。现在是119页\一共有171页\编辑于星期四现在是120页\一共有171页\编辑于星期四简单包和子系统现在是121页\一共有171页\编辑于星期四外观和控制器现在是122页\一共有171页\编辑于星期四模型-视图分离和“向上”通信现在是123页\一共有171页\编辑于星期四包设计准则包在水平和垂直划分上的功能性内聚由一族接口组成的包正式包和聚集不稳定类的包职责越多的包越需要稳定将不相关的类型分离出去使用工厂模式减少对具体包的依赖现在是124页\一共有171页\编辑于星期四分离不相关的类型现在是125页\一共有171页\编辑于星期四具体包的依赖现在是126页\一共有171页\编辑于星期四工厂模式减少对具体包的依赖现在是127页\一共有171页\编辑于星期四精化的交互图在交互图中，领域模型指出了需要设计的软件对象，设计模型中的设计类是以领域模型的类为基础的。在顺序图和协作图精化设计中，一些类直接来自前面的分析模型中的类，还有一些针对软件系统的更好的实现虚构出来的。例如设计makeNewSale操作。要处理一次新的销售，首先必须创建软件对象Sale。根据控制器模式我们还需要设计一个转发makeNewSale请求的对象Register。Register是记录Sale的类。又根据创建者模式得出应该由Register创建Sale。在销售过程中必须设计一个集合来存储一系列的商品，所有由Sale对象创建了记录所有将来会添加的集合SalesLineItem实例。现在是128页\一共有171页\编辑于星期四精化设计类现在是129页\一共有171页\编辑于星期四输入商品现在是130页\一共有171页\编辑于星期四结束销售现在是131页\一共有171页\编辑于星期四获取总价现在是132页\一共有171页\编辑于星期四处理支付现在是133页\一共有171页\编辑于星期四计算找零现在是134页\一共有171页\编辑于星期四精化的类图类图和对象图是设计阶段的主要制品顺序图和协作图中的消息映射为类图中的方法，交互消息的对象映射为类的对象，每个消息的交互实现映射为类图和对象图中方法的实现。在类图的精化设计中不仅要得到每个类中的属性和方法，还要有方法的粗略实现（也即方法的实现过程）现在是135页\一共有171页\编辑于星期四可见性的设计可见性的设计主要有四种：属性可见性参数可见性局部可见性全局可见性classRegister{

…… privateProductCalatogcatalog; publicvoidenterItem(itemID,qty){

…… desc=catalog.getProductDesc(itemID);

…… }

……}现在是136页\一共有171页\编辑于星期四类图的细化类图的设计是以交互图的设计为基础的，类图中的元素也是从交互图中抽象提取出来的。通过交互图中对象之间的交互，找出对象所属的类以及类之间的关系。通过对交互图中对象之间消息的交互的分析和细化得到类图中的属性和方法。对类图进行分析的时候也必须理解类图和类之间的关系如何映射得到具体的实现类。现在是137页\一共有171页\编辑于星期四输入商品条目的类图现在是138页\一共有171页\编辑于星期四细化的类图现在是139页\一共有171页\编辑于星期四实现publicclassRegister{ privateProductCatalogcatalog；

privateSalecurrentSale；

publicRegister（ProductCatalogpc）{…} publicvoidendSale（）{…} publicvoidenterItem（ItemIDid，intqty）{…} publicvoidmakeNewSale（）{…} publicvoidmakePayment（MoneycashTendered）{…} }现在是140页\一共有171页\编辑于星期四持久性设计持久性设计的目的就是让对象能够方便、快捷的持久化存储。所以在系统中要持久存储的对象也叫做持久性对象。例如：在POS系统中的SaleLineItem对象、ProductDescription对象。在运用关系型数据库来存储对象信息时需要第三方或者系统拥有的持久性服务。通过这种持久性服务来解决面向对象和面向记录的数据之间的失配问题。用对象数据库来存储对象时就不需要设计持久性服务。但对象数据库应用比较少。在设计持久性服务时不仅仅对于存储在关系型数据库中，还设计其他的存储机制，如普通的文件形式、XML结构、层次数据库等等。现在是141页\一共有171页\编辑于星期四持久化设计的基本原理持久性服务又称为O-R（对象-关系）映射服务。持久性服务主要完成两件事：一是在存储数据时，把对象转换为记录（或其他数据格式如XML），并将其存储到数据库中；二是在读取数据时，从数据库中读出记录型数据（或其他格式数据），并将其转换成对象。概念：映射：在类和持久性存储（如数据库中的表）之间，对象的属性和记录的域（属性列）之间必须存在着一定的映射关系。对象标识：为了方便将记录与对象联系起来并确保没有重复，所以对象和记录都必须有唯一的对象标识。具体化和虚化：具体化是指将以某些格式存储的非对象数据（如数据库中的记录，XML中的数据）转换为对象型数据。虚化是指将需要持久化的对象数据转换为非对象形式的数据（如记录）进行存储。数据库映射器：主要负责具体化和虚化的纯虚构映射器。现在是142页\一共有171页\编辑于星期四类ProductDescription表示为表PRODUCTDESCRIPTION表现在是143页\一共有171页\编辑于星期四对象标识符记录和对象的相互映射都通过对象标识符（OID）来实现。OID的值通常由字母和数字组成，每个对象具有惟一的OID。有各种方法可以生成惟一的OID，包括对于一个数据库的惟一OID乃至全局性的惟一OID。这些方法包括：数据库序列生成器High-Low键生成策略等。在对象领域，OID由封装实际值及其表示的OID接口或类来表示；在关系数据库中，OID通常被存储为固定长度的字符串值。每个表都有一个OID作为主键，每个对象也（直接或间接的有一个OID）。现在是144页\一共有171页\编辑于星期四通过OID来映射对象和记录现在是145页\一共有171页\编辑于星期四持久性框架的设计持久性框架是一组通用的、可复用的、可扩展的类型，它提供支持持久性对象的功能，即提供持久性服务。在持久化设计中，可以通过外观来访问持久化服务。根据指定的OID提取对象的操作，当然子系统还必须知道具体化对象的类型，所以在这里要提供具体化后类的类型。例如，在POS机系统中使用外观访问持久服务。持久化设计两种具体化和虚化对象的方式：直接映射：持久性对象类本身定义了自己存储到数据库中的代码。但是这种方式使类的耦合性增加了，同时对象类的内聚性也降低。间接映射：使用了数据库代理模式，即创建一个类来负责对象的具体化和虚化。现在是146页\一共有171页\编辑于星期四持久化外观现在是147页\一共有171页\编辑于星期四数据库映射器现在是148页\一共有171页\编辑于星期四使用模板设计持久性框架使用模板设计持久性框架的思想是，在超类中定义一种方法，这种方法叫模板方法。超类中定义了算法的框架，其中既有固定的部分也有可变的部分。通过模板方法调用其他一些方法，这些方法中有些可能会被子类覆盖。子类覆盖这些变化的方法，增加自己特有的行为。现在是149页\一共有171页\编辑于星期四使用模板现在是150页\一共有171页\编辑于星期四部署与构件图部署图表示的是如何将具体软件制品（例如可执行文件）分配到计算节点（具有处理服务的某种事物）上。部署图表示了软件元素在物理架构上的部署，以及物理元素之间的通信。部署图有助于沟通物理或者部署架构。部署图中最基本的元素是节点，有两种类型的节点：设备节点：具有处理和存储能力，可执行软件的物理计算资源，例如典型的计算机或者移动电话。执行环境节点：在外部节点中运行的软件计算资源，其自身可以容纳和执行其他可执行软件元素。现在是151页\一共有171页\编辑于星期四构件图构件是系统中用来描述客观事物的一个实体，它是构成系统的、支持即插即用的基本组成单位，一个构件由一个或多个对象经过包装构成，通过