【文档说明】软件设计与体系结构-齐治昌课件.ppt，共(667)页，11.485 MB，由小橙橙上传

转载请保留链接：https://www.ichengzhen.cn/view-45354.html

以下为本文档部分文字说明：

软件设计与体系结构主讲教师：1第1章软件工程与软件设计◼1.1软件工程◼1.2软件生存周期◼1.3软件开发过程模型◼1.4软件设计◼1.5软件体系结构◼1.6小结第1章软件工程与软件设计◼以计算机为核心的信息社会◼软件是信息化的灵魂◼以工程化方法和思想开发软件◼软件设计是软件开发过程中的

核心活动之一1.1软件工程◼软件危机：在计算机软件的开发和维护过程中所遇到的一系列严重问题◼软件设计：计算机软件发展到一定阶段，为了应对软件危机◼计算机软件=程序+数据+文档◼计算机软件是逻辑和智力产品，不是物理产品1.1软件工程◼软件的应用领域和分类系统软件实时软件嵌入式软

件科学和工程计算软件事物务理软件人工智能软件个人计算机软件1.1软件工程◼软件危机软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。即包含两方面的问题：(1)如何开发软件(2)如何维护软件◼软件危机

的原因软件产品生产效率较低软件供需失衡用户需求不明确整个软件开发过程缺乏正确的理论指导软件产品的规模越来越大软件产品开发的复杂度越来越高1.1软件工程◼软件工程软件工程是指导计算机软件开发和维护的工程学科；

将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究；是用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术和管理方法；◼软件工程要素：方法、工具、过程方法：为软件开发提供了“如何做”的技术，是完成软件工程项目的技术

手段工具：人类在开发软件的活动中智力和体力的扩展和延伸，为软件工程方法提供自动或半自动的软件支持环境过程：将方法和工具综合起来以达到合理、及时地进行软件开发的目的1.1软件工程◼软件工程的目标和原则在给定成本、进度的前提下，开发出具有可修改性、有效性、可靠性、可理解性、可

维护性、可复用性、可适应性、可移植性、可跟踪性并满足用户需求的软件产品。抽象、信息隐藏、模块化、局部化、一致性、完全性、可验证性◼目标可修改性有效性可靠性可理解性可维护性可复用性可适应性可移植性可追踪性•基本目标：✓付出较低的开发成本✓达到要求的软件

功能✓取得较好的软件性能✓开发的软件易于移植✓需要较低的维护费用✓能按时完成开发工作✓及时交付使用软件工程的目标是提高软件的质量与生产率，最终实现软件的工业化生产。软件工程的原则◼抽象采用分层次抽象，自顶向下、逐层细化的办法控制软件开发过程的复杂性◼信息隐蔽将

模块设计成“黑箱”，实现的细节隐藏在模块内部，不让模块的使用者直接访问。这就是信息封装，使用与实现分离的原则◼模块化如C语言程序中的函数过程，C++语言程序中的类。模块化有助于信息隐蔽和抽象，有助于表示复杂的系统

。软件工程的原则◼局部化要求在一个物理模块内集中逻辑上相互关联的计算机资源，保证模块之间具有松散的耦合，模块内部具有较强的内聚。这有助于控制解的复杂性◼确定性软件开发过程中所有概念的表达应是确定的、无歧义性的、规范的。◼一致性整个软件系统的各个模块应使用一致的概念、符号

和术语。程序内部接口应保持一致。软件和硬件、操作系统的接口应保持一致。系统规格说明与系统行为应保持一致。用于形式化规格说明的公理系统应保持一致软件工程的原则◼完全性软件系统不丢失任何重要成分，可以完全实现系统所要求功能的程度。为了保证系统的完备性，在软件开发和运行过程中需要严格的技术评审。◼

可验证性开发大型的软件系统需要对系统自顶向下、逐层分解。系统分解应遵循系统易于检查、测试、评审的原则，以确保系统的正确性。软件工程的原则复杂问题子问题1子问题2子问题n程序1程序2程序n软件系统解决原始问题集成分解1.2软件生存周期◼So

ftwarelifecycle◼软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程称为软件生存周期◼软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存周期◼软件定义-软件开发-软件使用和维护软件定义(系统分析)：可行

性研究(软件计划)、需求分析软件开发(系统设计)：概要设计、详细设计、软件实现(编码、单元测试)、软件测试(组装测试、确认测试)软件使用、维护退役软件生存周期◼可行性研究确定要开发软件系统的总目标给出功能、性能、可靠性以及接口等方面的

要求完成该软件任务的可行性研究估计可利用的资源、成本、效益、开发进度制定出完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查◼需求分析对用户提出的要求进行分析并给出详细的定义编写软件需求说明书或系统功能说明书及初步的系统用户

手册提交管理机构评审软件生存周期◼概要设计—把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应，编写设计说明书，评审◼详细设计—对每个模块要完成的工作进行具体的描述，为源程序编写打下基础，编写设计说明书，提

交评审◼软件构造把软件设计转换成计算机可以接受的程序代码，即以某一种特定程序设计语言表示的“源程序清单”；程序应当是结构良好、清晰易读的，且与设计相一致的。软件生存周期◼软件测试单元测试，查找各模块在功能和结构上存在的问题并加以纠正集成测试，将已测试过的模块按一定顺

序组装测试确认测试，按规定的各项需求，逐项进行有效性确认测试，决定已开发的软件是否合格，能否交付用户使用◼使用与维护：在用户特定的环境中，在测试通过后移交用户使用改正性维护：运行中发现软件中的错误需要

修正适应性维护：为了适应变化了的软件工作环境，需做适当变更完善性维护：为了增强软件的功能需做变更1.3软件开发过程模型◼软件开发过程模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架瀑布模型原型模型

螺旋模型统一软件开发过程瀑布模型（生存周期模型）◼W.W.Royce1970提出◼瀑布模型，是既自顶向下结构化开发模型◼优点：奠定了软件工程方法的基础；流水依赖；便于分工协作；推迟现实；文档易修改；有复审质量保证。◼缺点：用户需

求明确困难；用户见面晚；纠错慢；难于克服系统分析员不懂专业领域的知识，用户不懂计算机的困难，成功率低。适合于系统要求明确的小系统。带反馈的瀑布模型快速原型模型◼rapidprototypemodel◼根据用户提出的软件定义，快速的开发一个原型，在征求用户对原型意见的过程中，再

进一步修改、完善，直至达成一致。模拟软件的人机界面开发一个原型，实现部分功能向用户展示正在运行的类似软件◼优点：与用户见面快；开发成功率高，适合于需求不确定的大系统。◼缺点：周期长，开发成本高。快速原型模型螺旋模型◼螺旋模型沿着螺线

旋转（一个螺旋式周期），在四个象限上分别表达四个方面的活动，即：◼制定计划──确定软件目标，选定实施方案，弄清项目开发的限制，选定完成目标的策略◼风险分析──分析所选方案，考虑如何识别和消除风险，风险角度分析该策略◼实施工程──实施软件

开发，启动一个开发阶段◼客户评估──评价前一步开发工作，提出修正建议，计划下一轮的工作◼特点瀑布模型+快速原型+风险分析迭代过程统一软件开发过程◼统一软件开发过程(RUP,RationalUnifiedProcess)是一套软件工程过程，是一套软件工程方

法的框架，各个组织可根据自身的实际情况，以及项目规模对RUP进行裁剪和修改，以制定出合乎需要的软件工程过程。◼适合与统一建模语言(UML,UnifiedModelLanguage）结合起来使用◼支持六大最佳软件开发实践迭代式开发管理需求基于

构建的软件体系结构可视化建模验证软件质量控制变更统一软件开发过程统一软件开发过程◼横轴：时间轴，表示软件开发的顺序开启阶段精化阶段构建阶段产品化阶段◼纵轴：“谁”在“何时”、“如何”去做“何事”9个工作流程

各个阶段实施的工作流程，在不同的时间段内工作流所占工作量不同1.4软件设计◼对软件如何被开发出来的一种规范化描述软件需求分析和软件设计受到重视编码所占比例越来越少◼软件设计的重要性对软件需求的直接体现为软件实现提供直接依据考虑软件系统的各种约束条件并给出相应方案决定最终软件系统的质

量及早发现软件设计中存在的错误减少软件修复和维护的成本1.4软件设计◼软件设计的特征出现新的问题需要软件来解决、解决问题和实施决策的过程、一系列转换过程、满足各种约束的过程过程、不断演化的过程、给出一个方案、新思路、新想法◼软件设计的要素目标描述、设计约束、产品描述、

设计原理、开发规划、使用描述1.5软件体系结构◼软件设计是从软件需求到软件实现的活动，它把各种软件需求转换为能直接实现的软件结构◼软件需求与软件设计之间存在难以逾越的鸿沟，如何有效的将软件需求软化为相应的设计？◼软件需求——？——软件设计——软件实现

—软件体系结构1.5软件体系结构◼软件体系结构的定义软件体系结构是软件系统的结构，包含软件元素、软件元素外部可见的属性以及这些软件元素之间的关系；软件体系结构是软件系统的基本组织、包含构件、构件之间、构件与环境之间的关系，以及相

关的设计与演化原则；软件体系结构是程序或系统中组件的结构、组件之间的相互关系、设计的基本原则以及随时间进化的指导方针；1.5软件体系结构软件体系结构的发展历程“无体系结构”设计阶段萌芽阶段以汇编语言进行小规模应用程序开发为特征以描述系统的高层抽象结构为

中心，不关心具体的建模细节，划分了体系结构模型与传统软件结构的界限，该阶段以Kruchten提出的“4+1”模型为标志出现了从不同侧面描述系统的结构模型，以UML为典型代表。出现了程序结构设计主题，以控制流图和数据流图构成软件结构为特征高级阶段初期

阶段1.5软件体系结构◼软件体系结构的内容软件体系结构的描述：软件体系结构描述语言软件体系结构的设计方法软件体系结构的分析方法软件体系结构的复用本章完第二章：统一建模语言UML内容2.1UML概述2

.2面向对象开发方法2.3UML2.0结构建模2.4UML2.0行为建模（1）UML的发展历程◼多种面向对象分析与设计方法的存在不利于面向对象方法的发展，也给用户的选择带来一些困惑。◼1994年Booch和Rumbaugh首先将

各自先前的研究成果统一起来，于1995年10月发布了UM0.8。◼经过Booch、Rumbaugh和Jacobson三人的共同努力，于1996年发布UML0.9，并从此将UM命名为UML。◼UML结束了“模型论战”，

融合了众多优秀的面向对象建模方法以及软件工程方法，消除了因建模方法相互独立带来的诸多不便。UML2.0◼1997年对象管理组织（ObjectManagementGroup，OMG）采纳UML作为其标准建模语言，并通过严格有序的OMG过程对其进行修订和维护。◼1999，UML1.3，相对稳定成

熟阶段◼2001-05，UML1.4◼2003年6月宣告完成了UML2.0：Infrastructure（底层结构）Superstructure（上层结构）OCL（对象约束语言）DiagramI

nterchange（图形交换）UML2.0◼UML2.0另一个显著特征就是加强了对模型驱动体系（ModelDrivenArchitecture，MDA）的支持。◼MDA的目标是要实现从UML模型到最终代码的自动化生成。◼UML已经迅速成为软件设计语言的事实标准。◼本章介绍UML2.

0上层结构中规定的各种模型的语法和用途。（2）UML的特点和用途◼为使用者提供了统一的、表达能力强大的可视化建模语言，以描述应用问题的需求模型、设计模型和实现模型。◼提供对核心概念的扩展机制，用户可加入核心概念

中没有的概念和符号，可为特定应用领域提出具体的概念、符号表示和约束。◼独立于实现语言和方法学，但支持所有的方法学，覆盖了面向对象分析和设计的相关概念和方法学。◼独立于任何开发过程，但支持软件开发全过程。◼提供对建模语言进行理解的形式化基础，用元

模型描述基本语义，OCL描述良定义规则，自然语言描述动态语义。◼增强面向对象工具之间的互操作性，便于不同系统间的集成。◼支持较高抽象层次开发所需的各种概念，如协同、框架、模式和构件等，便于系统的重用。（3）UML2.0建模机制◼13种视图模型，分为结构视图和行为视图◼结构视图

：描述系统中各种元素之间的组织结构关系◼行为视图：描述系统中有关元素的行为过程（3）UML2.0的建模机制◼结构建模：类图包图对象图构件图组合结构图部署图◼行为建模：➢活动图➢顺序图➢通信图➢交互概览图➢时序图➢状态图➢用例图UML2.0的建模机制UML2.0

建模机制结构建模(Structure)行为建模(Behavior)类图(ClassDiagram)包图(PackageDiagram)对象图(ObjectDiagram)组合结构图(CompositeStru

ctureDiagram)部署图(DeploymentDiagram)构件图(ComponentDiagram)交互图(InteractionDiagram)状态图(StateMachineDiagram)活动图(ActivityDiagram)顺序图

(SequenceDiagram)时序图(TimingDiagram)交互概览图(InteractionOverviewDiagram)通信图(CommunicationDiagram)用例图(UseCaseDiagram)内容2.1UML概述2.2面向对象开发方法2.3UML2.0结构建

模2.4UML2.0行为建模面向对象方法◼面向对象开发方法通过提供对象、对象间消息传递等语言机制让软件开发人员在解空间中直接模拟问题空间中的对象及其行为。◼削减了语义断层，拉近了问题空间与解空间的距离，简化了软件工程师为问题寻找解的

工作，并为软件开发活动提供了直观、自然的语言支持和方法学指导。面向对象的基本概念基本概念面向对象=对象+类+继承+聚集+多态+消息◼对象:现实世界中个体或事物的抽象表示，是其属性和相关操作的封装。◼类:某些对象的共同特征（属性和操作）的表示。对象是类的实例，类是创建

对象的模板。◼继承◼聚集:部分—整体关系◼多态:父类及其子类中，对外接口的定义形式相同，却可以对应多种接口的实现形态（重写、重载）。◼消息:对象和对象之间是通过传递消息来完成相互通信，对象与外部世界相互关联的唯一

途径。（2）面向对象方法的优势◼简化软件开发过程◼支持软件复用◼改善软件结构内容2.1UML概述2.2面向对象开发方法2.3UML2.0结构建模2.4UML2.0行为建模结构建模◼结构建模也称为静态建模，主要用来描述

系统中包含的元素以及元素之间的关系。◼结构建模中的视图可以对各个层次和阶段的软件进行刻画，例如软件设计、软件实现、系统部署等。这些模型对系统的逻辑结构或物理结构进行描述，并不涉及系统的动态行为和过程。◼UML2.0中的结构建模包括类图、包图、对象图

、构件图、组合结构图和部署图。结构建模◼本节结构建模视图模型如下：◼包图包、依赖关系、导入关系、合并关系◼对象图◼构件图构件、接口、装配连接子、委托连接子◼组合结构图◼部署图（1）类图◼类图是UML中最基本、也是最重要的一种视图，它用

来刻画软件中类等元素的静态结构和关系。◼类图的图元：类、抽象类、接口、依赖关系、关联关系、聚集关系、构成关系、泛化（继承）关系、实现关系、关联类类描述具有相同特征、约束和语言的一类对象，这些对象具有共同的属性和操作。

Customer+Buy():void+Pay():void+name:string#address:stringCustomer类名属性：类型操作+:Visiblea：详细设计的类b：简单表示的类：仅给出类名抽象类◼一个类只提供操作名，而不对其进行实现，对这些操作的实现可以由其

子类进行，并且不同的子类可以对同一操作进行不同的实现。◼不能被实例化的类，一般至少包含一个抽象操作+Buy():void+Pay():voidCustomer类名，斜体字符表示抽象类接口◼声明一些属性或方法，但并不实现它们。用来规定一种契约，对接口进行实现的元素

（类）必须遵循该契约。构造型和圆圈两种表示。构造型表示的接口接口名标识元素类型与接口相连的是对接口进行实现的类依赖关系◼两个类之间存在依赖关系，表明一个类使用或需要知道另一个类中包含的信息，用虚线箭头表示Cu

stomerProductCatalog关联关系◼两个类之间存在关联关系，表明这两个类的实例之间存在语义上的联系。关联可以具有方向性(有单方向关联，双方向关联)。◼PersonCompany+Employee*+Employer1多重

性意义11个并且只有一个0。。*或者*0到无限1。。*1到无限2。。42到4的范围2，42或者4聚集关系◼聚集关系是一种特殊的关联，表示两个类的实例之间存在一种拥有或属于关系，是较弱的“整体—部分”关系，或是逻辑上的“隶属”关系。◼整体（上级）类一侧有一个空心菱形的图。P

ersonCompany*1构成关系◼构成关系表明两个类的实体间存在一种包含关系，是比聚聚关系更强的“整体—部分”关系，部分对象在任何时候都只能属于一个整体对象，整体对象被破坏则部分对象也被破坏。用实心菱形表示，菱形在整体一侧。OrderItemOrder1*泛化（继

承）关系PersonManagerEngineerSalesman实现关系◼实现关系表示一个元素是对另一个元素的实现+QueueSort():bool+SetSort():bool<<接口>>Sort+QueueS

ort():bool+SetSort():boolSortImplementation关联类◼关联类用来记录与关联（关系）有关的信息，提供与关联有关的操作。PersonCompany+Employee*+Employer1+ContractEmployment（2）包图◼包图在UML中可

以看作是类图的一部分。◼包用来对一组元素进行划分，是对复杂模型的一种分而治之的层次划分。◼常用来描述一个复杂系统逻辑上的子系统划分。◼包图主要由包和包之间的关系组成。◼包的划分应遵循高内聚、低耦合的原则，一个包中可以包含多个类和子包。◼包图的

图元：包、依赖关系、导入关系、合并关系包ScrollBarListWindowsTextBox1SystemInterface依赖关系◼如果包中的元素之间存在依赖关系，则包存在依赖关系。◼OrderManager包中的类依赖于SystemInt

erface包中的某个类导入关系◼当一个包（CustomerManager）中的元素访问另一个包（OrderManager）中的元素时，需要给出被访问元素的完整名称，如OrderManager::Order。如果把OrderManager包中的元素导入到CustomerManage

r中，则可以使用直接访问Order类。◼《import》导入。◼《acess》导入：被导入元素的可见性是private，不可以被其他包使用。导入关系OrderManagerCustomerManager<<import>>DataManager<<access>>导入关系P1Public:C1

<<acess>>P2Public:C3P3C4P4C2<<import>><<import>><<acess>>导入前：P1::C1P1::C2P2::C3导入后：C1C2private：C3导入前：P3::

C4导入后：C1C2（不可访问）C3（不可访问）C4合并关系◼把一个包中的内容合并到另一个包中，合并后的包拥有两个包中的内容，可见性为private的元素不被合并，具有相同名字的元素通过泛化关系连接起来。OrderManagerDataMan

ager<<merge>>（3）对象图◼对象图是看作类图的实例，对象之间的连接是类之间关联关系的实例。◼对象名：所属的类；可以出现一个类的多个实例。10..*+Name:stringCustomer+No:long+Date:stringOrderName:string=张三张三:Cus

tomerNo:long=2042343Date:string=21/04/2008订单2042343:OrderNo:long=2087230Date:string=05/08/2008订单2087230:Order（4）构件图◼基于构件的软件开发日益受到重视，UML2.0对构件图进行

较大的改进。◼构件的根本特征在于它的封装性和可复用性，其内部结构被隐藏起来，只通过接口向外部提供服务或请求外部的服务。◼通过明确构件对运行环境的假设（即接口定义），可以将构件封装起来，尽可能的独立，从而为复用提供支持。◼构

件图用来描述系统中存在的构件、构件具有的接口、以及各个构件怎样通过接口连接起来形成一个完整的系统。（4）构件图◼构件图的图元：构件、接口、装配连接子、委托连接子◼构件是系统中具有良好封装、可替换的模块◼简单构件

构件的表示符号：◼复杂构件内部有实现细节，可以是构件或者是类（4）构件的依赖关系◼一个构件需要用到另一个构件的信息<<component>>Order<<component>>Account<<component>>ProductOrderIi

neOrderHeader1接口◼一个构件与其他构件之间通过具有规范定义的接口进行交互，这使得一个构件可以被另一个具有相同接口定义的构件替换（换灯泡）。◼需求接口（RequiredInterface）◼提供接口（ProvidedInterf

ace）<<component>>OrderPersonOrderableOrderState装配连接子◼把一个构件的服务和另一构件的需求连接起来<<component>>OrderPersonOrderable<<component>>Cu

stomerPerson<<component>>ProductOrderable委托连接子◼复杂构件包括多个子构件，复杂构件的需求和提供接口的功能应由其某个子构件完成。◼把复杂构件的外部接口与内部子构件的接口映射起来

，由端口（port）和委托连接子（delegate）描述。◼端口由一个小方框表示，一个端口可以对应多个接口，方向是从需求方指向提供服务方。委托连接子<<component>>Store<<component>>Orde

rPersonOrderable<<component>>CustomerPerson<<component>>ProductOrderableOrderStateOrderStateAccountAccount<<delegate>><<delegate>>需求接口委托给Customer子构件

的Account需求接口提供接口委托给Order子构件的OrderState提供接口（5）组合结构图◼为了描述复杂系统在运行时的结构，组合结构图通过内部结构、端口、协作等概念，描述系统、对象、协作实例等元素之间的结构关系。◼组合结构图中可以使用类图、对象图、构件图中的有关图元，也可以有

自己独特的建模元素。组合结构图中的端口StoreOrderStateAccountp[2]q端口q是一个行为端口，与一状态连接，状态用来解释端口运行时的行为端口p在运行中有两个实例组合结构◼组合结构图可用来描述系统及其组成部分，组成部分的描述类

似于对象图中的对象，但组合结构图可以说明该部分属于哪个系统。StoreMainWindow:WindowOkButton:ButtonCancelButton:Button协作◼组合结构图能够描述表示系统功能行为的协作（Collaboration）及其内部的实现结构，并且协作可以实例化，Selle

r:PersonBuyer:PersonSale（6）部署图◼部署图用来描述软件开发过程中生成的物理文件形式的软件或信息、运行平台中的物理节点和通信，以及软件文件到相应硬件节点的部署或映射。◼制品：物理文件形式的软件或信息，如：源代码文件、文档、模型文件等。◼节点：运行平台中的硬件

，节点间通过通信路径进行消息传递。◼描述制品怎样在节点上部署以及节点之间如何连接（6）部署图◼AppServer<<Artifact>>ShoppingCart.jar<<Artifact>>Order.jarWebServerDatabaseSer

ver1DatabaseServer2-MiniProcessors=2-MiniSpeed=2.4GHz-Storage=1TB-Storage=2TB<<JDBC>><<JDBC>><<RMI>>内容2.1UML概述2.

2面向对象开发方法2.3UML2.0结构建模2.4UML2.0行为建模行为建模◼行为建模也常被称为动态建模，它主要用来刻画系统中的动态行为、过程和步骤。◼UML行为建模中提供的视图可以从不同侧面来描述软件系统的动态过程。◼结构建模对系统中的元素及

其关系进行描述，而行为建模对这些元素完成特定任务的过程进行描述，两者相互结合就能够完整地描述整个系统的特征。（1）活动图◼活动图主要描述一个系统行为的执行过程或步骤，它的适用范围非常广泛，能够用来描述工作流、过程流、算法步骤等从问题域到解空间的任何能够用流的形式描述的行为，可以用于概念层、设计层

、实现层等不同抽象层次的系统行为建模。活动和动作◼活动是包含一组动作的行为，动作是活动中的一个步骤。◼初始/终止节点、初始/动作、动作SaleProcessPurchasedItem:ProductSubmitOrder

PaymentShipItemAddItemToShoppingCart对象节点◼为了增强对活动的表达能力，活动图还有一些特殊的节点，以表示活动的输入、输出，以及动作之间传递的复杂对象。◼示例：两个动作之间传递Order对象SubmitOrderAddItem

ToShoppingCartOrderSubmitOrderAddItemToShoppingCartOrderOrder控制节点◼在实际的活动流程中，会经常出现分支选择情况。还有可能执行完一个动作后，下

面需要同时开始执行几个流程，或几个流程完成后汇总为一个流程。◼分支节点，可标明分支条件◼分叉节点◼汇合节点控制节点泳道◼为了能够把动作按照执行该动作的对象进行划分，以明确活动中各个参与者的相应职责，活动图引入了泳道的概念。◼泳道可以是水平

的，也可以是垂直的，或者二者同时存在。泳道交互图◼顺序图◼通信图◼交互概览图◼时序图（2）顺序图◼顺序图用来描述对象之间动态的交互关系，主要强调完成某个场景的对象之间存在哪些消息传递以及消息的时间序。◼顺序图的水平轴表示交互的不同对象，垂直虚线表示对象的生命线。◼对象间的通信表示为对象生命线之间

的消息传递，消息有简单消息、同步消息、异步消息等类型。消息有消息名，还可以有参数标识，可以用条件表达式表示消息发送的条件。◼[发送条件]消息标号：消息名（消息参数）简单顺序图:UserWindow:Log

inManager:DatabaseManager1:CheckUser(UserName,Password)2:GetPassword(UserName)3:Set(Result)4:IfPass=Check(Result)[IfPass=true]5:Show(Passed)[

IfPass=fase]5:Retry()sdLogin顺序图—交互操作◼对象的交互是一个很复杂的过程，使用交互片段（InteractionFragment）和片段组合（CombinedFragment）对复杂交互进行建模。◼多个交互片段通过交互操作（InteractionOperat

or）组合成为一个复杂的交互图。◼片段组合：交互操作（1..*交互片段）=复杂交互图交互操作：ref,alt,opt,par,loop,critical,neg,assert,strict,seq,ignore,

consider,break图2-31（3）通信图◼关注参与交互的对象通过连接组成的结构，消息和方向附属于对象间的连接，并通过编号表示消息的顺序。（3）通信图:UserWindow:LoginManager:DatabaseManagersdLogin1:CheckUser(UserN

ame,Password)[IfPass=true]5:Show(Passed)[IfPass=fase]5:Retry()2:GetPassword(UserName)3:Set(Result)4:IfPass=Check(Result)（4）交互概览图◼交互概览

图(interactionoverviewdiagram)是把顺序图和活动结合起来描述交互流程和交互细节的一种交互图。◼交互概览图通过类似于活动图的方式，描述交互之间的流程，给出交互控制流的概览。◼在交互概览图中，节点不像活动图中那样是动作，而是一个交互图或对交互图的引用。◼图2-33

（4）交互概览图（5）时序图◼时序图用来表示交互中关于消息时间的描述，并描述对象在生命线中，其所处状态或条件随着消息发生的变化。每个事件可给出时间约束。sdOrderManagement:OrderMan

agerReadyUpdatingSubmittingLoginIdleUpdateSubmitOkLogout0123t{t..t+3}时序图的紧凑形式sdOrderManagement:OrderManagerReadyUpdatingSubmittingIdleIdle{t..t+3}（6）

状态图◼状态图使用有穷状态变迁图的方式刻画系统或元素的离散行为，可以用来描述一个类的实例、子系统甚至整个系统的在其生命周期内，所处状态如何随着外部激励而发生变化。◼在UML2.0中，状态图又分为行为状态机和协议状态机，前者描述一个建模元素的行为（例如对象），而后者描述一个协议的行为。状态与迁

移◼状态指所描述的元素在其生命周期中可位于一种相对稳定的位置，状态一般会（隐含）满足一组条件。◼状态的表示：状态名，状态中发生的动作/动作的类型，◼状态之间存在迁移，即从一个状态变化为另一个状态。迁移条件：事件[条件]/

动作StateNameentry/op1do/op2exit/op3StateNametrigger[guard]/effect状态图UpdatingWaitingDispatchingCancelledDel

ivereddo/CheckItemCheckingCreateOrderSubmitOrder[someitemsnotinstock]/StockPrepare[allitemsavailable][allit

emsavailable]CancelOrderCancelOrderCancelOrderOrder状态图—复合状态◼一个状态还可以再细分为若干个子状态。◼复合状态可以用来对状态进行层次划分，使得状态图具有

良好的结构，并且易于理解。◼复合状态也有自己的初始状态和终止状态。状态图—复合状态（1）状态图—复合状态（2）◼把内部分成几个正交的区域，每个区域内都有一个状态图，几个区域之间是并行执行的，适用于描述具有并发状态的对象。UpdatingWaiting

DispatchingCancelledDelivereddo/CheckItemCheckingCreateOrderSubmitOrder[someitemsnotinstock]/StockPrepare[allit

emsavailable][allitemsavailable]CancelOrderOrderOrderProcessingAuthorizingAuthorizedPaymentReject伪状态◼伪状态是一些特殊的

状态：初始状态和终止状态选择（Choice）入口点（Entry）出口点（Exit）分岔（Fork）汇合（Join）深度历史（DeepHistory）浅度历史（ShallowHistory）……（7）用例图◼用

例图通常被用来描述系统的需求，从用户的角度对系统的功能视点进行建模。◼一个用例表示系统的一个特定功能，是用户与系统之间一次典型交互，能引发系统执行一系列动作，并且动作执行的结果能被用户（或外部实体）觉察到。◼用例图刻画了系统包含哪些用例、用例

之间、用例与外部角色之间的关系。用例和参与者◼一个用例代表系统执行的一组动作，这些动作完成特定的任务，并产生对用户或外部实体可观察的结果。◼用例用来描述系统对外可见的需求或功能。◼参与者是与用例发生交互的系统外部角色，必须是被开发的系统范围之外的角色（不必在本开发系统中实现）

，它们只与系统发生某种形式的交互。用例图ModifyOrderSubmitOrderDispatchOrderPaymentStoreProductManageUserSystemManagerAccountantBank用例之间的关系◼包含关系（incl

ude）：表示一个用例执行过程中，另一个用例也必须被执行。通常把多个用例共享的行为提取出来形成一个用例，然后用包含关系连接起来。◼扩展关系（extend）：一个用例的功能需要通过其他用例进行扩展（在线帮助）。扩展用例只有在某些条件下才会被用到，UM

L提供了扩展点机制，在被扩展的用例中描述什么条件下执行扩展用例。用例之间的关系LoginModifyOrderSubmitOrderDispatchOrderPaymentStoreProductManageUserSystemManagerAccountan

tBankOnlineHelp<<include>><<include>><<include>><<include>><<extend>><<extend>>本章完第3章软件设计基础116什么是软件架构？◼办公室里，关于什么是软件架构，争论正酣。◼程序员说，软件架构就是要决定需要编写

哪些类、使用哪些现成框架。◼程序经理说，软件架构就是模块的划分和接口的定义。◼系统分析员说，软件架构就是为业务领域对象的关系建模。◼配置管理员说，软件架构就是开发出来的以及编译过后的软件到底是个啥结构。◼数据库工程师说，软件架构规定了持久化数据的结构，其他一切只不过是对数据的

操作而已。◼部署工程师说，软件架构规定了软件部署到硬件的策略。◼用户说，软件架构就是决定一个个功能子系统如何划分。◼大家想了想说，这些架构视图好像我们都需要啊，软件架构师哭了。……上述争论可以总结为一句话：不同涉众看待软件架构的视角是

不同的。◼软件设计是软件开发过程中至关重要的部分，它的结果直接影响到最终的软件质量。不等同于“编程序”或“写代码”◼结构化开发方法、面向对象开发方法、基于构件的软件开发方法形成各种系统化的软件设计过程和技术。◼软件设计是一个精化的过程，其中也包含多种活动，并需要灵活运用抽象、模

块化、求精等多种技术。内容3.1软件设计的基本概念3.2软件设计过程3.3软件设计的质量3.4软件体系结构设计3.5高可信软件设计3.6软件设计规格说明3.7软件设计评审3.1软件设计的基本概念◼软件设计主要针对需求分析过程得到的软件需求规格

说明，综合考虑各种制约因素，探求切实可行的软件解决方案并最终给出方案的逻辑表示，包括文档、模型等。◼软件设计受到资源和技术两方面的制约。资源：时间、人力、财力、开发工具。技术：方法、技术、平台。◼软件设计的最终目标是获得满足软件需求的、明确的、可行的、高质量的软件解决方案。明确：设

计模型易于理解可行：在可用的技术平台和软件项目的可用资源条件下，须用预定的开发语言可构造技术可以完整地实现设计模型高质量：设计模型给出需求的实现方案，非功能需求的约束，设计模型优化◼软件设计基本概念是过去数

十年里陆续提出的，软件设计者根据这组概念进行设计决策。（1）抽象与逐步求精◼“抽象”是一个心理学概念，它要求人们将注意力集中在某一层次上考虑问题，而忽略那些低层次的细节。是管理、控制复杂性的基本策略。◼软件设计过程是在不同抽象级别考虑、处

理问题的过程。最初应该在最高抽象级别上，用面向问题域的语言概述问题，包括问题解的形式，然后不断具体化，不断用接近计算机域的语言描述问题，最后，在最低的抽象级别上给出可直接实现的问题解，即程序。（1）抽象与逐步求精◼软

件设过程的每一步都是对较高以及抽象的解作一次更具体化的描述。过程抽象：把完成特定功能的动作序列抽象为一个过程名和参数表，以后通过指定过程名和实际参数调用此过程。数据抽象：把一个数据对象的定义（或描述

）抽象为一个数据类型名，用此类型名可定义多个具有相同性质的数据对象。（1）抽象与逐步求精◼“逐步求精”可视为一种早期的自顶向下设计策略，其主要思想是，针对某个功能的宏观描述用逐步求精的方法不断地分解，逐步确立过程细节，直至该功能用程序语言描述的算法

实现为止。◼在软件设计过程中，抽象与逐步求精是一般都是结合起来进行应用。◼系统的层次结构的上一层是下一层的抽象，下一层是上一层的求精。（2）模块化与信息隐藏◼软件体系结构体现了模块化思想，即把软件划分为可独立命名和访问的部件，每个部件称为一个模块，当把所有模块组装到一起

时则获得满足问题需要的一个解。◼模块化使得开发活动更加简单的一个重要因素是模块的信息隐藏，即一个模块的开发者不必看到其它模块的内部，只需知道其接口即可，这使得每个模块的开发人员所要处理的复杂性显著降低。◼信息隐藏指导的模块化设计不仅

支持模块的并行开发，而且还可以减少测试和维护的工作量。（2）模块化与信息隐藏◼问题求解的研究表明，把两个问题组合起来进行求解的复杂性，一般要比分别对两个问题进行求解的复杂度之和更大，这个结论导致“分治法”的出现，即把一个复杂问题分割成若干个可管理的、更易于求解

的小问题。◼但这种分割并不意味着“无限”分割，当模块数量增加时，模块接口所需要的代价也随之增加。模块数量与成本模块数目成本或工作量M成本/模块接口开销软件总耗费最小成本区域（2）模块化与信息隐藏◼恰当的定义模块范围和大小非常重要，这与采用的设计方法密切相关，评价所

采用设计方法的标准：模块可分解性模块的组装性模块的可理解性模块连续性模块保护内聚与耦合◼每个模块应相对独立，其功能相对单一，而模块之间的接口应尽可能简单。内聚是前述信息隐藏和局部化概念的自然扩展，它标志一个模块内部各成分彼此结合的紧密程度。耦合是对软件结构中模块间关

联程度的一种度量。耦合的强弱取决于模块间接口的复杂性、进入或调用模块的位置以及通过接口传送数据的多少等。追求高内聚、低耦合。（1）抽象与逐步求精内聚◼内聚按其高低程度可划分为不同等级，内聚度越高越好，从而获得较高的模块独立性。低等级内聚：偶然性内聚：最低程序的内聚逻辑性内

聚时序内聚中等级内聚：过程性内聚通信性内聚高级内聚：顺序性内聚功能性内聚：最高程度的内聚三、内聚与耦合◼偶然性内聚：一个模块内各成分为完成一组功能而组合在一起，它们相互之间即使用关系，也很松散◼逻辑性内聚：模块完成的诸任务逻辑上相关◼时序内聚：一个

模块包含的任务必须在同一时间内执行◼过程性内聚：模块内成分彼此相关，并且必须按特定的次序执行◼通信内聚：模块中各成分都将对数据结构的同一区域进行操作◼顺序性内聚：各成分均与同一功能相关，且处理按序执行◼功能性内聚：所有成分形成一个整

体，完成单个功能模块内聚A:Readinputsfromdiskfromtapefrom……逻辑内聚（Logicalcohesion）：Logicallyrelatedfunctionsordataareplacedinthesamem

odule.例如：偶然性内聚（Coincidentalcohesion）：Unrelatedfunctions,processes,ordataarefoundinthesamemodule(forconvenience).例如：工具模块时序内聚（Temporalcohesion）：Thefu

nctionsarerelatedonlybythetiminginvolved.例如：系统的初始化问题：不同功能混在一个模块中，有时共用部分编码，使局部功能的修改牵动全局。通信内聚（Communicationalcohesion）：Allthefunctionsinamoduleoperat

eonorproducethesamedataset.例如：从同一磁带上读取不相干的数据——可能破坏独立性。过程内聚（Proceduralcohesion）：Functionsaregroupedto

getherinamoduletoensureacertainorderofperformance.例如：enterdatacheckdatamanipulatedata高内聚：顺序内聚（Sequentialcohesion）：Theo

utputfromonepartofamoduleistheinputtothenextpart.功能内聚（Functionalcohesion）：Everyprocessingelementisessentialtotheperformanceofasinglefunct

ion.c模块内聚耦合◼耦合的强弱取决于模块间接口的复杂性、进入或调用模块的位置、通过接口传输数据量等。◼模块间的耦合程度直接影响着系统的可理解性、可测试性、可靠性和可维护性，软件设计应追求尽可能松散的耦合，模块间的联系越少，错误在模块间传递的可能性就越小。耦合◼耦合等级的划分低等级耦

合：非直接耦合中等级耦合数据耦合特征耦合控制耦合外部耦合公共耦合高等级耦合：内容耦合传递的信息含有控制信息◼非直接耦合：两个模块中的任一个都不依赖对方能独立工作。◼数据耦合：两模块间通过参数交换信息，数据仅限于数据。◼控制耦合：模块间

传递的信息含有控制信息。◼特征耦合：介于数据耦合和控制耦合之间。◼外部耦合：若干模块均与同一外部环境关联。◼公共耦合：若干模块通过全局的数据环境相互作用。◼内容耦合：一个模块使用另一模块内部的数据或控制信息，或一个模块直接转移到另一模块内部。⑴耦合(Coupling)Gr

eatdealofdependenceIndependentHighlycoupledLooselycoupledUncoupled☺例1：A访问C的内部数据或不通过正常入口而转入C的内部。……ABCDA:……………………gotoC

1……………………C:……………………C1:…………内容耦合(ContentCoupling):Onemodulemodifiesanother.例2：部分代码重叠（常出现在汇编程序中）BA例3：一个模块有多个入口（功能

）A:………………………………entry1:………………………………entry2:………………………………Theleastdesirable公共耦合(Commoncoupling)：Dataareaccessiblefromacommondatastore.Global

:V1V2A:……………………A1=V1+V2……………………B:……………………V1=B1……………………Global:V1V2A:……………………V1++……………………B:……………………V2=B1+V1……………………问题：公共部分的改动将影响所有调用它的模块；公

共部分的数据存取无法控制；复杂程度随耦合模块的个数增加而增加。控制耦合(Controlcoupling)：Onemodulepassesparameterstocontroltheactivityofano

thermodule.ABFlagF2F1Fn…………Flag接口单一，但仍然影响被控模块的内部逻辑。数据耦合(Datacoupling):Onlydataarepassed.Itiseasytotracedat

aandmakechanges.☺Themostdesirable.原则：尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，完全不用内容耦合。模块间的耦合启发性规则1.争取低耦合、高内聚（增加内聚>减少耦合）2.模块规模适中：过大不易理解；

太小则接口开销过大。注意分解后不应降低模块的独立性。3.适当控制——深度=分层的层数。过大表示分工过细。宽度=同一层上模块数的最大值。过大表示系统复杂度大。启发性规则◼系统结构启发性规则扇出=一个模块直接调用\控制的模块数。3fan-out9AA

的扇出AA的扇入扇入=直接调用该模块的模块数在不破坏独立性的前提下，fan-in大的比较好。启发性规则◼尽可能减少高扇出结构，随着深度增大扇入。如果一个模块的扇出数过大，就意味着该模块过分复杂，需要协调和控制过多的下属模块。应当适当增加中间层次的控制模块启发性规则4、作用域

在控制域内控制域MACBM的控制域为{M，A，B，C}作用域：M中的一个判定所影响的模块。例如：A:…………if……thengotoB1……………………B:……………………B1:……………………作用域在控制

域内A:…………if……thengotoM1……………………M:……………………M1:gotoC1……………………作用域超出了控制域上例中A的作用超出了控制域。改进方法之一，可以把A中的if移到M中；方法之二，可以把C移到A下面。启发性规则5、降低接口的复杂程度：接口复杂可能

表明模块的独立性差。6、单出单入，避免内容耦合。7、模块功能可预测——相同输入必产生相同输出。反例：模块中使用全局变量或静态变量，则可能导致不可预测。内聚和耦合的量化指标◼类耦合度类的耦合度为与它耦合的其它类的数目，包括调用其他类的方法、使用其它类的实例变量。一个类越独立，它在应

用中就越容易被重用，类之间的耦合度应尽可能的小。◼方法内聚缺乏程度“不访问相同成员变量的方法对数目”减去“访问相同成员变量的方法对数目”如果一个类中没有任何两个方法对同一变量进行访问，则它们没有相似性，该类的内聚程度将会很低，缺乏内聚度意味着该类可以分为两个或更多的类。内容3.1软件设

计的基本概念3.2软件设计过程3.3软件设计的质量3.4软件体系结构设计3.5高可信软件设计3.6软件设计规格说明3.7软件设计评审（1）软件设计的一般过程◼软件设计可能是一个多次反复的过程，所以，软件设计一般都可以被看作是迭代的过程。◼迭代有两层含义：第一层含义

是，针对给定的需求模型，通过多次从抽象到具体的设计过程，得出足够精细的设计模型以供软件实现之用。第二层含义是，在需求模型发生变化并更新完成后，第一层含义的设计过程再随之展开，直至获得最终的目标软件产品。软件设计的迭代需求单次设计过程原型构造需求变化第一层：针对固定需求

的设计精化迭代第二层：针对需求变化进行设计迭代软件设计的一般过程◼软件设计过程包括在不同抽象层次上开发系统的多个模型。◼软件设计可以看作是将需求规格说明转换为可直接提供软件代码实现使用的设计规格说明。◼工程管理的角度：概要设计：根据需求确定软件和数据总体框架。详细设计：进一步精化成软件

的算法表示和数据结构。技术上，概要设计和详细设计由若干活动组成，包括软件体系结构设计、界面设计、模块/子系统设计、数据模型设计、过程/算法设计。软件设计的一般过程设计活动需求规格说明设计计划体系结构设计界面设计模块/子系统设计过程/算法设计数据模型设计设计规格说

明设计评审通过未通过1）软件设计计划◼在设计过程中，对设计活动进行计划应该最早进行，然后按照计划实施体系结构设计、界面设计、模块/子系统设计、数据模型设计、过程/算法设计等活动。◼软件设计计划的任务是：明确设计过程的输入制品并使其处于就绪状态，定义设计过程的目标、输出制品及其验收准则

，确定覆盖设计过程中各个阶段的全局性设计策略，分配设计过程相关人员的职责，针对设计过程中的活动制订工作计划。1）软件设计计划◼软件设计计划的步骤：确定设计的目标和验收标准明确目标软件系统应遵循的技术标准或规范重新审视项目风险管理计划制定

本次设计过程的工作计划对设计过程的工作计划进行评审2）体系结构设计◼软件体系结构设计的目标是建立软件系统的体系结构，有时也称“顶层架构”。◼这种架构既要明确定义软件各子系统、关键构件、关键类的职责划分及协

作关系，同时也要描绘它们在物理运行环境下的部署模型。◼顶层架构还必须针对软件系统全局性、基础性的技术问题给出技术解决方案，这种方案往往构成目标软件系统的体系结构的技术基础设施。2）体系结构设计◼评价软件体系

结构宽度和深度：软件控制的层数和跨度扇出率和扇入率：扇出率：一个模块的扇出率指该模块直接控制的其他模块数。扇入率：一个模块的扇入率指直接控制该模块的模块数。可见性和联通性模块的可见性：该模块可直接或间接引用的一组模块。模块的联通性：模块可直接引用的一

组模块。软件结构有关概念ABCDEFGHJI深度宽度扇出扇入3）界面设计◼用户界面设计的目标是，为用户使用目标软件系统以实现其所有业务需求而提供友好的人机交互界面。◼软件界面设计需要考虑以下因素：适用于软件功能易理解性一致性灵敏性容错性人性化国际化个性化合理的布局和谐的色彩界

面的易用性界面的美观性4）模块/子系统设计◼子系统和模块的区别：一个子系统独立构成系统，不依赖其它子系统提供的服务。一个模块通常是一个能提供一个或多个服务的系统部件。它能利用其它模块提供的服务，一般不被看成一个独立的系统。◼由于模块和子系统都是软件组成部分，它们一般都有层次结构，相互之间存在接

口，其设计方法有很多类似的方面，因此我们统一称为模块设计。模块设计的目标◼模块设计的目标是，确定模块的具体接口定义，并设计模块的内部结构，即，设置包含于其中的（更小粒度的）模块、构件和设计类，◼明确它们之间的协作关系，确保它们能够协同实现高层模块接口规定的所有功能和行为。◼在进行模块设计时，要尽量

保持模块的功能独立性，遵循“高内聚、低耦合”的设计思想。◼此外，还要力求将模块的影响限制在模块的控制范围内，使得软件日后的修改和维护工作更加简单。5）过程/算法设计◼过程/算法设计的任务就是对模块内部的工作和执行过程进行描述，给出有关处理的精确说明，例如事件的顺序、确切的决策位置、循环

操作以及数据的组成等。◼软件结构与软件过程相互关联，软件结构中任何模块的所有从属模块必将被引用出现在该模块的过程说明中。因此，软件过程对应的结构设计亦构成一个层次结构。◼可以使用UML对模块进行设计使用UML的模

块过程设计6）数据模型设计◼我们把数据结构设计、数据库设计、甚至数据文件设计等统一称为数据模型设计。◼在数据模型设计中有一个重要概念：持久数据操作，它包括写入、查询、更新和删除四类基本操作以及由它们复合而成的业务数据操作。◼在很多软件系统中，数据是其核心，因此，对数据元素的

格式、结构、访存、表示等机制进行良好建模和优化，是提高软件设计质量和系统性能的基础，对软件系统的应用具有重要意义。内容3.1软件设计的基本概念3.2软件设计过程3.3软件设计的质量3.4软件体系结构设计3.5

高可信软件设计3.6软件设计规格说明3.7软件设计评审软件设计质量的重要性◼软件设计是软件开发过程中的核心活动，软件设计的质量不但对最终软件产品的质量起着决定性作用，还对软件开发过程以及软件以后在使用过程中维护的难易程度有着重

要的影响。◼高质量的软件设计，能够有效缩短软件开发时间，减少开发成本，提高最终软件产品质量。软件设计的质量要素◼评价软件设计的质量结构良好充分性可行性简单性实用性灵活性健壮性可移植性可复用性标准化软件设计的质量◼软件设计对最终

软件产品质量产生的影响包括：正确性可靠性运行效率可移植性可维护性可复用性软件设计的质量◼软件设计对软件开发过程可能产生的影响包括：开发效率交付时间风险管理资源使用成本人员培训合法性正确性◼目标:每个项目都要满足指定的需求，然后一起满足所有应用程

序的需求◼实现正确性的途径：达到正确性的非正式方法完全理解－>模块化达到正确性的正式方法达到正确性的非正式方法：充分设计一个设计足以实现需求一个正确的设计有时称为设计必须完全可理解接下来设计非常模块化达到这个目标的方法是：。。。最小目标达到正确性的正式方法◼基于在严密的控

制下跟踪变量的变化，一般会指定一个不变式。不变式在变量值之间表示的是一种不变关系。例如：◼length>=0◼length*breadth==area◼overdraft<OVERDRAFT_MAX◼用在类级别设计中的不变式称为类

不变式。例如1）mileage>=02)mileage<10000004)value>=-3005）originalPrice>=06）(type==“REGULAR”&&value<=originalPrice)||(type

==“VINTAGE”&&value>=originalPrice)◼考虑不变式，将变量设为私有，只能通过公有的存取方法才能改变他们的值。可以对存取方法进行编码来保持不变式。如通过setter方法来设置类不变式◼精心设计

的类通常拥有可理解的不变式集。1.防止错误输入o用户输入o不是用户的输入•数据通信•其他应用方法调用2.防止开发错误错误的设计错误的实现健壮性健壮性◼检查输入在继续进行处理之前，可以检查应用程序的所有输入的方法。检查类型（例

如：整形);检查与前置条件和不变式的输入◼为提高健壮性而初始化提供静态方法，用来为类产生标准的默认值◼提高健壮性的参数传递技术保证方法正确调用引入一个捕获参数的类并将约束条件合并◼强化意图通过防止设计和实现中的错误来提高

健壮性强化计划，按计划使用相应功能Example:intcomputeArea(intaLength,intaBreadth){…}❑如果可行，捕获在类中的参数约束intcomputeArea(RectangleDimen

sionaRectangleDimension)❑在方法中说明所有的参数约束aLength>0andaBreadth>0andaLength>=aBreadth❑在方法代码中首先检查约束if(aLength<=0)……如

果预计这种情况将会出现，则抛出异常否则，如果可能就中止程序否则如果返回的默认值在上下文之间有意义，就将其返回并且产生警告或日志参数的约束ReplaceintcomputeArea(intaLength,intaBreadth){..}withintcomputeAr

ea(RectangleaRectangle){..}--whereclassRectangle{…Rectangle(intaLength,intaBreadth){if(aLength>0)this.length=aLength

;else…..}…}只在一个地方进行错误处理，改进了设计与维护性，不足是产生了类的激增。健壮性在使用数据之前进行检查，可以提高健壮性。灵活性灵活性的预期目标：◼用于增加更多类型功能的设计例如（银行应用）：处理更多类型的账号而不需要修改已存在的代码◼用于增加不同

类型功能的设计例如：在存款功能的基础上增加提款功能◼修改功能例如：可透支应用中增加同类型功能的设计◼举例：网站成员注册WebSiteregister()Member0..nmembersclassWebsite{Member[]members;/

/ormaybe:vectormembers;voidregister(MemberaMember){...}}怎样才能使设计更灵活以注册新类型的成员？注册网站的灵活性WebSiteMember0..nStand

ardMemberXMemberYMembermembers解决方案：引入一个基类，将基类抽象化，根据需要产生继承类灵活性我们之所以进行灵活的设计，因为变化和重用是经常出现的可重用性◼尽可能的降低成本◼重用原有的工作可以

获得最大生产率◼重用：函数重用、类重用、重用类组合可重用设计，可重用组件◆函数设计的可重用性◆基于重用的类选择◆用于重用的类组合使一个方法具有可重用性❑完全指定前置条件等❑避免不必要的封装类耦合如果可行，让

方法成为静态的参数化让方法功能化但要限制参数的个数❑让名字更具表达性可理解性促进可重用性❑解释算法重用者要知道算法如何工作◼重用的方法必须给出完整的定义，以便使重用者知道这些方法的功能及使用条

件◼一个方法对于上下文越独立，其可重用性的性能就越高。静态方法就属于这种类型使一个类成为可重用的❑完整的描述类❑使类名与功能与实际情况相符❑定义一个有用的抽象类以获得更广泛的应用❑减少对其他类的依赖性通过继承获得减少类间的依赖性◼如果类A依赖于类B，没有类B就不可以使

用类A，这就减少了类A的重用性。◼Piano类依赖Custumer类，因为钢琴是卖给用户的，限制了Piano类的使用。◼一个库存应用程序可能需要Piano类，但却不需要Customer类。重用Piano类。◼能否让Custumer类依赖Piano类，因

为用户只有购买钢琴时才成为用户。◼有没有更好的解决方案呢？降低依赖性。CustomerReplace…Piano减少类间的依赖性◼引入第三个类PianoOrder将其关联起来。◼这个设计具有一定的作用，但在现实情

况中可能是不行的。例如，可能需要访问某一给定用户的订单，而不必检查每个PianoOrder订单对象。◼中介者设计模式解决问题◼减少类之间的依赖关系，抽象级的依赖关系是可以接受的。通过减少类的依赖性来增加其可重用性with…CustomerPian

oPianoOrder高效性◼应用程序必须在给定的时间内完成特定的功能◼执行效率处理循环问题消除远程调用消除或制定函数调用◼存储效率RAM的大小（运行时）代码本身的规模辅助存储器的大小执行效率◼影响执行效率的一些因素◼循环w

hile,for,do◼远程调用：消除远程调用Requiringanetwork需要网络LANTheInternet◼函数调用：消除函数调用如果函数调用导致以上情况发生◼对象创建◼高效的设计并不要求简单，甚至会比较凌乱◼高效原则会减少函数调用

，会导致产生大量的方法和类，难于扩展和重用❑先按其它原则设计，再考虑效率以灵活性，可重用性等原则进行设计找出效率低的部分有针对性的修改❑一开始就按效率原则进行设计确认当前关键的效率需求在整个阶段都按需求进行设计❑以上两种方法

的结合在设计时为效率需求做出折中在初始设计之后，也要继续考虑效率问题针对时间效率的基本方法时空折中Space处理一个项目的时间通常的目标时间、空间、开发的折中空间时间开发的设备限制可接受的值不可接受的值好于可接受的值内容3.1软件设计的基本概念3.2软件

设计过程3.3软件设计的质量3.4软件体系结构设计3.5高可信软件设计3.6软件设计规格说明3.7软件设计评审（1）软件体系结构设计方法概述◼软件体系结构的设计方法是指通过一系列的设计活动，获得满足系统功能性

需求、并且符合一定非功能性需求约束的软件体系结构模型。◼目前存在多种体系结构设计方法，它们的侧重点有所不同(功能、非功能、复用)。◼在实际应用过程中，这些体系结构设计方法并不是绝对互斥的，根据需要，有可能综合运用不同体系结构设计方法的思想，得到最终所需的设计结果。软件体系结构设计方法◼‘4+1’多

视图建模◼基于评估与转换的设计方法◼模式驱动的设计方法◼领域特定的软件体系结构设计复用◼软件产品线方法◼其它软件体系结构设计方法◇“4+1”模型概述Kruchten在1995年提出了“4+1”的视图模型。“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和

场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。1）多视图建模进程视图物理视图逻辑视图开发视图场景最终用户功能特性开发人员软件管理集成人员性能可扩展性系统工程师拓扑通信◇逻辑视图逻辑视图主要支持系统的功能需求，即系统提供给最终用

户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。◇逻辑视图可以从Booc

h标记法中导出逻辑视图的标记法，只是从体系结构级的范畴来考虑这些符号，用RationalRose进行体系结构设计。构件实例继承使用包含，聚集关联类层次参数化类类服务类连接件◇逻辑视图逻辑视图中使用的风格为面向对象的风格，逻辑视图设

计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。会话终端控制器转换服务连接服务编号计划◇逻辑视图对于规模更大的系统来说，体系结构级中包含数十甚至数百个类。显示及用户接口机械服务基本元素航空信息空中交通管理飞行管理外部接口网关仿真和培训◇开发视图开发视图也称模块视图，主要侧重于软

件模块的组织和管理。开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统输入输出关系的模型图和子系统图来描述。◇开发视图与

逻辑视图一样，可以使用Booch标记法中某些符号来表示开发视图。构件参照相关性模块连接件子系统层◇开发视图在开发视图中，最好采用4-6层子系统，而且每个子系统仅仅能与同层或更低层的子系统通讯，这样可以

使每个层次的接口既完备又精练，避免了各个模块之间很复杂的依赖关系。设计时要充分考虑，对于各个层次，层次越低，通用性越强，这样，可以保证应用程序的需求发生改变时，所做的改动最小。开发视图所用的风格通常是层次结构风格。◇开发视图公用构件1低层服务支撑机制：通信、时间、储存、资源管理等

2航空类、空中交通管制类3空中交通管制功能区：飞行管理、雷达管理等4人机接口外部系统5离线工具测试工具各种各样的空中交通管制系统特定的空中交通管制系统构件空中交通管制系统框架分布式虚拟机基本元素硬件、操作系统、数据库领域特定领域无关通用空中交通管制代码客户定制◇进程视图进程视图侧重于系统的运行特

性，主要关注一些非功能性的需求。进程视图强调并发性、分布性、系统集成性和容错能力，以及从逻辑视图中的主要抽象如何适合进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象，每个级别分别关注不同

的方面。在最高层抽象中，进程结构可以看作是构成一个执行单元的一组任务。它可看成一系列独立的，通过逻辑网络相互通信的程序。它们是分布的，通过总线或局域网、广域网等硬件资源连接起来。◇进程视图通过扩展Booch对Ada任务的表示法，来表示进程视图。构件事件广播双向消息远程过程调用

消息未指定连接件循环进程简化进程进程◇进程视图控制器进程慢周期控制器任务快周期控制器任务主控制器任务终端进程◇物理视图物理视图主要考虑如何把软件映射到硬件上，它通常要考虑到系统性能、规模、可靠性等。解决系统拓扑结构、系统安装、通讯等问题。当软件运行于不同的节点上时

，各视图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小。◇物理视图大型系统的物理视图可能会变得十分混乱，因此可以与进程视图的映射一道，以多种形式出

现，也可单独出现。构件宽带或总线双向通信单向通信临时通信通信其他设备处理器连接件◇物理视图ACS系统的物理视图C主KKKKKKKKF备份F主F备份F主C备份◇物理视图具有进程分配的小型ACS系统的物理视图K会话进程F终端进程控制器进程◇物理视图具有进程分配的大型ACS系统的物理视

图C中心进程备份节点伪中心进程F会话进程终端进程伪中心进程F会话进程终端进程K控制器进程K控制器进程K控制器进程更多的K类处理器线路接口卡线路接口卡线路接口卡◇场景场景可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。在开发体系结构时，它可以帮助

设计者找到体系结构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。◇场景本地呼叫场景的一个原型（1）摘机小

王:控制器编号计划小王:终端小王:会话（2）拨号音（3）号码（4）号码（5）打开会话◇小结逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来

说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。◼“4+1”模型一览表逻辑视图过程视图开发视图物理视图场景视图构件类过程模块、子系统节点用例、活动连接件关联、继承、使用

消息、广播、过程调用参照相关性通信线路涉众最终用户系统集成人员开发人员工程人员最终用户、开发人员关注点功能性能、可用性组织、可用性、整体性可伸缩性、性能、可用性可理解性◼“4+1”模型实例为了便于理解，我们将一个实际系统的软件体

系结构用“4+1”模型描述出来。某一市级政府部门需要建立领导决策信息支持系统，其目的是将领导日常工作中经常浏览的信息从公文服务器实时集成到信息服务器中，并通过浏览器分类浏览。领导所要浏览的信息包括各类

公文、区县政府部门的人员编制、区县概况等信息。◼“4+1”模型实例系统逻辑视图领导浏览器Web服务器Web服务数据集成服务公文数据库服务器数据更新服务信息数据库服务器系统边界◼“4+1”模型实例系统进程视图数据集成任务公文数据库服务过程信息数据库服

务过程Web服务任务信息浏览任务◼“4+1”模型实例系统开发视图操作系统、硬件数据库服务器Web服务器数据集成服务Web服务：网页、相关资源浏览器1234◼“4+1”模型实例系统物理视图(1)：一般视图公文数据库服务器信息数据库服务器Web服务器领导终端领导终端领导终

端◼“4+1”模型实例系统物理视图(2)：具有进程分配的视图Web服务软件公文数据库服务器数据库服务器软件数据集成软件数据库服务器软件浏览器浏览器浏览器◼“4+1”模型实例场景视图数据集成服务公文数据库服务器信息数据库服务器1、时间到，查

看是否有新数据2、答复3、读取数据5、保存4、返回数据◼“4+1”模型存在的问题在如何构造这些视图，以及视图之间的关系方面缺乏指导，使用者只能通过经验体会并利用。数据作为系统开发的重要方面，没有在“4+1”

模型中得到很好地体现。不能描述体系结构风格。2）基于评估与转换的设计方法◼针对功能特性设计体现结构，对设计结果进行评审，如果不满足要求则进行改进，一直迭代到满足要求为止。◼对设计出的体现结构的质量进行评估、不满足要求时的体现

结构转换特别重要。2）基于评估与转换的设计方法基于功能的体系结构设计质量属性评价体系结构制品需求规格说明体系结构转换质量优化方案不满足满足体系结构的评估◼基于场景的评估◼仿真◼数学建模◼基于经验的推理体系结构设计转换方式◼质量评价结果不满足需求

规格说明，需要改变评估环境（修改评估）或修改体系结构设计，有以下三种体系结构转化方式：使用合适的体系结构风格和模式，或者设计模式来改进体系结构设计。把非功能需求转化为功能性解决方案，该功能性方案可以与问题域无关

，但可以满足质量属性的要求。采用“分而治之”的方式，可以把系统级的质量需求分配到子系统或模块中，或者把质量需求分解为多个与功能相关的质量需求，分解后的质量需求能够比较容易得到满足。软件设计经验的总结和复用◼模式驱动的设计方法◼领域特定的软件体系结构设计◼软件产品线方法体系结构风格

/模式◼体系结构风格是描述某一特定应用方式中系统组织方式的惯用模式，为设计人员提供公共的模型、符号和术语表示，促进设计复用甚至代码复用◼体系结构模式是对设计模式的扩展，描述了软件系统基本的结构化组织方案，是具体体系结构的模板。◼体系结构风格描述了软件总体框架的结构，综合考虑整个系

统各方面的需求。◼设计模式是针对单一的问题提供解决方案，层次比软件体系结构风格低。3）模式驱动的设计方法系统特征初步分析需求规格说明搜索可用的体系结构风格对体系结构风格进行改造以体系结构风格为基础进行设计选择合适的体系结构风格自行设计软件体系结构软件体系结构设计模型不存在存在扩展软件体系

结构风格库体系结构风格的分类体系结构风格分类独立构件体系结构数据流体系结构数据为中心的体系结构虚拟机体系结构调用与返回体系结构4）领域特定的软件体系结构设计◼领域特定的软件体系结构（DomainSpecificSoftwar

eArchitecture，DSSA）是领域工程的核心部分，领域工程分析应用领域的共同特征和可变特征，对刻画这些特征的对象和操作进行选择和抽象，形成领域模型，并进一步生成DSSA。◼领域特定的软件体系结构借鉴领域中已经成熟的

软件体系结构，实现解决方案在某个领域内的复用。虽然这些系统实例的细节会有不同，但共同的体系结构在开发新系统时是能够复用的。DSSA与体系结构风格的区别◼DSSA与软件体系结构风格是从不同角度出发研究问题的

两种结果，前者从问题域出发，而后者从解决域出发。◼DSSA只在某个特定领域中进行经验知识的提取、总结与组织，但可以同时使用多种软件体系结构风格；而一种软件体系结构风格所呈现的公共结构和设计方法可以扩展到多个应用领域。◼DSSA的体系结构表示和工具一般只适用于一个较小的范围，在其它领域中是不适

用并难以复用的。领域特定的软件体系结构类型◼类模型：类模型是从许多实际系统中抽象出来的一般模型，它们封装这些系统的主要特征。如：编译器模型，大量的编译器几乎都基于同一种体系结构。◼参考模型：参考模型是更抽象且

是描述一大类系统的模型，它对设计者是有关某类系统的一般结构的指导，通常源自于对某应用领域的研究。它代表了一个理想化的体系结构，包含了系统所有应该具有的特征。如：OSI七层参考模型。5）软件产品线方法◼软件

复用的更高阶段，已经超出软件体系结构设计方法的范畴。◼软件产品线指一组具有公共的、可管理特征（系统需求）的软件系统，这些系统满足特定的市场需求或者任务领域需求，并且按照预定义的方式基于公共的核心资产（CoreAs

sets）集合开发得到。◼软件产品线主要由两部分组成：核心资产库：产品线的基础，是领域工程所有成果的集合，管理支持产品开发的可复用资源。产品线体系结构和构件是核心资产库中用于产品构建的最重要部分。产品集合软件产品线过程模型产品开发核心资产开发管理产品线开发领域工

程应用工程产品线方法的基本活动◼核心资产开发：如何获得核心资产，可以自己构建、直接购买、委托加工等方式。◼产品开发：是产品线的目标，核心资产开发只是达到该目标的一种手段。◼管理：为各个活动合理分配资源、协调监督、设置恰当的组

织机构等。循环重复是产品线开发过程、核心资产开发、产品开发以及对其进行管理的特征。核心资产开发和产品开发没有先后顺序，管理活动协调整个产品线开发过程的各个活动。新产品形成步骤◼从公共资产库中选取合适的构件；◼使用预定义的变化机

制进行裁剪，如参数化、继承等；◼必要时增加新的构件；◼在整个产品线范围内共同的体系结构指导下，进行构件组装，形成系统。新产品的开发从“创造”变成“组装”，占支配地位的活动是“集成”而非“编程”。软件产品线是对特定领域的软件开发更加全面的复用，包括领域特定的软件体系结构设计方法。（到商店

里买，去仓库里拿，而不是自己慢慢烹饪）6）其它软件体系结构设计方法◼基于目标图推理的体系结构设计方法◼基于属性的体系结构设计方法◼一些常用的软件开发方法学中也包含了软件体系结构的设计，例如：面向数据流的软件开发方法面向对象的软件开发方法面向方面的软件开发方法软件体系结构设计步骤◼始于体系结

构设计，自顶向下、逐步精化。◼体系结构设计是在需求规格说明、软件设计计划已经完成后开始的。◼软件体系机构设计步骤图（2）软件体系结构设计步骤1.开发软件顶层架构2.搜索并选取可用设计资产3.设计技术支撑方案4.确定设计元

素5.开发软件部署模型6.设计并发机制7.构建软件体系结构模型8.评审软件体系结构模型内容3.1软件设计的基本概念3.2软件设计过程3.3软件设计的质量3.4软件体系结构设计3.5高可信软件设计3.6软件设计规格说明3.7软件设计评审案例:阿丽亚娜5型火箭软件设计的反思

◼1996年6月,欧洲航天局研制的”阿丽亚娜5型火箭”在法国圭亚那库鲁航天中心首次发射,这次发射因空中云层过厚而被推迟了1小时.随后高51.4米,通体银白的火箭离开发射台升空约30秒,距地面约4000米时,

半空传来两声巨大的爆炸声.70亿美元的研制费用,上万人10余年的心血,瞬息间付之一炬.◼外电报称:这是自1986年美国”挑战者”航天飞机爆炸后,世界航天史上的又一大悲剧.◼事件发生后,欧洲航天局成立的专门的调查委员会,经过6周的调查,确认失败的原因为:阿丽亚娜5型火箭在主发动机点

火顺序开始37秒后,制导和姿势信息完全遗失造成的,信息遗失是由于惯性制导系统的软件出现规格和设计错误.◼原因一:在需求分析和设计中,没有对惯性制导系统中”重用”软件的合理性,进行可行性分析和认证采用了阿丽亚娜4型火箭的惯性制导系统.但5型的功率和飞行速度都远大于4型,惯性制导系统把64位的浮

点数转换为一个带符号的整数时,由于数量太大而超限◼原因二:查错设计的失误对于这种非常重要的操作数的转换,本来应该在设计时加以防范,设计人员也考虑到了这一点,他们发现7个变量可能引起操作数有差错,但是由于计算机的最大工作负荷已达80%,于

是它们只对其中4个变量进行了保护◼原因三:改错设计的失误在许多安全关键系统中，如果发现关键失效发生,通常采用紧急停机的措施.◼原因四:容错方法的失误阿丽亚娜5型的设计师们非常重视可靠性技术中的冗余设计技术

.火箭的惯性制导系统采用双备冗余.火箭上的主计算机也是双备冗余,飞行控制系统的许多单元也是双备冗余.但是他们忽视了软件容错的特殊性,在硬件的热备份系统中使用了完全相同的软件版本,只做到了硬件容错（1）可信软件的特点◼计算机系统的缺陷很大一部分是由于软件的

问题引发的。纵观软件应用的发展历史，国际上由于软件可信性问题所导致的重大灾难、事故和严重损失屡见不鲜，软件的可信性问题已经成为一个相当普遍的问题。◼所谓“可信软件”，是指软件系统的运行行为及其结果总是符合人

们的预期，且在受到干扰（包括操作错误、环境影响、外部攻击等）时仍能提供连续的服务。可信属性◼可靠性（Reliability）：在规定的环境下和规定的时间内，软件无失效运行的概率；◼可靠安全性（Safety）：软件运行不引起危险、灾难的能力；◼保密安全性（Se

curity）：软件系统对数据和信息提供保密性、完整性、可用性、真实性保障的能力；◼可生存性（Survivability）：软件在受到攻击或失效出现时连续提供服务并在规定时间内恢复所有服务的能力；◼实时性（RealTime）：软件在指定的时间内完成反应或提交输出

的能力。成本－可信曲线可信性成本低中高很高极高由于需要附加的设计、实现和验证开销，提高可信行性将极大的增加开发成本指数曲线软件可靠性分析与设计软件可靠性管理软件可靠性参数与指标的确定软件可靠性分析与设计软件可靠性测试与验证软件交付与使用软件可靠性早期预计软件可靠性预

计和估计软件需求分析阶段软件设计与实现阶段软件测试阶段软件交付与使用软件可靠性分析与设计的原因◼软件在使用中发生失效（不可靠）会导致任务的失败，甚至导致灾难性的后果。因此，应在软件设计过程中，对可能发生的失效进行分析，采取必要的措施避免将引起失效的缺陷引入软件，为失效纠正措

施的制定提供依据，同时为避免类似问题的发生提供借鉴。◼这些工作将会大大提高使用中软件的可靠性，减少由于软件失效带来的各种损失。Myers设计原则Myers专家提出了在可靠性设计中必须遵循的两个原则：◼控制程序的复杂程度使系统中的

各个模块具有最大的独立性使程序具有合理的层次结构当模块或单元之间的相互作用无法避免时，务必使其联系尽量简单，以防止在模块和单元之间产生未知的边际效应◼是与用户保持紧密联系模块化逐步求精信息隐蔽软件可靠性设计◼软件可靠性设计的实质是在常规的软件

设计中，应用各种必须的方法和技术，使程序设计在兼顾用户的各种需求时，全面满足软件的可靠性要求。◼软件的可靠性设计应和软件的常规设计紧密地结合，贯穿于常规设计过程的始终。◼这里所指的设计是广义的设计，它包括了从需求分析开始，直至实现的全过程。软件可靠性设计的四种类型容错设计改错设计查错设计避错设

计软件可靠性设计软件避错设计◼避错设计是使软件产品在设计过程中，不发生错误或少发生错误的一种设计方法。避错的设计原则是控制和减少程序的复杂性。◼体现了以预防为主的思想，软件可靠性设计的首要方法◼各个阶段都要进行避错◼从开发方

法、工具等多处着手避免需求错误深入研究用户的需求（用户申明的和未申明的）用户早期介入，如采用原型技术选择好的开发方法结构化方法：包括分析、设计、实现面向对象的方法：包括分析、设计、实现基于部件的开发方法（COMPONENTBASED）

快速原型法软件避错设计准则◼(1)模块化与模块独立假设函数C(X)定义了问题X的复杂性，函数E(X)定义了求解问题X需要花费的工作量（按时间计），对于问题P1和问题P2，如果C(P1)>C(P2)，则有E

(P1)>E(P2)。人类求解问题的实践同时又揭示了另一个有趣的性质：(P1+P2)>C(P1)+C(P2)由上面三个式子可得：E(P1+P2)>E(P1)+E(P2)◼这个结论导致所谓的“分治法”----将一个复杂问

题分割成若干个可管理的小问题后更易于求解，模块化正是以此为据。◼模块的独立程序可以由两个定性标准度量，这两个标准分别称为内聚和耦合。耦合衡量不同模块彼此间互相依赖的紧密程度。内聚衡量一个模块内部各个元素彼此结合的紧密程度。软件避错设计准则◼(2)抽象和逐步求精抽象是抽出事物的本质特性而暂时

不考虑它们的细节◼举例抽象Ⅰ该CAD软件系统配有能与绘图员进行可视化通信的图形界面，能用鼠标代替绘图工具画各种直线和曲线；能完成所有几何计算以及所有截面视图和辅助视图的设计。抽象ⅡCAD软件任务；用户界面

子任务；创建二维图形子任务；管理图形文件子任务；ENDCAD抽象III………………◼软件工程过程的每一步都是对软件解法的抽象层次的一次精化软件避错设计准则◼(3)信息隐蔽和局部化信息隐藏原理指出：应该这样设计和确定模块，使得一

个模块内包含的信息对于不需要这些信息的模块来说，是不能访问的。“只有需要才能知道”如果绝大多数数据和过程对于软件的其他部分而言是隐蔽的，那么在修改期间由于疏忽而引入的错误就很少可能传播到软件的其它部分局部化是指把一些关系密切的软件元素物理地放得彼此靠近局部变量软件避错设计◼慎重使用容

易引入缺陷的结构和技术浮点数指针动态内存分配并行递归中断继承别名默认输入的处理软件查错设计◼软件查错设计是指在设计中赋予程序某些特殊的功能，使程序在运行中自动查找存在错误的一种设计方法。◼被动式错误检测在程序的若干部位设置检测点，等待错误征兆的出现◼主动式错误检测对程序状态主

动进行检查被动式错误检测◼检测原则相互怀疑原则：在设计任何一个单元、模块时，假设其它单元、模块存在着错误；立即检测原则：当错误征兆出现后，要尽快查明，以限制错误的损害并降低排错的难度。◼负效应所设置的“接收判据”不可能与预期的正确结果完全吻合，导致错判或漏判；软件增加了冗余可能降低可

靠性被动式错误检测的实施方法◼看门狗定时器当出现潜在不安全的系统状态或有可能转移到这种状态时，将系统转移到规定的安全状态。◼循环等待次数控制◼配合硬件进行处理的设计如：电源失效、电磁干扰、系统不稳定、接口故障、干扰

信号，以及错误操作等。◼按照已知的数据极限检查数据；◼按照变量间恒定关系检验；◼检查所有多值数据的有效性；◼对冗余的输入数据进行一致性检验；◼……看门狗的设计看门狗技术是控制运行时间的一种有效方法。看门狗实际上是一种计时装置

，当计时启动后看门狗在累计时间，当累计时间到了规定值时触发到时中断（即狗叫），看门狗在不需要时可以关闭。看门狗的设计要首先明确其目的性。如：(1)要防某段程序可能的死循环，则在此段程序前启动狗，在此段程

序后关闭狗，在狗叫中断中进行超时异常处理。(2)要防外来的信息长时间不来，则在开始等外来信息时启动狗，在接收到外来信息时关闭狗，在狗叫中断中进行超时异常处理。(3)要防计算超时，则在开始计算时启动狗，在计算完毕后关闭狗，在狗叫中断中进行超时异常处理。显然，不可能要求一个狗

可以看管好所有的超时情况。避免潜在的死循环在等待外部信号的程序段中，不允许无限制地等待。正确的做法应是，或采用循环等待次数控制，或使用定时器，使得规定时间内（无论成功或失败）必须保证退出等待外部信号的程序段。不允许的设计方法建议

采用的设计方法注意通过双口RAM进行握手通过双口RAM进行信息交换是设计师经常采用的一种设计方案。的确双口RAM提供了信息交换双方的方便读写，但仅靠双口RAM要做到读写的时序要求就要格外小心。如此的设计是要避免的

：通过双口RAM交换信息，在双口RAM中设置了握手信号单元。读方检查到握手信号为01H，表明对方已准备好数据，再读数据，读完后将握手信号置为00H；写方检查到握手信号为00H，表明对方已取走数据，再写数

据，写完数据后再将握手信号置为01H，表明自己已准备好数据。这种设计不一定可靠，可能会出现写方要写握手信号时，读方正在读握手信号，则写方要写的值写不进去。可靠的设计应用硬件连线保证握手，而不要靠双口RAM中的握手信号。如果一定要靠双口RAM进行握手，则写握手信号单元数据时

一定要写完后接着再读出，经验证确实写成功后再进行下面的操作，否则需继续写。当然这必须与避免潜在的死循环的设计准则联合使用。可靠的设计方法握手标志置写不上的可能数据采集的多路冗余设计关键数据的采集可采用多路冗余设计，即可以从多个通

讯口对同一数据进行采集，通过表决进行有效数据的裁决。通常多采用奇数路的冗余设计，如3路、5路等。(1)开关量的裁决可采用多数票的裁决，如3取2、5取3等。(2)模拟量的裁决可采用中间数平均值的裁决，如3路数的中间值、5路数去掉最大最小值后的平均值等。主动式错误检测◼主动式错误检测对ROM中

的代码进行和检验（sumcheck）；检测RAM，以保证正确的操作用数码；检测内存的正确性，以确保正确操作；对关键及重要的函数功能及逻辑功能进行典型校核。……据统计，将硬件看门狗定时器及主动检测相结合，一般可检测出98％的故障。◼主动式错误检测可作为周期性任务来安排，

也可作为一个低优先级的任务来执行。故障恢复措施◼完全恢复（依靠冗余备份）◼降级恢复（只提供重要的功能）◼立即停止程序运行（安全停机）◼记载错误将发生错误时的状态记录在一个外部文件上，然后让系统恢复运行，再由维护人员对记录进行深入的分析研究。软件改

错设计◼改错设计是指在设计中，赋予程序自我改正错误、减少错误危害程度的能力的一种设计方法。◼改正错误的前提是已经准确地找出软件错误的起因和部位（故障检测与故障定位合称故障诊断），程序又有能力修改、剔除有错误的语句。◼现阶段仅限于减少软件错误造成的有害影响，或将有害影响限制在一个

较小的范围。常采用故障隔离技术。◼现阶段没有人的参与几乎不可能故障隔离◼权限最小化原则是实现故障隔离的主要思想。◼为了限制故障的蔓延，要求对过程和数据加以严格的定义和限制。◼例如，针对操作系统的故障隔离方法：不允许一个

用户的应用程序引用或修改其它用户的应用程序或数据；绝对不允许一个应用程序引用或修改操作系统的编码或操作系统内部的数据；保护应用程序及其数据，使其不致由于操作系统的错误而引起程序和数据的偶然变更；应用程序绝对不能终止系统工作、不能诱发操作系

统去改变其它的应用程序或数据；……软件容错设计◼软件容错设计是指在设计中赋予程序某种特殊的功能，使程序在错误已被触发的情况下，系统仍然具有正常运行能力的一种设计方法。时间容错结构容错信息容错时间容错◼所谓“时间容错”就是不惜以牺牲时间为

代价来换取软件系统高可靠性的一种手段，它包括指令的重复执行和程序(一个模块或一个子程序)重复执行，两种常被采用而行之有效的方法指令重复执行是当应用软件系统检查出正在执行的指令出错误后，让当前指令重复执行n

次(n>=3)，若故障是瞬时性的干扰，在指令重复执行时间内，故障有可能不再复现，这时程序就可以继续往前执行下去。这时指令执行时间比正常时大n倍程序(一个模块或一个子程序)重复执行是当应用软件系统检查出正在执行的程序出错误后，中断当前正在运行的软件，反复调用n次(n>=3)

运行出错的程序(一个模块或一个子程序)。在反复调用过程中若故障不再复现，这时程序继续从中断的地址往前执行。这时所需的运行时间比重复执行n条指令的时间要大得多◼对于复执不成功的情况，通常的处理办法是发出中断，转入错误处理程

序，或对程序进行复算，或重新组合系统，或放弃程序处理。结构容错◼结构容错的基本思想来源于硬件可靠性中的冗余技术。静态冗余N版本程序设计法（NVP）动态冗余恢复块法(RB)Q:使用多个完全相同的软件能够实现容错吗软件N

版本程序设计◼美加州大学Avizienis和L.Chen提出◼基本思想对相同的要求进行多个不同版本的设计对相同的初始条件和相同的输入的操作结果实行表决（多数决定、一致决定）◼针对的错误来源：设计人员对需求说明理解不正确、不完全导致的缺陷◼

要求需求说明完全、精确NVP的基本结构P1P2P3PN表决器输入版本N版本1“正确”输出告警冗余软件的设计原则◼相异性是指对实现同一功能的多版本产品，在制作时为防止出现共因故障而有意识地使之产生某种差异的性质；◼冗余版本之间相互屏蔽故障不能完全依靠背靠背编程（随机相异）；◼应有意识地实行相异

化编程（强制相异）：相互独立的不同人员不同的算法不同的编程语言不同的编译程序不同的设计工具、测试方法……恢复块法M1A1A2M2A3M3MNAN接收测试失效基本块替换块接收测试N告警输入接收测试1“正确”输出成功“正确”输出恢复块法◼恢复块法适合只有一台计算机的情况；◼允许只对较为复杂

、容易出故障的程序段进行冗余；◼基本块与替换块的设计应尽可能相异；◼接收测试的作用非常重要，应能检测程序执行结果与预期结果的偏离，或检测和防止能触发安全事故的输出：需求检查法帐目检查法合理性检查法计算机运行时检查法信息容错（检错及纠错）◼一般非关键信息可以使用奇偶校验码。◼关键、重要信息

与其它信息之间应保持一定的Hamming距离，不会因一位或两位差错而引起系统故障。例如不能用01表示一级点火，10表示二级点火，11表示三级点火。◼如安全关键信息有差错，应能检测出来，并返回到规定的状态（例如安全状态）

。如循环码◼安全关键信息的决策判断不得依赖于全“1”或全“0”的输入（尤其是从外部传感器传来的信息）。软件可靠性分析的作用◼发现设计缺陷◼指导软件设计◼指导软件测试软件可靠性分析方法◼软件失效模式和影响分析（SFMEA）◼软件故障树分析（SFTA）◼软件Petri网分析法◼软件潜

藏分析法(SSCA)SFMEA概述◼软件失效模式和影响分析（SFMEA）是在软件开发阶段的早期，通过识别软件失效模式，分析造成的后果，研究分析各种失效模式产生的原因，寻找消除和减少其有害后果的方法，以尽早发现

潜在的问题，并采取相应的措施，从而提高软件的可靠性和安全性。◼是一种评估方式而不是解决手段。SFMEA的基本概念◼软件失效就是泛指程序在运行中丧失了全部或部分功能、出现偏离预期的正常状态的事件。软件失效是由软件的缺陷引起的。◼软件失效模式指软件失效的表现形式，即软件失效

发生的方式，有时也被描述为对设备运行产生的影响。在IEEE软件异常分类标准中给出了软件失效模式的分类，在进行SFMEA分析时可作为参考。◼软件失效影响是指软件失效模式对软件系统的运行、功能或状态等造成的后果。IEEE软件异常分类软件异常类型具体软件异常操作系统失败——程序挂起——程序失败程序不

能启动程序运行不能终止程序不能退出输出问题错误的格式不正确的结果、数据不完全或遗漏拼写问题、语法问题美化问题未达到性能要求不能满足用户对运行时间的要求不能满足用户对数据处理量的要求多用户系统不能满足用户数的要

求整个产品失效——系统错误信息——其它程序运行改变了系统配置参数程序运行改变了其它程序的数据其它◼软件错误(error)：在软件生存期内的不希望或不可接受的人为错误。◼其结果是导致软件缺陷的产生。◼软件错误是一种人为过程，相对于软件本身，是一种外部行为。软件缺陷(defect)：是存

在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。有时又称“softwarebug”。◼软件故障(fault)：是指软件运行过程中出现的一种不希望

或不可接受的内部状态。◼此时若无适当措施（容错）加以及时处理，便产生软件失效。◼是一种动态行为。软件失效(failure)：是指软件运行时产生的一种不希望或不可接受的外部行为结果。SFMEA分析的一般步骤◼SFMEA的分析对象可以是开发早期阶段的高层次的子系统、部

件，也可以是详细设计阶段的单元、模块。◼对于不同的分析对象，其软件失效模式是不同的，采用的SFMEA分析方法也不同，前者采用系统级分析方法（systemFMEA），后者为详细级分析方法（detailedFMEA）。系统FMEA分析的一般步骤◼1）系统定

义◼2）软件失效模式分析◼3）软件失效原因分析◼4）软件失效影响分析◼5）改进措施分析1）系统定义◼在系统定义中应说明系统的主要功能和次要功能、用途、系统的约束条件和失效判据等。系统定义还应包括系统工作的各种模式的说明、

系统的环境条件，以及软、硬件配置。◼进行结构分解，就是将软件按照一定的分解原则划分为若干逻辑部分，以确定系统的分析级别，以及最小分析单元。结构分解的原则可基于软件系统的功能、结构特征或工作模式等，应根据软件的具体情况确定◼2）软件失效模式

分析针对每个最小分析单元，确定其潜在的失效模式，例如软件无响应或者返回错误的值等。◼3）软件失效原因分析针对每个软件失效模式分析其所有可能的原因。软件的失效原因往往是软件开发过程中形成的各类缺陷所引起的。软件失效原因◼逻辑遗漏或执行错误◼算法的编码错误

◼软硬件接口故障◼数据操作错误◼数据错误或丢失具体失效原因—逻辑遗漏或执行错误◼遗忘细节或步骤◼逻辑重复◼忽略极限条件◼需求的错误表述◼未进行条件测试◼检查错误变量◼循环错误具体失效原因—算法编码错误◼等式不完整或不正

确◼丢失运算结果◼操作数错误◼操作错误◼括号使用错误◼精度损失◼舍入和舍去错误◼混合类型◼标记习惯不正确具体失效原因—软硬件接口错误◼I/O时序错误◼时序错误导致数据丢失◼子函数调用不当◼子函数调用位置错误◼调用不存在的子函数◼子函数不一致具体失

效原因—数据操作错误◼数据初始化错误◼数据存取错误◼标志或索引设置不当◼数据打包解包错误◼变量参考错误数据◼数据越界◼变量缩放比率或单位不正确◼变量维度不正确◼变量类型错误◼变量下标错误◼数据范围不对具体失效原因—数据错误或丢失◼传感器数据

错误或丢失◼操作数据错误或丢失◼嵌入到表中的数据错误或丢失◼外部数据错误或丢失◼输出数据错误或丢失◼输入数据错误或丢失4）软件失效影响分析◼针对每个失效模式分析其造成的影响，一般可分为局部影响、上一层次影响和最终影响

三级，并分析失效所造成影响的严重性。失效影响严重性分类严重性类别严重性定义致命/非常严重引起人员死亡，系统报废，或对周围环境造成灾难性破坏严重引起人员严重伤害，系统严重损坏，任务失败，或环境严重破坏一般引起人员轻度伤害，系

统轻度损坏，导致任务延误或降级，环境受影响轻微不导致人员伤害，不影响任务完成，不影响环境，但使用的方便性或舒适性降低5）改进措施分析◼根据每个失效模式的原因、影响及严重性等级，综合提出有针对性的改进措施。SFMEA工作表格编号单元功能失效模式可能的失效原因失效影响

严重性改进措施单元子系统系统1.1输出输出数据提交用户显示数值高于正常范围逻辑问题计算问题数据操作问题N/A无任务降级一般…1.2数值低于正常范围逻辑问题计算问题数据操作问题N/A无任务降级一般…1.3输出数据没有显示逻辑问题接口或时

序问题N/A无任务中止严重…1.xxxxxxx…SFMEA实例（1/5）◼某舰载防御武器型号的转塔控制与伺服软件的并行通讯软件采取主从双机8255通讯（固定字节长度）的方式。其中控制计算机为主计算机（A），伺服计算机为从计

算机（B）。主从双机之间的通讯协议如下：先由A向B发送N字节，待B接收完N字节后，B再向A发送M字节；SFMEA实例（2/5）A发送的第一字节为HeadA，HeadA为控制机命令标识，A发送的第N

字节为TailA，TailA为控制机校验标识。B发送的第一字节为HeadB，HeadB为从属机接收状况回应标识，B发送的第M字节为TailB，TailB为从属机校验标识；A发送过程的容忍时间为TSA，A接收

过程的容忍时间为TTA，B发送过程的容忍时间为TSB，B接收过程的容忍时间为TTB；A进入通讯子程序后，先发中断，B响应中断后进入通讯子程序准备接收A的数据；采用8255，实现能判别是否对方已提供字节数据，能判别对方是否已取走字节数据。SFMEA实例（3

/5）主计算机A从计算机B①N个字节HeadA···TailA②M个字节HeadB···TailB发送容忍时间TSA接收容忍时间TTA发送容忍时间TSB接收容忍时间TTB某并行通讯系统SFMEA实例（4/5）A的失效模式｛通讯时间异常｛通讯数据异常✓无法按时进入通讯中断✓规

定的时间不能完成接收，即TT>TTA✓规定的时间不能完成发送，即TS>TSA✓HeadA错✓TailA错✓中间字节错SFMEA实例（5/5）编号失效模式失效影响严重性措施1A由于其它中断或其它原因，无法按时进入通讯中断。导致通讯无法进行。非常严重由A的通讯外程序采取措施保证按时

进入通讯子程序。2A的通讯程序在规定的时间内未能完成发送/接收。通讯周期将被打乱，通讯混乱。非常严重在A中设置定时器，或通过计数控制，以保证规定时间内返回。3A发送头字节HeadA由于外干扰出现错误。B执行错误的命令。严重B接收A的头字节后，判别头字节的合法性。4…………

………5A发中断后，由于外干扰，B没能响应中断。B无法进入通讯程序，因此无法接收A发送的数据。严重在A中设置定时器，当在允许的时间后仍无B的响应信息，放弃此帧通讯。SFMEA的优缺点◼优点：突出需要更改的部分分析

底层故障如何在整个系统中逐级向上传播分析应在何处采取容错、故障检测和运行监控等设计手段识别将导致系统崩溃的单点故障可以按照对设备和人员影响的严重程度对软件失效严重性进行分级◼局限性：不能识别人为错误造成的潜在失效

作为一个工具尚未广泛的应用于对软件错误的评估用于分析路径十分复杂或相互交联的软件时，SFMEA是一项繁琐、劳动强度高的工作软件故障树分析（SFTA）◼软件故障树分析（SFTA）是一种自顶向下的软件可靠性分析方法，即从软件系统不希望发生的事件（顶事件），特别是对人员和设备的

安全及可靠性产生重大影响的事件开始，向下逐步追查导致顶事件发生的原因，直至基本事件（底事件），从而确定软件故障原因的各种可能组合方式和（或）发生概率。SFTA步骤◼软件故障树的建立◼软件故障树的定性分析◼软件故障树的定量分析软件故障树的建立◼建立软件故障树通

常采用演绎法:首先选择要分析的顶事件（即不希望发生的故障事件）作为故障树的“根”；然后分析导致顶事件发生的直接原因（包括所有事件或条件），并用适当的逻辑门与顶事件相连，作为故障树的“节”；按照这个方法逐步深入，一直追溯到导致

顶事件发生的全部原因（底层的基本事件）为止。这些底层的基本事件称为底事件，构成故障树的“叶”。故障树符号(部分)与门：只有所有输入事件都发生时才能导致输出事件发生。OutABOutAB或门：输入事件中至少有一个发生时，就能导致输出事件发生。顶事件或中间事件：表示需进一步分析的事件。顶事

件是不希望发生的系统不可靠或不安全事件。中间事件是故障树中除底事件和顶事件之外的所有事件。X1W1基本事件：即底事件，对于故障树中的基本事件不必作更深入的分析未展开事件：由于发生概率较小，或由于信息不足，不能作更深层的分析的事件。InOut入三角形：表示树的部分分支在另外地方绘制，用以简化故障树；

出三角形：表示该树是在另外部分绘制的一颗故障树的子树，用以简化故障树。ATM系统硬件部分软件部分ATM操作系统ATM操作系统备份取款操作层数据库密码核对模块取款操作模块故障树分析示例ATM系统结构ATM软件系统故障数据记录错误数据录入错误数据更改错误未取得指定数额未取得Money取得

所剩余额指定金额<=余额编码错误指定金额>余额逻辑错误取款操作错误输入密码正确取款数额错误退出或过多询问未询问询问过多输入密码不对初始Chioce<0输入密码不对初始Chioce过大SFMEA与SFTA的区别与联系SFMEASFTA

区别分析方法由系统的最低分析层次，分析潜在的失效模式及原因，自底向上分析对系统产生的影响，即由因到果。是一种自顶向下的分析方法，从系统不希望发生的事件（顶事件）开始，向下逐步追查导致顶事件发生的原因，直到基本事件（底事件），即由果到

因。分析级别SFMEA分析的最低级别可以是实现一定功能的模块。最低分析级别可以是程序的语句。分析对象SFMEA用于分析系统和子系统所有可能的失效模式和原因。SFTA只分析顶层的故障事件。联系将SFMEA和SF

TA相综合，是一种有效的软件可靠性分析方法。小结◼软件可靠性设计和分析是软件可靠性工程的重要内容；◼软件可靠性设计包括避错设计、查错设计、改错设计和容错设计；◼软件可靠性分析包括软件失效模式和影响分析、软件故障树分析、软件Petri网

分析和软件潜藏分析。（7）嵌入式和实时软件设计◼嵌入式系统是计算机软件与硬件的综合体，通常具有专用的功能，并作为某个设备或机器的组成部分，用来控制、监测、辅助其运作。◼按照IEEE（美国电气和电子工程师协会，InstituteofElectri

calandElectronicsEngineers）的定义，嵌入式系统是作为某个更大规模系统组成部分之一的计算机系统，按照其所属系统的某些要求来进行执行。◼嵌入式系统已经普遍应用在与人类生活密切相关的各种

电子产品、电器中，并在航空、汽车等领域的控制系统中起到关键作用。嵌入式软件的特征◼嵌入式软件一般用于单一任务。◼嵌入式软件有多种类型的处理器体系结构支持。◼嵌入式软件的资源约束更加严格。◼嵌入式软件需要更高的可靠性和安全性。◼嵌入式软件对反应性和实时性要求很高。◼嵌入式软件通常固化存储

。嵌入式系统的设计过程阶段一：产品定义阶段二：软硬件划分阶段三：软件设计与硬件设计阶段四：软硬件集成阶段五：产品测试与发布阶段六：维护与升级软件设计过程硬件设计过程嵌入式系统中的一般软件结构嵌入式系统在启动后将

会一直运行下去，除非被关闭电源或消耗完能量，一般运行在特殊的硬件平台上，对系统的各种物理部件进行监控或响应外部激励，软硬件结合的非常紧密。无操作系统的嵌入式软件设计◼前后台系统前台：中断服务程序处理异步事件，前台也称为中断级。后台：

应用程序无限循环，在主程序中被调用，后台也称为任务级。◼中断（事件）驱动系统◼巡回服务系统◼基于定时器的巡回服务系统有操作系统的嵌入式软件设计◼有操作系统的嵌入式软件分为分时系统和实时系统◼分时系统：使用定时器调度任务的运行，按时间片均匀的分配给每个任务。◼实时系统：把系统处理的事件根据轻

重缓急进行分类，并赋予优先级。非抢占式系统抢占式系统内容3.1软件设计的基本概念3.2软件设计过程3.3软件设计的质量3.4软件体系结构设计3.5高可信软件设计3.6软件设计规格说明3.7软件设计评审软件设计规格说明◼软件设计过程中的各个活动的结果最终应该文档

化，形成正式的软件设计规格说明，作为软件设计的输出。形成的软件设计规格说明将被评审，并作为后续软件实现活动的依据。◼软件设计规格说明并没有统一的格式，例如IEEE标准、ISO标准以及我国的国家标准、各行业标准所建议的格

式都不尽相同。◼使用不同的软件设计方法学所得到的设计模型也会有很大区别，导致设计规格说明的结构也会明显不同。内容3.1软件设计的基本概念3.2软件设计过程3.3软件设计的质量3.4软件体系结构设计3.5高可

信软件设计3.6软件设计规格说明3.7软件设计评审设计评审◼设计评审的目标是，确保设计规格说明书能够实现所有的软件需求，及早发现设计中的缺陷和错误，并确保设计模型已经精化到合格的软件实现工程师能够构造出符合软件设计者期望的目标软件系统。◼评审分正

式与非正式两种方式。正式评审由软件开发人员、用户代表、领域专家参加，通常通过答辩形式，设计人员对设计方案详细说明后，答复与会者的问题并记下各种重要的评审意见。非正式评审有同行切磋的性质，不拘时间，不拘形式。设计评审关注的内容◼设计模型是否能够充分地、无遗漏地支持所有软件需求

的实现；◼设计模型是否已经精化至合理的程度，可以确保合格的软件实现工程师能够构造出符合软件设计者期望的目标软件系统；◼设计模型的质量属性，即设计模型是否已经经过充分的优化，以确保依照设计模型构造出来的目标软件产品

能够表现出良好的软件质量属性。设计评审的原则◼对产品进行评审，而不是开发人员。◼要有针对性，不要漫无目的。◼进行有限的争辩。◼阐明问题所在，但不要试图去解决问题。◼要求事先准备，如果评审人没有准备好，则取消会议并重新安排时间。◼为被评审的产品开发一个

检查表。◼确定软件元素是否遵循其规格说明或标准，记录任何不一致的地方。◼列出发现的问题、给出的建议和解决该问题的负责人。◼坚持记录并进行文档化。本章完第4章面向对象的软件设计方法337内容4.1基于UML的分析与设计过程4.2用例分析与设计4.3概念模型和顶层架构设计4.4用户界

面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计引言◼面向对象开发方法的核心是利用面向对象的概念和方法对软件需求分析和设计，建立面向对象的软件分析和设计模型。◼面向对象软件开发过程从领域概念到设计概念和代码实现都

以类和对象为核心，是一个逐步精化的过程，因此需求分析和设计之间并没有严格的分界线。◼本章使用UML进行软件分析和设计。（1）抽象与逐步求精4.1基于UML的分析与设计◼UML是独立于软件开发过程的，它几乎可以用于任何类型的

软件开发过程，包括瀑布式、迭代式、螺旋式等不同模型。◼在软件分析和设计中，可以根据项目的特征、开发组织在已有实践中定义的相关规范、设计人员本身的偏好等因素，对基于UML的软件设计过程进行定制。◼根据UML各

种视图的特点，它们可能更适用于软件分析与设计的某些活动，形成了一些常用的设计方式与过程，起到一定的指导作用，但并没有强制性要求。基于UML的分析与设计过程用例分析与设计概念模型与顶层架构设计用户界面设计数据模型设计设计精化

类设计部署模型设计UML设计模型用例图交互图活动图类图包图构件图类图包图状态图类图对象图类图状态图活动图构件图部署图类图包图交互图使用UML的软件分析和设计的较为通用的过程，实践中开发人员可以此过程为基础进行改进和订制。内容4.1基于UML的分析与设计过程4.2

用例分析与设计4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计4.2用例分析与设计◼案例：银行ATM自动柜员机的需求简述（本案例将要开发的ATM系统能够为顾客提供以下基

本服务，它们统一称为交易）：取款服务。顾客可以用银行卡从对应的账户中支取现金，现金必须是100元的整数倍，且每次取款不能超过2000元。存款服务。顾客可以把现金存入与银行卡对应的账户中。转帐服务。顾客可以把一个银行卡对应

的账户中的款项转帐到另一个银行账户中。查询服务。顾客能够查询一个银行卡对应的账户中的余额。（1）确定用例◼采用用例模型描述系统需求时，首先需要开发人员从业务需求描述出发获取参与者（Actor）和场景，对场景进行汇总、分类、抽象，

形成用例。◼场景是从单个参与者的角度观察目标软件系统的功能和外部行为，这种功能通过系统与用户之间的交互来表示。◼场景是用例的实例，而用例是某类场景的共同抽象。确定参与者和场景——对多个场景进行抽象——用例获取场景◼以下问题可以帮助分析人员获取场景：目标软件系统有哪些参与者？参与者希望系统执行的

任务有哪些？参与者希望获得哪些信息？这些信息由谁生成？由谁修改？参与者需要通知系统哪些事件？系统响应这些事件时会表现出哪些外部行为？系统将通告参与者哪些事件？确定参与者和场景的关键在于理解业务领域和初步需求描述文档。定义用例◼在场景确定之后，通过

对场景的汇总、分类归并、抽象即可形成用例。◼需要特别注意的是，参与者并只限于人员，其它与目标软件发生交互的外部实体或系统也是参与者；用例应该是对参与者可见的系统需求或功能，否则不能作为用例。◼如果多个外部实体在与目标软件系统进行交互时扮演同一角色，这些实体用同一参与者表示；如果一

个外部实体扮演多个角色，则需要多个参与者来表示同一实体，即参与者与角色一一对应。ATM案例的参与者◼“顾客”（Customer）◼“操作管理人员”（Operator）◼“银行服务器”（BankSystem）◼“读卡器”（CardReader）◼“存款器”（Ca

shAcceptor）◼“取款器”（CashDispenser）◼“打印机”（Printer）参与者：与系统交互的人、设备、其他系统ATM案例的用例◼“取款”（Withdrawal）◼“存款”（Deposit）◼“转帐”（Transfer）◼“查询余额”（Inquiry

）◼“开机”（SystemStartup）◼“关机”（SystemShutdown）用例：系统的功能（2）生成用例图◼确定参与者与用例之后，建立用例图，描述参与者与用例、用例之间的关系。◼生成用例图是一个逐步精化的过程，首先可以建立初步的用例图，包括前面发现的参与者和用例；◼然后对用例图进行细化，

定义用例之间“包含”、“扩展”、“继承”等关系，并可能需要定义新的用例，以能够更准确地使用用例图描述系统需求。生成初步用例图WithdrawalSystemStartupSystemshutdownDepo

sitInquiryATMTransferCustomerOperatorBankSystemCardReaderCashDispenserCashAcceptorPrinter用例图的细化◼包含（include）关系◼扩展（extend）关系◼继承关系细化后ATM用例图InvalidPIN

Transaction<<include>><<extend>>DepositSystemStartupSystemshutdownWithdrawalInquiryATMTransferCustomerOperatorB

ankSystemSessionCardReaderCashAcceptorCashDispenserPrinter（3）用例描述◼从外部视角看，一个用例是参与者与目标软件之间的一次交互过程；从系统内部视

角看，一个用例是系统执行的一系列动作，动作执行的结果能被外部的参与者觉察。◼对用例的完整描述包括用例名称、参与者、前置条件、一个主事件流、0到多个辅事件流、后置条件。主事件流表示正常情况下参与者与系统之间的信

息交互及动作序列，辅事件流则表示特殊情况或异常情况下的信息交互及动作序列。“取款用例”描述◼用例名称：Withdrawal◼参与者：Customer，BankSystem，CardReader，CashDispenser，Printer◼前置条

件：顾客已插入银行卡，密码验证正确，顾客按下“取款”按钮◼主事件流：1.顾客输入取款金额，并确认。2.系统认可取款金额，并发送指令给取款器。3.取款器把相应金额的现金送出。4.打印机打印回执。◼辅事件流：1.如果取款金额不是100的整数倍，则显示信息“输入金额必须是100的整

数倍，请重新输入”，并返回主事件流中步骤（1）。2.如果取款金额超过2000元，则显示信息“输入金额不能超过2000元，请重新输入”，并返回主事件流中步骤（1）。3.如果账户余额小于取款金额，则显示信息

“账户余额不足，请重新输入”，并返回主事件流中步骤（1）。4.顾客在确认取款金额前可以选择取消交易。◼后置条件：如果取款成功，系统从账户余额中减去相应数额，并返回等待状态；如果顾客取消交易，则返回等待状态。“取款用例”描述◼用例名称：Withdrawal◼参与者：Customer，BankSyst

em，CardReader，CashDispenser，Printer◼前置条件：顾客已插入银行卡，密码验证正确，顾客按下“取款”按钮◼后置条件：如果取款成功，系统从账户余额中减去相应数额，并返回等待状态；如果顾客取消交易，则返回等待状态。顺序图描述用例sdStartup:OperatorPan

el:ATM:CashDispenser:NetworktoBankSwitchOn()PerformStartup()getInitialCash()InitialCash()setInitialCash()

openConnection()交互图与用例模型之间的对应关系：对于动作绪论比较简单的用例，一个交互图对应一个用例；对于比较复杂的用例，可能对应多个交互图，每个交互图表示一个相对简单的子动作序列。图4-5、4-6、4-7请自行分析内容4.1基于UML的分析与设计过程4.2用例分

析与设计4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计（1）概念模型设计◼概念模型针对问题领域中的对象进行描述，顶层架构依据概念模型进行设计。◼在用户需求和相关的业务领域中，往往有一些全局性的概念对于理解需求至关重要，因此，有必要

抽取这些概念，研究这些概念之间的关系。◼UML类图非常适合用来建立领域概念模型，描述在问题域中存在哪些主要概念和对象，并表示出它们之间的关系，例如关联、聚集、继承等。关键概念◼为建立以UML类图表示的领域概念模型，首先

必须标识关键概念。关键概念的来源包括：（1）业务需求描述、用例说明；（2）业务领域中的相关规范、标准、术语定义。（3）反映业务领域知识的既往经验。分析类◼描述概念模型的UML类图主要由分析类组成。◼分析类是指直接

服务于用户功能性需求的概念层面的类，它们与待开发软件系统的具体实现技术无关。◼概念层UML类图也可以称为分析类图。三种分析类◼边界类。负责目标软件系统与参与者之间的交互，构造型为<<boundary>>。◼控制类。作为完成用例任务的责任承担者，负责协调、控制其它类共同完成用例规定的功

能或行为。构造型为<<control>>。◼实体类。负责保存目标软件系统中具有持久意义的信息项并向其它类提供读、写信息项内容的必要操作接口，一般不涉及业务逻辑处理。构造型为<<entity>>。图4-8ATM系统的概念模型——分

析类图（2）顶层架构设计◼顶层架构的主要目的是为后续的分析和设计活动建立一种结构和划分，以便开发人员在不同的开发阶段，以及同一开发阶段的不同开发人员，能够聚焦于系统的不同部分。◼顶层架构是分析和设计的阶段成果的承载体。◼随着开发过程的

推进，框架中的内容不断丰富、翔实，最终演进为完整的面向对象软件结构。顶层架构设计◼顶层架构的设计可以把体系结构设计方法与概念模型得到的结果结合起来考虑，利用一定的体系结构模式（例如分层模式、模型－视图－控制器MVC模

式等）对概念模型中的相关元素进行组织，同时需要考虑目标软件系统与其它作为参与者的外部系统之间的联系和交互方式。◼UML包图非常适合于表示软件顶层架构，可以从某种视角将具有比较密切的关联的一些类划分为一个包，分属不同包的两个类之间的关联则比较松散。图4-9层次结构组织的ATM系统的顶

层架构内容4.1基于UML的分析与设计过程4.2用例分析与设计4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计用户界面设计的内容◼用户界面是对于用户的直接表现，直接影响到用户对软件易用性、友好性的感觉。用户界面包含两方面内容：首

先要完整地包括用户在使用软件过程中所需的各种元素，例如窗口、菜单、按钮、输入文本框、选择列表、提示信息等，缺乏这些元素中的某些将会导致软件功能无法被用户正常完成；其次要求具有良好的外观和布局，例如背景颜色、按钮等元素的位置、选择列表中条目的顺序等，这些因素

的不足可能不会影响软件功能的正确使用，但会给用户带来不便、迷惑甚至反感。本节关注第一方面的内容用户界面的层次和结构◼用户界面元素分为两个层次：屏幕:用构造型<<screen>>表示窗口：屏幕上的组成部分（文本框、按钮等）统一称为窗口。用构造型<<win

dow>>表示◼用户界面的结构可以由UML类图描述，屏幕和窗口用类进行表示，并给出它们之间的关系。◼屏幕之间的切换过程可以用UML状态图表示。每个状态表示当时所处的屏幕，迁移表示用户激励。◼当屏幕中有许多窗口时，可以对窗口划分层次，一些简单的窗口可以作为复杂窗口的属性和操作。屏幕结构类图<<s

creen>>InputCustomerInfo<<window>>PromptInfo1-RightBottom1<<window>>FunctionsOptions+NewProducts()+ProductQuery()+UpdateCustomerInfo()+OrderManag

e()1-Left1<<window>>CustomerInfo+Submit()+setEmpty()+Name+Age+Profession+Phone+Address1-RightTop1屏幕变化状态图WelcomeSecuri

tyPromptInputPINTransactionSelection插入银行卡继续输入密码，确认，并且密码正确取消PromptCardKept三次密码输入不正确输入密码，确认，密码不正确且未达三次“插卡”过程的屏幕转换状态图：每个状态表示一个屏幕，迁移表示当前屏幕用户的激励。屏幕结

构类图InputPin屏幕的结构图。每个屏幕的结构可以用类图设计，即屏幕上有什么（窗口），如：文本框、按钮等屏幕结构包图CustomerConsoleUserInterfaceCardInsertedUserInterfaceWithdrawalUserInterfa

ceDepositUserInterfaceTransferUserInterfaceInquiryUserInterface顾客控制台包含丰富的元素，可以进一步细化形成一个对应的包，专门描述界面元素其中有分为5个子包，分别对应

“插卡”、“取款”、“存款”、“转账”、“查询”5个独立的过程。每个子包又对应一些列的屏幕，并对应到表示屏幕切换的状态图用户界面设计◼一个独立的过程包含若干屏幕变换◼状态图表示屏幕间的变换◼状态图的一个状态表示一个屏幕◼一个屏幕的结构用屏幕

结构（类）图表示内容4.1基于UML的分析与设计过程4.2用例分析与设计4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计数据模型设计◼数据模型设计包括数据结构设计、数据库设计、数据文件设计等，本节主要关注持久

数据存储设计。持久数据模型设计步骤为：（1）确定设计模型中需要持久保存的类的对象及其属性，其中实体类是主要关注对象。（2）确定持久存储的数据之间的组织方式。（3）确定数据模型中的操作行为，例如数据完整性验证、数据读取、存储与更新、数据求和、求数据平均值等。（3）进一步优化持久数

据操作的性能，如使用数据索引、存储过程、触发器等方式。数据模型设计的输出制品是数据模型，包括以UML类图表示的数据库表格以及它们之间的关系。数据模型必须满足设计模型对持久数据存储的要求。关系数据库建模◼类对应于关系数据模型中的表格（table），对象对应于记录（r

ecord），属性对应于表格中的字段（field）或者列（column），类中的方法实现可以用SQL语句对数据库表格进行操作。<<table>>T_Customer<<table>>T_Order<<key>>-C

ustomerID-CustomerName...<<key>>-OrderID<<foreignkey>>-CustomerID...1*<<table>>表示表格，<<key>>表示关键字，<<>f

oreignkey>表示外键数据模型<<entity>>Receipt+TansactionName+CardNumber+Date+Time+Position<<entity>>WithdrawalReceipt+Wi

thdrawalAmount<<entity>>DepositReceipt+DepositAmount<<entity>>TransferReceipt+TransferAmount+ToAccount内容4.1基于UML的分析与设计过程4.2用例分析与设计

4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计4.6设计精化设计精化的任务：（1）精化软件架构（2）调整软件组成类（3）精化交互模型（4）精化类之间关系（1）精化软件架构

◼精化软件架构的主要目的是寻找一种理想的包划分方案，使得每个包中直接包含的类的数量规模适中，包的边界清晰、自然，并且包间的耦合度较低。◼随着分析和设计不断深入，原有包图中的包可能包含了过多的类，此时需要对其进行分拆。◼按照软件工程强内聚、松耦合的原则，这

种分拆应该具有某种自然划分的性质，并且尽可能降低划分以后的子包之间的耦合度。精化软件架构◼包间的耦合度主要取决于依赖关系，包间的依赖关系又取决于两个包中类之间的关系，包划分（拆分、移动、合并等）的有关原则：避免包间的循环依赖关系，即排除

包P1依赖于包P2、P2又依赖于P1的情形。在层次结构中，位于较低层次的通用包不应当依赖于较高层次中的专用包。在层次结构中，较高层次的包可以依赖于较低层次的包，但应尽量在相邻的层次间发生。如果针对某些子系统专门划分了接口包和实现包，那么，其它与该子系统相关的包只能依赖于接口包，

不能依赖于实现包。图4-17、4-18“用户交互层包、子包精化后的模型”（2）调整软件构成类◼对设计模型中的类进行调整和优化，以满足强内聚、低耦合、简单性、自然性等软件工程原则。调整和优化主要包括：（1）增加辅助类，例如实现通信、关键算

法的类（2）合并相互通信频繁的类（3）分拆规模过大的类（3）精化交互模型◼精化交互图时，消息名、对象交互的参数、返回值等均需要注明。需要考虑以下内容：（1）要考虑软件架构和组成类被调整之后对交互模型会产

生哪些影响，新出现的对象或拆分后的对象如何参与交互过程，在其中起到什么样的作用（2）对象在交互过程中的消息传递需要哪些参数和返回值。（3）交互过程是否需要细化，例如增加必要的消息，或对局部引用一个更加具体的交互图

。图4-20精化后的Withdrawal顺序图（4）精化类之间的关系◼研究类之间的连接关系：（1）根据这些连接的语义强度将它们精确地判定为UML的依赖、关联、聚合或构成关系之一；（2）确定连接的方向及参与连接的类对象之间的数量对应关系；（3）根据软件复用的要求

及软件结构简洁化、清晰化的要求，优化类之间的关系。精化类之间的关系◼对象obj1和obj2之间的消息传递机制：（1）引用全局对象（2）通过参数传递（3）引用局部对象（4）通过类的成员变量：暂时性连接，用依赖关系表示稳定性连接构成关系聚合/集关系关联关系（以上两种均不成立）精化

类之间的关系◼其他需要考虑的问题：（1）关联类（2）依赖、构成、聚合关系的方向：尽量将关联单向化，单向关系更简单，实现代价更小。（3）利用继承精化设计模型，引进新的父类捕获公共性。内容4.1基于UML的分析与设计过程4.2用例分析与设计4.3概念模型和顶层架构设计4.4用

户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计类设计◼类设计的任务是对各种设计模型中出现的类进行细化设计，以使它们精细至能够直接提交给软件构造阶段进行代码实现，类设计也是一种对设计的精化，类设计主要包括：（1）

对类的属性与操作进行精化。（2）对类的对象实例在其生命周期中对外部消息的响应和状态变化过程进行建模。（3）对类中重要操作的实现过程或算法进行描述。(1)关注单个类的内部细节的设计；(2)和(3)属于类的行为模型设计。（1）精化类的属性与操作◼

对于类的每项属性，在设计模型中，可以定义属性的名称、类型、初始值、取值范围及属性说明（后三项内容是可选的）。◼操作的基本内容包括名称、参数表（含参数的名称和类型）、返回类型、功能描述。◼如果操作比较复杂，还需

要用文字或UML活动图说明操作的实现算法。精化类的属性与操作◼属性和操作的作用范围：（1）public：对系统中所有类可见（2）protected：对本类及其子类可见（3）private：仅对本类可见确定属性和操作作用范围的原则：尽量缩小作用范围，每个类仅公

开那些直接响应消息所必需的操作。原则上属性不宜公开，如果确有必要让其他类读取或者设置该属性的值，应通过本类增加get/set函数实现。精化类的属性与操作◼类的操作主要来源于各种设计模型和方案中对类的职责的规定，针对每个类的特征，考虑是否需

要以下操作：（1）对象创建（2）对象删除（3）对象比较（4）对象复制精化类之间的关系在类中设置相应属性，实现类之间的关联、聚合、构成关系:a、类型为B的指针或引用b、集合类型，集合元素的类型为B的指针或引用c、类型为B的

指针或引用d、集合类型，集合元素的类型为BABa1：1的关联或聚合（非构成）关系b1：*的关联或聚合（非构成）关系c1：1的非构成）关系d1：*的构成关系（2）类的行为模型设计在两个层次上建模（1）针对整个类

使用UML状态图描述其行为。（2）针对类中某些重要的方法，用UML活动图描述其执行过程或步骤。对象具有一定的生存周期，在其活跃过程中可以响应外部的消息激励，执行相应的操作。对象生存期具有不同的状态，位于不同的状态可以响应不同的消息

，因此可以用状态图刻画对象的动态行为。只需针对具有明显的状态特征并具有比较复杂的“状态—事件—响应”的类设计状态图即可。状态图主要针对控制类，很少对实体类。图4-23、4-24状态图中的节点是状态对于某些执行

比较重要的任务且控制流程较为复杂的方法，可以使用活动图描述其执行过程图4-25活动图中的节点是动作内容4.1基于UML的分析与设计过程4.2用例分析与设计4.3概念模型和顶层架构设计4.4用户界面设计4.5数据模型设计4.6设计精化4.7类设计4.8部署模型设计部署模型设计◼部署模型设计

考虑如下内容：（1）最终开发完成的软件包括哪些制品形式；（2）软件运行环境存在哪些类型的物理节点；（3）不同节点之间的连接和通信形式是什么；（4）软件制品应该如何在物理节点上进行部署，即它们的部署映射关系。部署图对于复杂的分布

式软件系统非常有用，部署图还可以描述整个系统结构的一些特殊要求，例如系统的备份和容错结构设计ATM系统部署模型:ATM<<CDMA>><<TCP/IP>><<Artifact>>atm.exe<<applic

ation>>Wirelessencrpytion:ATM<<Artifact>>atm.exe:BankServer<<application>>BankSystem本章完第五章面向数据流的软件设计方法内容5.1数据

流图与数据字典5.2实体关系图5.3面向数据流的分析过程5.4面向数据流的设计过程5.5启发式设计策略397（1）数据流图398外部实体位于软件系统边界之外的信息产生者或信息接收者转换转换数据流的处理过程，又称为泡（

Bubble）数据流在转换之间有向流动的数据项或数据项集合数据源为一个或多个转换提供数据源或数据存储服务的缓冲区、文件或数据库数据流图的层次◼数据流图就是用来刻画数据流和转换的信息系统建模技术。◼它提供层次结构让分析人员能够方便地表示任意抽象级别

上的信息系统或其子部分，并支持问题分解、逐步求精的分析方法。◼初始时，整个信息处理系统可以用顶级（第０级）数据流图表示。◼在数据流方法中，对数据（数据流）的精化是伴随着对转换的精化而同步进行的。399顶级数据流图400外部实体软件系统外部实体外部实体外部实体输入数据流输入

数据流输出数据流输出数据流数据流图的精化◼在进行逐层精化的过程中，必须维持层间数据流图的平衡，即，被精化的转换的输入、输出流必须与精化它的数据流子图的初始输入流和最终输出流严格一致。◼要注意逐层精化必须适可而止，因为设计之前的分

析活动只求对问题的全面、清晰的理解，并不关心软件的设计细节。401（2）数据字典◼数据流图机制并不足以完整地描述软件需求，因为没有描述数据流的内容。◼数据流图必须与描述并组织数据条目的数据字典配套使用。◼数据条目的定义必须遵循

以下原则：精确、简洁，并且能为用户方和软件开发方共同理解。402数据字典的内容◼在数据流图中标识数据流、数据源或外部实体的名称与别名；◼数据类型；◼所有以它作为输入流或输出流的转换的列表；◼如何使用该数据条目的简要说明；◼数据条目的解释性说明；◼其它补充

说明，例如取值范围与缺省值，有关的设计约束等。403数据字典示例－电话号码《电话号码》∷＝《分机号》｜《外线号码》《分机号》∷＝3501｜3502｜……｜3599《外线号码》∷＝2＋（《市话号码》｜《长话号码》）《长话号码》∷＝０＋（《区号》＋《市话号码》）《区号》∷＝任何

长度为2或3的数字串《市话号码》∷＝《局号》＋《分局号》《局号》∷＝455｜448｜888｜552《分局号》∷=任何长度为4的数字串404内容5.1数据流图与数据字典5.2实体关系图5.3面向数据流的分析过程5.4面向数据流的设计过程5

.5启发式设计策略405引入实体关系图的原因◼在数据密集型应用问题中，对复杂数据及数据之间复杂关系的分析和建模将成为需求分析的重要任务。◼显然，这项任务是简单的数据字典机制无法胜任的。◼所以，有必要在数据流分析方法中引进适宜于复杂数据建模的实体关系图。406数据对象、属性与关系◼数据对

象是现实世界中实体的数据侧面；或者说，数据对象是现实世界中省略了功能和行为的实体。◼数据对象由其属性刻画。通常，属性包括：命名性属性描述性属性引用性属性◼应用问题中的任何数据对象都不是孤立的，它们与其它数据对象一定存在各种形式的关联。407实体关系图◼实体关系图是表示数据对象及其关系的图

形语言机制，具体包括标识系统输入/输出的数据对象、定义对象的属性、描述对象间的关系。4080:11:10:多1:多建立实体关系图的过程1）客户列出业务过程中的事物，它对应一组输入/输出数据对象，及生产/消费信息的外部

实体。2）系统分析员和客户逐个定义对象及对象间的连接。3）根据对象间的连接标识对象-关系偶。4）确定对象-关系偶的数量关系。5）重复2）－4）直至创建所有的对象-关系偶。6）描述实体属性。7）复审实体-关系图。8）重复1）－7）完成数据建模。409内容5.1数据

流图与数据字典5.2实体关系图5.3面向数据流的分析过程5.4面向数据流的设计过程5.5启发式设计策略410（1）建立数据流模型◼在创建用户需求的数据流模型的过程中，分析人员应遵循以下规则：1.首先建立顶级

数据流图，其中只含有一个代表目标软件系统整体处理功能的转换。2.对用户需求的文字描述进行语法分析，其中的名词和名词短语构成潜在的外部实体、数据源或数据流，动词构成潜在的处理功能。3.采用通常的功能分解方法，按照“强内聚、低耦合”原则逐个对处理功能进行精化；与此同时逐

步完成对数据流的精化，并针对被精化的处理功能生成下一级数据流图。4.在精化过程中必须维持各级数据流图的平衡。5.精化过程应适可而止，避免涉及软件设计细节。411示例：ATM顶级数据流图412用户控制面板银行ATM系统存款器显示器取款器用户命令存入款项信息取出款项信息显示信息管理员控制开关管理员命

令读卡器银行卡信息银行系统打印机账户变更信息银行系统账户信息打印信息示例：一级数据流图413用户控制面板命令处理存款器显示器取款器用户命令存款数额取款数额显示信息管理员控制开关启动/停止命令读卡器银行卡信

息银行系统打印机账户变更信息银行系统帐户和密码信息打印信息密码核对启动/停止取款查询余额存款信息显示凭条打印转帐存款命令查询命令取款命令转帐命令启动/停止状态交易记录存款交易记录查询交易记录转帐交易记录取款交易记录需显示的交易信息账户和用户输入密码有效/无效打印信息

银行系统账户信息账户信息银行系统账户信息账户信息启动/停止命令示例：二级数据流图414取款数额获取账户余额取款命令取款交易记录账户余额余额比较账户余额正常取款处理余额不足处理余额满足余额不足生成交易记录处理结果处理结果取款命令分析取款数额

（2）过程规格说明◼对于数据流图中不再分解的处理功能，分析人员要借助结构化的自然语言对其功能进行精确、简洁的描述。◼例如，余额比较：(1)参数：取款数额；类别：整数(2)处理步骤：(a)从银行系统中获取账户的余额信息；(b)比较账户余额和取款金额之间的大小；(c)如果账户余额大于等于

取款金额，则进入“正常取款处理”(d)如果账户余额小于取款金额，则进入“余额不足处理”；(3)约束条件：每次的取款金额不能超过2000元。415内容5.1数据流图与数据字典5.2实体关系图5.3面向数据流的分析过程5.4面向数据流的设计过程5.5启发式设计策略416（1）基本概

念和设计过程◼面向数据流的方法能方便地将数据流图转换为软件结构，其过程分为五步：1.确定信息流的类型；2.划定流界；3.将数据流图映射为程序结构；4.提取层次控制结构；5.通过设计复审和使用启发式策略进一步精化所得到的结构。417变换流◼入信息流沿传入路径进入系统，同时由外部形式变换为内部形

式，经系统变换中心加工、处理，作为输出信息流又沿传出路径离开系统，并还原为外部形式。418事务流◼单个数据项称为事务（Transaction）沿传入路径（也称接受通道）进入系统，由外部形式变换为内部形式后到达事务中心，事务中心根据数据项计值结果从若干动作路径中选定一条继续

执行。419设计过程420流的类型精化数据流图确定事务中心和各动作路径“事务流”确定输入、输出流界“变换流”映射为事务结构映射为变换结构提取控制结构利用启发式策略精化软件结构描述接口和全局数据结构复审未通过通过详细设计事务分析变换分析变换分析的步骤◼

步骤一：复审基本系统模型◼步骤二：复审和精化软件数据流图◼步骤三：确定数据流图的特性，判定它为变换流还是事务流◼步骤四：通过划定输入流和输出流的边界来孤立变换中心421确定变换中心422变换分析的步骤◼步骤五：执行“一

级分解”423输入流变换流输出流主控模块变换流控制模块输入流控制模块输出流控制模块变换分析的步骤◼步骤六：执行“二级分解”424主控模块输入流控制模块DBCAABCD“存款”子系统的程序结构“雏形”425主控模块

更新账户信息控制模块存款信息输入控制模块生成交易记录控制模块获取账户余额核对存款命令分析获取存款器数额更新账户余额生成交易记录提交交易记录变换分析的步骤◼步骤七：采用启发式设计策略，精化所得程序结构雏形，以求改良软件质量426主控模块存款信息输入控制模块获取账户余额核对存款命令分析获

取存款器数额更新账户余额生成交易记录提交交易记录（3）事务分析◼事务分析法的步骤与变换分析方法基本类似，主要差别在于从数据流图到程序结构的映射。事务分析法可概括为七个步骤，其中前三个步骤与变换分析法相同，即：步骤一：复

审基本系统模型步骤二：复审并精化软件数据流图步骤三：确定数据流图的特性，判定它为变换流还是事务流427事务分析的过程◼步骤四：指出事务中心，确定由事务中心发出的每一动作路径的数据流特性428启动命令处理用户命令存款数额取款数额启动/停止命令银行卡信息帐户密码密码比较启动/停止取款

查询余额存款转帐存款命令查询命令取款命令转帐命令启动/停止状态存款交易记录查询交易记录转帐交易记录取款交易记录账户和用户输入密码有效/无效账户信息账户信息账户信息账户信息启动/停止命令读入外部命令命令分析命令信息命令读用户密码用户输入密码生成输出信息核对结果事务分析的过程◼步骤

五：把数据流图映射为事务处理型的程序结构429ABDPQRSBAQPDC1RS流C1接收路径事务控制散转“命令处理”的一级分解430外部命令处理主控模块转帐控制模块命令分析启动命令处理存款控制模块读入外部命令查询余额控制模块取款控制模块密码核对控制模块启动/停

止控制模块事务分析的过程◼步骤六：分解并精化事务结构以及每条动作路径所对应的结构431外部命令处理主控模块转帐控制模块命令分析启动命令处理存款控制模块读入外部命令查询余额控制模块取款控制模块密码核对控制模块启动/停止控制模块生成输出信息读用户密码密

码比较事务分析的过程◼步骤七：使用启发式设计策略，精化所得程序结构雏形，改良软件质量432内容5.1数据流图与数据字典5.2实体关系图5.3面向数据流的分析过程5.4面向数据流的设计过程5.5启发式设计策略433◼启发式设计策略是人们从长期的大量软件

开发过程中积累总结的经验：改造程序结构，减小耦合度，提高内聚度。改造程序结构，减少高扇出，在增加程序深度的前提下追求高扇入。改造程序结构，使任一模块的作用域在其控制域之内。改造程序结构，减少接口的复杂性和冗余程度，提高协调性。模块功能应该可预言，避免对模块施加过多限制。

改造程序结构，追求单入口单出口的模块。为满足设计或可移植性的要求，把某些软件用包的形式封装起来。434本章完436第6章用户界面设计6.1界面设计的基本原则6.1界面设计的基本原则6.2设计良好界面的主要途径6.3用户界面的分析与设计过程6.4用户界面分析6.5用户界面设计

6.6用户界面原型6.7界面设计的评估设计人员须考虑的重要因素◼人只有有限的短暂记忆能力◼人都会犯错，特别是在我们必须处理大量信息或承受压力的情况下◼人们都有不同程度的生理特征◼人都有不同的交互喜好基本原则◼用户熟悉程度◼一致性◼使惊讶最小化◼可恢复性◼用户帮

助◼用户多样性6.2设计良好界面的主要途径6.1界面设计的基本原则6.2设计良好界面的主要途径6.3用户界面的分析与设计过程6.4用户界面分析6.5用户界面设计6.6用户界面原型6.7界面设计的评估用户界面设计的三条黄

金准则◼（1）使系统处于用户控制之中◼（2）减少用户记忆负担◼（3）保持界面一致性（1）使系统处于用户控制之中◼所定义的交互模式不会强迫用户进行不必要的动作，用户能够很容易地进入或退出交互模式。◼提供灵活的交互

方式。◼允许打断或撤销用户交互。◼事先根据用户的熟练程度来提高交互效率并且允许交互定制。◼为不熟悉系统的用户隐藏内部技术细节。◼与出现在屏幕上的对象直接交互。（2）减少用户记忆负担◼减少短期记忆要求。◼建立有意义的默认设置。◼定义符合直觉的快捷方式。◼界面

的视觉布局应该依据真实世界的比喻。◼以渐进的方式来揭示信息。（3）保持界面一致性◼用户能够在有意义的上下文中进行当前的任务。◼维护系列软件的一致性。◼如果之前的交互模型已经能够满足用户的期望，则不要随意进行修改，除非有强制性的理由。6.3用户界面的分析与设计过

程6.1界面设计的基本原则6.2设计良好界面的主要途径6.3用户界面的分析与设计过程6.4用户界面分析6.5用户界面设计6.6用户界面原型6.7界面设计的评估（1）界面交互方式◼直接操作◼菜单选择◼表格填写◼命令语言◼自然语言（2）界面分析和设计模型◼在用户界面的分析和设计过程中，有四种模型能够

起作用：分析工程师（或软件工程师）建立的用户模型系统用户介绍软件工程师构建的设计模型终端用户产生的用户心智模型或系统感知模型用户对所使用系统的想象系统实现人员创建的实现模型●实现模型结合了基于计算机系

统外部显示以及描述系统语法和语义的信息。（3）分析与设计过程◼螺旋迭代过程螺旋线每次经过某个活动表示需求的细化以及相应的设计活动。界面分析重点考虑将与系统交互的用户的信息。界面设计的目标是定义一组界面对象和动作的集合以及它们的屏幕表示

。界面确认注意三方面内容。6.4用户界面分析6.1界面设计的基本原则6.2设计良好界面的主要途径6.3用户界面的分析与设计过程6.4用户界面分析6.5用户界面设计6.6用户界面原型6.7界面设计的评估（

1）用户分析◼用户信息获取方式：用户会谈销售人员信息采集市场分析用户支持人员信息收集◼用户分析技术：任务分析用户采访和问卷调查群体文化学（2）任务分析和建模◼任务分析的目标是回答下面这些问题：用户在

规定的情况下将进行哪些工作用户工作时需要执行哪些任务用户在工作时将需要操作问题领域中哪些专门的对象任务的顺序以及层次结构◼为了回答这些问题，软件工程师可以使用需求分析和建模中的技术:用例任务细化对象细化工作流分析层次化表示（3）内

容展示分析◼展示信息包括：文字报告图形图像或其它专门的信息◼在显示内容分析这个步骤中，需要考虑界面显示内容的格式和美观性。（4）工作环境分析◼对于某些应用程序，计算机辅助系统的用户界面被放置在利于用户使用的环境中，但也可能存在一些不理

想等情况，界面设计人员有可能受到这些因素的影响，从而减弱了软件的易用性。◼除了物理环境因素，工作地点的文化也可能对界面设计人员产生作用。6.5用户界面设计6.1界面设计的基本原则6.2设计良好界面的主要途径6.3用户界面的分析与设计过

程6.4用户界面分析6.5用户界面设计6.6用户界面原型6.7界面设计的评估用户界面设计步骤（1）界面对象、动作和布局的定义◼界面设计中一个很重要的步骤是定义界面对象，然后定义在界面对象上使用的动作。◼对象和动作被定义并被迭代精化后，就可以对它们进行分类，指定目标对象、源对象

以及应用对象。◼当设计人员认为所有重要的对象和动作都已经定义，就可以开始进行屏幕布局。与其它界面设计活动类似，屏幕布局也是一个迭代的过程，其中包括图形设计和图表的放置、描述性文字的定义、窗口的描述和标题的命名，然后可以开始定义主要的菜单项。（2）

界面设计需考虑的问题◼响应时间◼用户帮助◼错误处理◼用户界面的友好性◼国际化◼命令标记◼……6.6用户界面原型6.1界面设计的基本原则6.2设计良好界面的主要途径6.3用户界面的分析与设计过程6.4用户界面分析6.5用户界

面设计6.6用户界面原型6.7界面设计的评估原型构建过程◼在理想情况下，用户界面原型的构建过程包括两个阶段：前期阶段：构建出纸上的原型，包括屏幕设计的实体模型，然后和用户进行商讨。后期阶段：对设计进行精化，并且开发

逐渐复杂的界面原型，然后把它们提供给用户来进行测试和动作模拟。原型构建方式◼脚本驱动的方法◼可视化的程序语言◼基于因特网的原型6.7界面设计的评估6.1界面设计的基本原则6.2设计良好界面的主要途径6.3用户界面的分析与设计过程6.4用户界面分析6.5用户界面设计6.6用户

界面原型6.7界面设计的评估界面设计评估循环周期◼基本过程可用性属性◼界面评估是评价一个界面可用性以及检查界面是否满足用户需求的过程，因此，它应该是软件系统正常的验证和确认过程的一部分。理想情况下，评估需要根据可用性属性的规约来开展：易学性操作速

度健壮性可恢复性适应性其他评估方法◼还有如下一些简单经济的用户界面评估技术，可以指出特定的用户界面设计存在的不足：调查表，可以用于收集用户对于界面的看法；观察用户在工作时使用系统的方式，并且总结出用户如何使用系统来完成某些任务；典型系统

应用的视频快照；在界面中包含搜集最常用功能和错误信息的代码。本章完第7章软件体系结构风格与设计模式466前言1、软件体系结构是软件工程的一个重要研究内容2、软件体系结构的设计是软件开发中的一个关键环节，是软件质量的重要保证。3、软件体系结构已经成为一个重要的研究方向和

独立的学科分支。4、软件体系结构对软件的总体结构进行清晰的描述和分析、并用它指导软件的后续开发。5、模式的本质：可解决一类问题并能重复使用的解决方案内容7.1基本概念7.2软件体系结构描述语言7.3软件体系结构风格7.4设计模式基

本概念◼软件设计模式：广义定义：可解决一类软件问题并能重复使用的软件设计方案狭义定义：设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。是在类和对象的层次描述的可重复使用的软件设计问题解决方案。基本概念◼软件体系结构风格：是在构件和连

接子的层次所描述的可重复使用的软件设计问题解决方案。基本概念◼二者的共性和区别：区别：1、设计模式是在类和对象的层次描述问题，粒度较小；2、体系结构风格是在构件和连接子的层次描述问题，粒度较大。体系结构风格是广义上的设计模式。共性：都是可重复使用的软件设计问题解决方案内容7.1基本概念7.2软件体

系结构描述语言7.3软件体系结构风格7.4设计模式软件体系结构描述语言◼软件体系结构描述语言ArchitecturalDescriptionLanguage，简称ADL是用来描述软件密集型系统的总体结构的语言，说明系统众多部件之间的结

构关系。◼代表性的体系结构描述语言◼Wright◼Rapide◼Darwin◼Unicon◼ACME◼ABC/ADL◼XYZ/ADL◼XADL大部分结构描述语言都有构件、连接子、配置等概念软件体系结构描述语言◼WrightADL构件（Comp

onent）连接子（Connector）端口（Ports）构件规范（Component-spec）计算（Computation）配置（Configuration）角色（Roles）粘连（Glue）实例（Instances）联接（Attachments）WrightA

DL◼过程调用实例：一个Caller类型的构件c通过D-C-connector类型的连接子dc调用Definer类型的构件dc调用d调用实例的Wright体系结构描述图形化的体系结构描述语言GADL◼GADL的元模型ConceptualConfigurationCComponentCC

onnectorCPortCRoleProtocol11110..10..10..10..10..10..1****************cbindingconnectioncbindingobeyobey图形化的体系结构描

述语言GADL调用实例的GADL体系结构描述—构件图c:Callerd:Definerdc:D-C-connectorprovidecallerdefinerrequest构件连接子端口角色图形化的体系结构描述语言GADL调用实例的GADL体系结构描述—类图图

形化的体系结构描述语言GADL◼一个图形化的体系结构描述语言GADL调用实例的GADL体系结构描述—协议类图和顺序图<<protocol>>ProcedureCall-1/port:ProcedureCall-1/role:ProcedureCall-1portprovide:callreq

uired:returnroleprovide:returnrequired:callcallreturnWright与GADL◼GADL语言用构件图、类图、顺序图等方式描述系统的软件体系结构，对行为的描述GADL用顺序图，而Wright用进行代数CSP。内容7

.1基本概念7.2软件体系结构描述语言7.3软件体系结构风格7.4设计模式软件体系结构风格◼在构件和连接子的层次上描述的可重复使用的软件设计问题解决方案。1.管道/过滤器风格2.层次风格3.客户/服务器风格核心特征、应用场景、注意的问题（1）管道/过滤器风格◼实例剖析：统计a.txt中单词的个数

并打印出来：shell命令：“cata.txt|wc-w|lpr”cat:Sourcewc:Filterlpr:Sinkp1:Pipep2:Pipeentryexitoutputoutputinputinputentryexit1、cat命令输出a.txt的内容2、通过管道传给命令w

c，统计输入流中单词的个数并输出3、输出的单词数通过管道传给命令lpr，lpr将其打印出来构件图命令是构件、管道是连接子（1）管道/过滤器风格◼实例剖析：shell命令：“cata.txt|wc-w|lp

r”类图（1）管道/过滤器风格◼实例剖析：shell命令：“cata.txt|wc-w|lpr”<<protocol>>WriteDataportrequire:write()/port:WriteData/role:Writ

eDatawrite()succeedfailed若管道中已没有空间，则返回“失败”roleprovided:write()WriteData协议类图和顺序图（1）管道/过滤器风格◼实例剖析：shell命令：“cata.txt|

wc-w|lpr”<<protocol>>ReadData/port:ReadData/role:ReadDataread()portrequire:read()roleprovided:read()ReadData协议类图和顺序图（1）管道/过滤器风格◼实例剖析：打印a.t

xt中soft的个数“cata.txt|grep-osoft|wc-w|lpr”wc:Filtercat:Sourcegrep:Filterlpr:Sinkp1:Pipep3:Pipeentryexitoutputoutput

inputinputentryexitp2:Pipeentryexitoutputinput构件图（1）管道/过滤器风格◼特征：系统中构件之间通过数据流松散耦合。也就是说，构件之间的依赖仅仅是数据流，而不是通常的接口函数调用或消息传递。◼其他典型应用：编译器、信号处理等。◼其他说明

：本模式在实现上可以有许多不同的变化，如主动与被动、多出口管道等。（2）层次风格◼实例剖析：数据库系统用户接口（查询、创建等）数据库管理数据库文件（文件管理功能）文件管理外部设备（设备管理功能）设备管

理（2）层次风格◼实例剖析：数据库系统:DataBaseManage:FileManage:DeviceManage:DataBaseSystem:ProcedureCall:ProcedureCalldb数据库服务端口db（2）层次风格◼特征

：从向外提供服务的构件出发，沿着连接关系递次搜索各构件和连接子，如果形成的拓扑结构是一个有向无圈图（典型情况下是一个线性结构），那么这个系统的体系结构风格就是层次式的。◼这种设计风格便于将复杂的系统进行分解；同时也

便于构件替换：只要保持接口一致，就可以将某一层的软件替换掉，而不会影响到系统的其他部分。（2）层次风格◼其他典型应用：开放系统互联（OSI）七层网络模型、WindowsNT操作系统的内核结构。应用层表示层:Pr

ocedureCall物理层:ProcedureCall应用层表示层:ProcedureCall物理层:ProcedureCall网线层1层2层7（2）层次风格◼其他说明：优点是结构清晰、可替换性好、便于控制复杂性；但也有它的缺点，如效率低：分层结构中高层的数据

要经过层层传递和转发，从而降低系统效率。（3）客户/服务器风格◼实例剖析：FTP系统b:FtpClient:FtpServer:Networkc:FtpClienta:FtpClientuser1user2user3（3）客户/服务器风格

◼特征：从向外提供服务的构件出发，沿着连接关系递次搜索各构件和连接子，如果形成的拓扑结构是一棵倒置的树，那么这个系统的体系结构就是客户/服务器风格的。◼这种风格使得服务功能的实现很集中，便于系统实现，因而得到广泛使用。（3）客户/服务器风格◼其他典型应用：电子邮件系统、W

WW系统、TELNET系统、CVS版本控制系统等浏览器WWW服务器应用服务器数据库服务器b:Browser:WWWServer:Network1c:Browsera:Browseruser1user2user3:AppServer:Network2:

DBServer:Network3e:CVSClient:CVSServer:Network1f:CVSClientd:CVSClientuser4user5user6数据库服务器可以向多个浏览器实例提供服务、还可以向CVS系统提供服务。（3

）客户/服务器风格◼其他说明：在客户/服务器风格的系统中，服务器是资源和计算的集中地，因此容易成为存储和计算瓶颈，实际应用中为了提高服务器的性能，可能要采用集群处理等办法。同时，这个特点也使得这类系统容易遭受拒

绝服务（DenyOfService）攻击，因此在设计和应用中要作针对性考虑。◼此外，在这种风格的系统中，服务器中往往要存储更多客户的状态信息，因此大量使用并发执行技术，如多进程、多线程等，这也就涉及到进程、线程的动态创建、调度、删除等问题。这些问题处理得好坏直接影响到服务

器的性能。内容7.1基本概念7.2软件体系结构描述语言7.3软件体系结构风格7.4设计模式设计模式◼文献[7-2]中描述了23个设计模式，并将它们分为三种类型：创建型设计模式、结构型设计模式和行为型设计模式。设计模式1.Fact

oryMethod（工厂方法）2.AbstractFactory（抽象工厂）3.Singleton（单件）4.Composite（组合）5.Proxy（代理）6.Iterator（迭代器）7.Observer（观察者）动机和实例、应用场合、结

构、核心思想(1)FactoryMethod◼动机与实例：“龙珠”游戏魔力管道：弹球（pop）制造球（Enchant）球(1)FactoryMethod◼动机与实例：“龙珠”游戏-设计1+Pop()#Enchant()

MagicPipeBall...Ball*ball=newBall;...BallRubberBallSteelBall球有多种，如皮球、钢球Ball抽象父类Ball无法被实例化？(1)FactoryMethod◼动机与实例：“龙珠”游戏-设计2newBall动作包装成虚函数MakeBal

lFactoryMethod在子类（描述各种魔力管道）中重新定义该虚函数(1)FactoryMethod◼适用场合：有一些实体（各种魔力管道），它们的结构和行为是相似的，且都包含一些相似的更小实体（各类球），但一个大实体内

部的这些小实体都是同一类的（一种魔力管道内只有一种球）。此时，如果各类小实体的描述构成一个类层次，那么可使用FactoryMethod模式，将各类大实体也描述为一个类层次。(1)FactoryMethod◼结构：FactoryMethod()PublicOperatio

n()BigEntityFactoryMethod()ConcreteBigEntitySmallEntityConcreteSmallEntity...smallEntity=FactoryMethod()...returnnewConcreteSmallEnti

ty(1)FactoryMethod◼核心思想归纳：在父类中，将创建对象的操作包装为一个虚函数，在描述公共行为的过程中调用该函数；在子类中重定义该虚函数来定制创建的对象，从而间接定制公共行为。利用虚函数的多态机制，FactoryMethod模式使得父类可集中描述公共行为，而将特别行

为（不同对象的创建）抽放于子类。(2)AbstractFactory◼动机与实例：魔力管道。在前面的设计中，三个MakeBallFactoryMethod工厂方法散放在三个MagicPipe类中。为了降低复杂性，可以把所有的创建动作拆分出来单独考虑。

即：创建球的动作单独形成一个工厂类，专门创建对象。MakeBallFactoryMethod()AbstractFactoryBallRubberBallSteelBallMakeBallFactoryMethod()RubberBallFactoryMakeBallFa

ctoryMethod()SteelBallFactory+Pop()+SetAbstractFactory()#Enchant()MagicPipe...Ball*ball=abstractFactory->MakeBallFactoryMethod()

;...abstractFactory(2)AbstractFactory◼动机与实例：设计3(2)AbstractFactory◼动机与实例：设计4不仅有球、还有盒子等小实体，抽象工厂类专门创建各种小实体(2)Abstract

Factory◼动机与实例：设计5MakeBallFactoryMethod()AbstractFactory1BallRubberBallSteelBallMakeBallFactoryMethod()RubberB

allFactoryMakeBallFactoryMethod()SteelBallFactory+Pop()+SetAbstractFactory()#Enchant()MagicPipe...Ball*ball=abstractFactory1->MakeBallFactoryMethod()

;Box*box=abstractFactory2->MakeBoxFactoryMethod();...BoxRubberBoxSteelBoxabstractFactory1MakeBoxFactoryMethod()AbstractFactory2MakeBoxFactoryMeth

od()RubberBoxFactoryMakeBoxFactoryMethod()SteelBoxFactoryabstractFactory2混合管道和小实体(2)AbstractFactory◼适用场合：当需要创建一组多种风格的小实体、且具体创建方式又要灵活可调整时，可使用Abs

tractFactory模式，将公共的创建行为描述为一个抽象类，而将具体的创建方式用该抽象类的子类来描述。(2)AbstractFactory◼结构：CreateProductA()CreateProductB(

)AbstractFactoryAbstractProductAProductA1ProductA2CreateProductA()CreateProductB()ConcreteFactory1CreateProductA()CreateProductB()ConcreteF

actory2+SetAbstractFactory()+Func()BigEntity...AbstractProductA*a=abstractFactory->CreateProductA();AbstractProductB*b=ab

stractFactory->CreateProductB();...abstractFactoryAbstractProductBProductB1ProductB2(2)AbstractFactory◼核

心思想归纳：为了提供灵活性，将需要创建的同一风格的一组小实体的一般特征提取出来，用一组抽象产品类来描述，同时将创建行为封装为一个抽象工厂类，提供通用的创建接口，而将各种具体的产品和具体的创建行为用抽象产

品类和抽象工厂类的子类来描述。从而使得BigEntity和具体的产品特性和具体的创建行为隔离开来，既降低了耦合度，也使得灵活调整创建行为成为可能。(3)Singleton◼动机与实例：日志功能，在一个应用程序内部一般只需要一个日志实例即可。实现方案1公有的构造

函数//log.h#include<stdarg.h>#include<windows.h>classLog{public:Log();voidPrint(LPSTRformat,...);voidSetFile(LP

STRfilename);virtual~Log();private:(3)Singleton实现方案1全局变量(3)Singleton◼实现方案1需要日志的地方直接使用变量g_log和相关接口函数//main.cpp#include"log.h"voidmain(){g_log.SetFil

e("myapp.log");g_log.Print("Appstarts...");...}(3)Singleton◼实现方案1：两个缺陷一般情况下（如果只有一个日志文件）只需要一个Log实例即可，但上述做法不能保证Log的实例只有一个，当多个

实例设置相同的日志文件的时候，还可能引起冲突；这种做法使得g_log无论用到与否都要被创建。(3)Singleton◼实现方案2：使用Singleton模式私有静态成员变量，代替全局变量，指向log唯一实例构造函数变为

protected不可能在类外部创建实例静态私有函数代替全局变量，获取实例指针(3)Singleton◼实现方案2：使用Singleton模式#include“log.h”Log*log::theOnlyInstance=0;Log*L

og::getInstance(){If(!theOnlyInstance)theOnlyInstance=newLog();ReturntheOnlyInstance;};…初始化为0静态成员函数getInstance返回theOnlyInstance的值(3

)Singleton◼实现方案2：使用Singleton模式#include“log.h”Voidmain(){Log*plog=Log::getInstance();…};…需要日志时，调用静态成员函数getIns

tance值(3)Singleton◼适用场合：当需要确保一个类最多只有一个实例时，使用本模式。(3)Singleton◼结构：设需要保证只有一个实例的类为Singleton，则类Singleton的定义为：(3)Singl

eton◼结构：类Singleton的实现为：(3)Singleton◼核心思想归纳：通过将一个类的构造函数设置为protected或private，可有效阻止从外部直接创建该类的实例；同时设置一个静态成员函数，以负责创建唯一的实例并向外提供访问接口。(4)Composite◼

动机与实例：幻灯片制作软件。一张幻灯片上可以有各种图元对象：文本框、图形、图像、影片、声音等等。图元具有“递归组合”特性。Draw()GraphicDraw()TextDraw()RectangleDraw

()CircleDraw()Add(ing:Graphic)Remove(ing:Graphic)GetChild(inidx:int)Compositegraphicsforallgingraphicsg.Draw()(4)Compos

ite◼适用场合：当需要描述的对象具有“递归组合”特征、且希望用户忽略基本对象与组合对象的区别时，适用本模式。◼结构：Operation()ComponentOperation()LeafOperation()Add(ing:Component)Remove(ing

:Component)GetChild(inidx:int)Compositechildrenforallginchildreng.Operation()Client(4)Composite◼核心思想归纳：为基本对象和组合对象提

供一个公共的抽象父类，以表示所有对象，并建立起从该抽象父类到组合对象类的聚集关联，从而间接建立起“递归组合”特性。(5)Proxy◼动机与实例：网络中间件。在这类程序中，实际工作的对象可能运行在远程的主机上，与客户端应用分别处于不同的地址空间。为了

编程方便，在其中大量地使用了Proxy模式。建立一个Proxy对象：它与Server对象的接口是一样的，而且与Client对象位于同一台机器、同一地址空间中，所有发给它的操作请求最终都转发Server对象。给使Client对象的设计开发变得简单，就

像本地编程一样，网络交互的许多细节则集中到Proxy对象的实现中。Operation()ProxyClientOperation()Server本地网络上(5)Proxy◼适用场合：1.前面的例子中使用Proxy模式是为了屏蔽网络交互细节、透明进行远程访问，因此

属于“远程代理”；2.还有一些场合是为了提高性能、降低开销，而设置一个“虚代理”，如文档文件中的图像代理，它只描述图像的位置、大小等基本信息，具体图像文件细节仅在需要时再创建一个真正的图像对象来描述；3.另外，当被访问对象的内部结构很复杂且

需要进行智能的分析、决策和协调时，可使用“智能代理”来屏蔽这些智能决策的细节，如一个“订票”代理就是如此：它可根据多家航空公司的订票服务，智能选择一种符合用户要求的订票方案。(5)Proxy◼结构Request()SubjectReques

t()ProxySubjectRequest()RealSubjectClientrealSubject...realSubject->Request();...(5)Proxy◼核心思想归纳：构造一个具有相同接口的代理对象，然后将操作

请求转发给真实对象，其目的是向客户隐藏“转发过程”的细节（如远程网络交互、智能决策、选择性转发等），提供对真实对象的透明访问。(6)Iterator◼动机与实例：支持遍历的列表设计。设计方案1Traverse()Add()Remove()ListFirst()Next()IsDone()Curr

entItem()Add()Remove()List(a)(b)内部迭代外部迭代voidPrintList(List<Item>*pList){for(pList->First();!pList->IsDone();pList

->Next()){pList->CurrentItem()->Print();}};(6)Iterator◼动机与实例：支持遍历的列表设计。设计方案1的问题：1.其一，这种设计只能描述一种遍历方式，如向前遍历或向

后遍历，但不能同时描述多种遍历方式。或许，大家觉得只需要再向List里面增加一些表示遍历的接口函数和表示位置的成员变量即可，但这样一来众多关系不紧密的功能混放在一个类里，会使得内聚程度变低，容易导致类膨胀，同时也给

函数命名等带来不便。2.其二，这种设计不支持在一个列表上同时进行多个相同类型的遍历（如都是向后遍历，只是对元素的处理方式不同），而这种情况可能出现在并行程序中。(6)Iterator◼设计方案2：在一个列表上同时进行多个相同类型的遍历。使用I

terator模式，将负责遍历的部分功能从List中分离出来，单独形成一个类ListIteratorFirst()Next()IsDone()CurrentItem()ListIteratorAdd()Remove()Li

stlist(6)Iterator◼设计方案2：在一个列表上同时进行多个相同类型的遍历ClassListIterator{…Private:constList<Item>*list;…}ListIter

ator增加指向原列表的指针。因此，一个ListIterator实例记录了与列表的一次遍历相关的所有信息，通过定义ListIterator的多个实例变量，就可以在一个列表上同时进行多个相同类型的遍历。(6)Iterator◼

设计方案3：以多种方式遍历一个列表，再定义一个迭代器类型List<Item>*aList;...ListIterator<Item>forward(aList);ReverseListIterator<I

tem>backward(aList);for(forward.First();!forward.IsDone();forward.Next())forward.CurrentItem()->Print();for(backward.Firs

t();!backward.IsDone();backward.Next())backward.CurrentItem()->Print();(6)Iterator◼适用场合：当需要以多种方式灵活地遍历一个聚合对象中的各个元素时，适用本模式。◼结构：F

irst()Next()IsDone()CurrentItem()IteratorConcreteIteratorAggregateConcreteAggregateaggregate(6)Iterator◼核心思想归纳：通过将与遍历

有关的部分从聚合对象的描述中分离出来、单独成类，能够将遍历的状态信息用一个独立对象记录，从而可有效处理多种遍历和并发遍历。另外，本模式可与FactoryMethod模式配合使用，支持从聚合对象直接创建相应的

聚合器。(7)Observer◼动机与实例：Word软件的“窗口拆分”功能。(7)Observer◼动机与实例：Word软件的“窗口拆分”功能。Attach(inw:Window)Detach(inw:Window)Notify()GetDat

a()SetData()dataDocumentdocUpdate()ModifyData()dataWindowwindows...data=doc->GetData();......doc->SetData();......forallwinwind

owsw->Update();......Notify();...(7)Observer◼动机与实例：Word软件的“窗口拆分”功能。aDocumentaWindowanotherWindowModifyData()SetData()Notify()U

pdate()GetData()Update()GetData()(7)Observer◼动机与实例：Word软件的“窗口拆分”功能。classDocument;classWindow{public:voidUpdate();Window(Document*d){doc=d;doc->Attach

(this);}~Window(){doc->Detach(this);}private:(7)Observer◼适用场合：如果对象之间存在一对多的数据依赖关系、且当被依赖对象的数据改变时所有依赖于它的对象都应得到通知并自动更新，那么可使用本模式。被依赖的对象称为发布者，负责发布

数据并通知所有的订阅者（即依赖于该发布者的对象），以便订阅者与发布者的状态保持一致。◼前面的例子中，Document对象为发布者，而Window对象为订阅者。因此，本模式也称为发布-订阅（Publish-Subscribe）模式。订阅者也可称为观察者（O

bserver），它似乎在时刻观察发布者的状态，并及时更新自己。(7)Observer◼结构：GetData()SetData()dataConcretePublisherUpdate()dataConcreteSubscriber...data=publish

er->GetData();......Notify();...Attach(inw:Subscriber)Detach(inw:Subscriber)Notify()PublisherpublisherUpdate()Subscribe

rsubscribers...forallsinsubscriberss->Update();...(7)Observer◼核心思想归纳：对象是对数据和函数的封装，当一个类包含了太多的函数（或称操作）时，我们倾向于将其拆分为多个相互协

作的类，每个协作类描述一部分行为、包含原来的一部分数据和函数，但这种拆分有一个副作用：因为各协作对象很可能会共享部分数据，所以需要维护相关对象在数据上的一致性。通过使用Observer模式，能够为相关对象

制定一个交互协议，专门用作数据的一致性维护。本章完第八章基于分布构件的体系结构550基于分布构件的系统体系结构客户分布构件框架分布构件分布构件分布构件客户端服务器端网络内容8.1EJB分布构件框架8.2DCOM分布构件框架8.3CORBA分布构

件框架8.1EJB分布构件框架◼简介：EJB（EnterpriseJavaBean）分布构件框架由SUN公司主导制定，它基于Java语言，面向企业级的分布式系统开发。Java客户端应用EJB构件远程接口的S

tubJVMEJB构件JVMEJB构件容器网络交互8.1EJB分布构件框架◼实例：HelloWorld1.EJB构件HelloWorldBean文件HelloWorldBean.java：packageexamples.server;importjavax.ejb.Remote;im

portjavax.ejb.Stateless;importexamples.server.HelloWorld;@Stateless@Remote({HelloWorld.class})publicclassHelloWorldB

eanimplementsHelloWorld{publicStringhello(){return"HelloWorld!";8.1EJB分布构件框架◼实例：HelloWorld1.EJB构件HelloWorldBean文件HelloWorld.java：package

examples.server;publicinterfaceHelloWorld{publicStringhello();}8.1EJB分布构件框架◼实例：HelloWorld1.EJB构件HelloWorl

dBean编译上述两个文件，便能够得到两个类文件HelloWorldBean.class和HelloWorld.class，它们分别描述了EJB构件HelloWorldBean和它的远程接口HelloWor

ld。将这两个类放在Jboss安装目录的examples\server子目录下，然后打包成一个文件HelloWorld.jar。至此，EJB构件HelloWorldBean就开发好了。8.1EJB分布构件框架◼实例：HelloWorld2.EJB构件HelloWorldBean的

部署在开发完EJB构件之后，需要将其部署到EJB应用服务器中。对于Jboss，在成功启动之后，只需要将上述的文件HelloWorld.jar直接拷贝到Jboss安装目录下的一个特定子目录中，Jboss就会自动完成EJB构件HelloWorldBean的部署。8.1EJB分

布构件框架◼实例：HelloWorld3.EJB客户HelloWorldClient的开发1.packageexamples.client;2.3.importjava.util.Properties;4.importjavax.naming.Conte

xt;5.importjavax.naming.InitialContext;6.7.importexamples.server.HelloWorld;8.9.publicclassHelloWorldClient{10.protectedstaticHelloWorldhello

world;11.publicstaticvoidmain(String[]args)8.1EJB分布构件框架◼实例：HelloWorld4.测试编译完文件HelloWorldClient.java后，

即可运行命令“javaexamples.client.HelloWorldClient”，结果如下所示：8.1EJB分布构件框架◼原理分析：本实例中定义的三个类之间的关系如下图所示。构件HelloWorldBean的实例由构件容器负责创建。Java客户端应用:He

lloWorldClientEJB构件远程接口的Stubhelloworld:HelloWorldJVMEJB构件:HelloWorldBeanJVMEJB构件容器网络交互8.1EJB分布构件框架◼原理分析：

本实例中定义的三个类之间的关系如下图所示。构件HelloWorldBean的实例由构件容器负责创建。Java客户端应用:HelloWorldClientEJB构件远程接口的Stubhelloworld:HelloWorldJ

VMEJB构件:HelloWorldBeanJVMEJB构件容器网络交互接口HelloWorld的Skeleton:HelloWorldSkeletonHelloWorldBean的包裹类对象:HelloWorldWrapper隐式中间件服务·生命周期管理·事务

管理·持久化服务·安全服务·等等8.1EJB分布构件框架◼原理分析：RMI原理RMI客户:HelloWorldClient远程对象存根:HelloWorldStub远程对象实现:HelloWorldWrapper远程对象骨架:HelloWorldSkeletonhel

lo()hello()MarshallingUnmarshalling网络8.1EJB分布构件框架◼其它说明：在EJB构件框架下，客户端可以有各种不同的形式。无论简单的Java程序，还是Web容器或者客户容器中的Java程序，它们都遵守上述

的EJB构件框架，即通过远程对象的存根访问EJB容器中的会话Bean。内容8.1EJB分布构件框架8.2DCOM分布构件框架8.3CORBA分布构件框架8.2DCOM分布构件框架◼DCOM（DistributedComponentObjectModel，分布构件对象模型）是一个二进制代码层

面的构件模型，由微软公司于1995年左右提出，从COM（ComponentObjectModel，构件对象模型）扩充而成。按照这个模型，以二进制形式存在的构件可以被远程客户透明访问。8.2DCOM分布构件框架◼基本概念1.DCOM客户：泛指所有与D

COM构件交互的程序片断。如果一个DCOM构件要与其他DCOM构件交互，那它同时也是一个DCOM客户。2.DCOM构件：是具有特定格式要求的动态链接库（DLL）文件或可执行（EXE）文件。3.对象、类和类工厂4.接口5.接口的代理/残桩DLL8.2DCOM

分布构件框架◼整体结构LPC8.2DCOM分布构件框架◼实例：HelloWorld，1、开发：共包含十个文件：HelloComponent.cpp、HelloComponent.h：包含EXE构件的主函数WinMain()和相

关代码。HelloClass.cpp、HelloClass.h：包含EXE构件向外提供的类CHelloClass的定义、以及向外提供的工厂类CFactory的定义。Hello.idl：定义类CHelloCl

ass向外提供的接口IHello。既用于EXE构件，也用于客户程序。HelloClient.cpp：客户程序。Registry.cpp、Registry.h：包含一些辅助函数的定义，用于访问Windows注册表。Makefile、HelloProxy.def8.2

DCOM分布构件框架◼实例：HelloWorld2、EXE构件HelloComponent.exe的生成和部署：部署时，需要将HelloComponent.exe和HelloProxy.dll拷贝到服务器上，

并应该将它们都注册到服务器上的DCOM系统中。注册HelloProxy.dll的命令是“Regsvr32HelloProxy.dll”；注册HelloComponent.exe的命令是“HelloComponent.exe-re

gserver”，也就是说它能够自我注册。8.2DCOM分布构件框架◼实例：HelloWorld3、客户方的部署和测试：将HelloClient.exe和HelloProxy.dll拷贝到客户机上，并

将HelloProxy.dll注册到客户机上的DCOM系统中。内容8.1EJB分布构件框架8.2DCOM分布构件框架8.3CORBA分布构件框架8.3CORBA分布构件框架◼CORBA（CommonObjectRequestBrokerArchitecture，分布对象请求

代理体系结构）是一种异构平台下的语言无关的分布对象互操作模型。由OMG（ObjectManagementGroup，对象管理组织）于1990年首次提出，后经过多版改进，最新的CORBA规范是2008年发布的3.1版。8

.3CORBA分布构件框架◼基本体系结构8.3CORBA分布构件框架◼单机环境下的基本体系结构8.3CORBA分布构件框架◼分布式环境下的基本体系结构8.3CORBA分布构件框架◼实例分析：HelloWorld，包含四个文件和七个Java类Hello

.idl<<生成>>HelloPOA_HelloStubHelloHelloImplClientServer<<生成>><<使用>><<使用>><<生成>>HelloOperation<<生成>>8.3CORBA分布构件框架◼完整体系结构8.3CO

RBA分布构件框架◼完整体系结构本章完第九章软件体系结构评估581内容9.1软件体系结构评估简介9.2ATAM方法9.3SAAM方法9.4ARID方法基本介绍◼软件系统的基础是它的体系结构，软件体系结构将影响系统很多质

量属性。◼在软件体系结构确定下来以后，软件系统的这些属性就是可预见的。◼软件体系结构评估的目的在开发过程的早期，通过分析系统的质量需求是否在软件体系结构中得到体现，来识别软件体系结构设计中的潜在风险，预测系统质量属性，并辅助软件体系结

构决策的制定。评估时机◼早评估：评估不需要完整的软件体系结构描述，可以在软件体系结构创建过程中的任何阶段使用评估方法，对已经做出的软件体系结构决策进行检查，或者确定还没有决定的软件体系结构选项。◼晚评估：迟评估的时机是软件体系结构已经明确并且实现已经完成的时候，这种情况在某个组织继承某些遗留系统时

发生，这些遗留系统可能是在市场中购买的，也可能是从本组织现有的存档中发掘的。评估人员（2/2）◼评估团队：其中的人员会实施评估并且进行分析，团队中成员和他们确切的角色将在后面定义；◼利益相关人员：是软件

体系结构和基于它开发的系统的既得利益者。评估结果和质量属性（1/4）◼软件体系结构评估会产生一个评估报告，报告的形式和内容随着所使用评估方法的不同而不一样。◼通过软件体系结构评估可以回答下面两类问题：软件体系结构是否适用于基于它的软件系统？如果对于目前的系统有多个软件体

系结构可以选择，那个是最合适的？评估结果和质量属性（2/4）◼如果一个软件体系结构满足以下两个标准，那么就认为它是适宜的：系统的结果满足质量目标。也就是说，系统的运行是可预期的，并且运行速度足够快，满足系统的性能或时间需求；系统的修改按照计划的方式进行，并且满足安全

约束，系统能够提供必须的功能。系统能够使用现有的资源来开发，现有资源包括：人员、预算、任何遗留系统以及交付之前分配的时间。也就是说，软件体系结构是可构建的。评估结果和质量属性（3/4）◼性能系统响应能力◼可靠性系统随着时

间的进行而保持运行的能力◼可用性系统有效工作的时间比例◼安全性系统在为合法用户提供服务的同时抵制未授权的使用请求和拒绝服务的能力◼可变性快速有效地修改系统的能力评估结果和质量属性（4/4）◼可移植性系统在不

同计算环境中运行的能力◼功能性系统能够按照预期工作的能力◼变化性软件体系结构能够通过扩展或修改来得到新的软件体系结构的程度◼可分解性支持生产系统某个子集的能力◼概念完整性能够统一所有层面系统设计概念的能力评估的益处和代价（1/2）◼评估的益处：把利益相关人员召集

在一起强制特定质量目标的接合生成冲突目标的优先级对软件体系结构有一个清晰的说明提高软件体系结构文档的质量发现跨项目重用的机会得到优化后的软件体系结构实践评估的益处和代价（2/2）◼评估的代价人员开销与参加软件体系结构评估的人员相关的

机会成本◼减小评估代价的方法在相同领域内的重用内容9.1软件体系结构评估简介9.2ATAM方法9.3SAAM方法9.4ARID方法ATAM基本介绍◼ATAM方法能够反映一个软件体系结构满足某些特定质量目标的程度，同时还能够给出这些质量目标相互之间的交互方式。◼ATAM方法也可对遗

留系统进行分析，提高对系统质量属性的理解。◼ATAM方法基本过程（4组）介绍、调查和分析、测试、报告ATAM方法步骤1、ATAM方法介绍2、商业动机的介绍3、软件体系结构介绍4、确定软件体系结构方法5、产生质量属性效果树6、分析软件体系结构方法7、集

体讨论并确定场景的优先级8、再次分析软件体系结构方法9、展示结果步骤1、ATAM方法介绍◼评估负责人给召集在一起的利益相关人员介绍ATAM方法。◼ATAM方法中步骤的简要介绍。◼介绍评估中使用的获取和分析技术，包括效果树的生成、基于软件体系结构方法的获取和分析以及场景的

集中讨论和优先级划分。◼介绍评估的结果，比如已经划分优先级的场景、用于理解和评估软件体系结构的问题、一组指定的软件体系结构方法、一组敏感点和折中点等。步骤2、商业动机的介绍◼项目决策者（最好是项目经理或系统关键客户）会从商业的角度来介绍系统的概况。◼系统最重要的功

能；任何技术、管理、经济或政治方面的相关约束；与项目相关的商业目标和上下文；主要的利益相关人员；软件体系结构的驱动因素，即形成软件体系结构的主要质量属性目标。步骤3、软件体系结构介绍◼首席设计师会以恰

当的详细程度来介绍软件体系结构软件体系结构相关文档的详细程度，可用的时间，行为和质量需求的实质◼软件体系结构视图是设计师用于展示软件体系结构的主要工具功能、并发、代码和物理视图步骤4、确定软件体系结

构方法◼评估团队会得到软件体系结构方法，但并不会对其进行分析，评估团队将要求设计人员为任何使用的软件体系结构方法命名，也将确定任何她们在上一个步骤中听到的软件体系结构方法。◼这些软件体系结构方法定义了系统的关键结构，描述了系统的成长方式

、应对变化的方式、抵抗攻击的方式、与其它系统集成的方式等等。步骤5、产生质量属性效果树◼评估团队与项目决策者（软件体系结构团队、项目经理和客户）一起工作，来确定系统最重要的质量属性目标，并对它们进行优先级划分和精化。交易吞吐量性能可用性可变性数据

延迟硬件失败(M,L)把客户数据库的存储延迟最小化到200毫秒(H,M)实时地提供视频效果安全性新添加产品种类修改COTS(L,H)在少于20人-月的代价下加入CORBA中间件(H,L)在少于4人-周的代价下修改Web用户界面(L,H)由于站点1的动力故障而需要把

请求转到站点3的时间要低于3秒(M,M)磁盘失败后重新启动的时间要低于5分钟(H,M)用于监测并恢复网络失败的时间要少于1.5分钟数据完整性数据保密性(L,H)信用卡和事务在99.999%的时间内是安全的(L,H)用户数据局的授权在99.999%的时间内是

安全的(M,M)最大化授权服务器的平均吞吐量COTS软件失败步骤6、分析软件体系结构方法◼评估团队可以调查实现重要质量属性的软件体系结构方法，这可以通过查看软件体系结构决策并且找出它们的风险决策、无风险决策、敏感点和折中点来完成。◼这个步骤

的输出包括：与每个最高优先级的效果树场景相关的软件体系结构方法或决策；每个软件体系结构方法相关的分析问题；设计人员对于问题的回答；所确定的风险决策、无风险决策、敏感点和折中点。步骤7、集体讨论并确定场景的优先级◼了解主要的利益相关群体◼集体讨论3种类型的场景

用例场景，代表利益相关人员所期望的系统使用方式；成长场景，代表软件体系结构处理成长和变化的方式；探索场景，代表成长的极限形式，包括新的性能或可用性需求、架构的主要改变或系统的任务等等。步骤8、再次分析软件体系结构方法◼评估团队会进行与步骤6中相同的

活动，把新生成的最高级别的场景对应到还没有发现的软件体系结构元素上。◼如果步骤7并没有产生任何在之前的分析过程没有被发现的高优先级场景，那么步骤8就是测试活动，其目标就是尽量完整地发现信息。步骤9、展示结果◼

方法结果中应该包括以下元素已具备文档的软件体系结构方法场景集合以及它们的优先级划分基于属性的问题集合效果树发现的风险决策已具备文档的无风险决策发现的敏感点和折中点四个阶段◼阶段1（步骤1-3）：评估

团队在这个阶段被创建，同时评估组织与需要评估软件体系结构的组织建立合作伙伴关系。◼阶段2（步骤4-6）：这个阶段以软件体系结构为中心，着重于获取软件体系结构信息并且对其进行分析。◼阶段3（步骤7-8）：这个阶段以利益相关人员为中心，着重于获得利益相关人员的观点然后验证第一个阶段的结果。◼阶段

（步骤9）：在这个阶段中产生最终的报告，计划接下来的动作，然后评估组织更新其业绩记录和经验基础。内容9.1软件体系结构评估简介9.2ATAM方法9.3SAAM方法9.4ARID方法SAAM基本介绍◼第一个具备文档说明并且广泛传播的软件体系结构分析方法◼方法假设实践人员会定期地对他们的软件体系结

构有所声明◼SAAM方法的输入一组场景◼SAAM方法的输出代表系统未来变化的场景到软件体系结构的对应，软件体系结构中潜在的复杂度高的区域，同时还有对每个变化工作量的估计；系统功能的理解，或者不同软件体系结构功能数量的比较。SAAM

方法步骤步骤1、场景的形成◼场景应该能够说明系统必须支持的活动类型，同时还必须说明客户参与者将给系统带来的变化类型。◼通过集体讨论的方式来获取场景。◼场景的获取和收集往往需要重复多次，形成场景和软件体系结构描述的过程是相关的，同时也是迭

代的。步骤2、描述软件体系结构◼候选的软件体系结构描述必须使用软件体系结构分析中各个成员能够理解的概念，这些软件体系结构描述除了包括相关连接子，还包括系统的计算构件和数据构件。◼场景的形成和软件体系结构描述通常相互促进软件体系结构描述的缺乏

将强制性地要求利益相关人员考虑针对当前软件体系结构专门特征的场景。场景反映了软件体系结构的需求，从而必须在软件体系结构描述中实现。步骤3、场景的分类和优先级划分◼直接场景场景的进行不需要修改软件体系

结构。通过展示现有的软件体系结构在执行此场景时的行为来决定。◼间接场景场景没有被直接支持，但存在一些可表示的软件体系结构的变化来支持场景步骤4、间接场景的单独评估◼设计人员能够描述应该如何修改软件体系结构来适应间接场景。◼列出为了支持间接场景对软件体系结构必须做的修

改，然后还要估计修改的代价。步骤5、评估场景交互◼当多个间接场景需要修改软件体系结构的某个构件时，它们就被认为在此构件中进行交互。场景交互揭示了产品设计中的功能分配。场景交互能够暴露出软件体系结构文档的

不够详细，没有达到结构分解的要求。步骤6、形成总体评估◼根据每个场景对于系统成功的相对重要程度，每个场景会被赋予一个权重，这个权重常常也与场景支持的商业目标相关。◼权值的决定是一个主观的过程，需要所有的利益相关人员通过讨论甚至辩论来决定。◼如果比

较多个软件体系结构，每个支持的直接场景的数量也会影响评估，因为直接场景意味着无需修改系统就能够支持某个用户任务。内容9.1软件体系结构评估简介9.2ATAM方法9.3SAAM方法9.4ARID方法ARID基本介绍◼ATAM方法和SAAM方法适合于评估成熟的软件体系结构。◼在

软件体系结构发布之前对其进行评估能够及时发现设计中的错误、不一致或缺陷。◼在中间阶段，需要的是一个简单、轻量级的评估方法，主要关注于系统的适应性，并且能够在没有详细设计文档的情况下使用。ARID方法步骤◼阶段1、排练步骤1、确定评审人步骤2

、准备设计情况介绍步骤3、准备种子场景步骤4、准备材料◼阶段2、评审步骤1、介绍ARID方法步骤2、介绍设计步骤3、场景的集体讨论和优先级划分步骤4、应用场景步骤5、总结本章完第十章软件设计的进化618内容10.1遗留系统10.2

软件的进化策略10.3软件再工程10.4软件体系结构的进化10.5代码重构和数据重构10.6软件移植遗留系统◼遗留系统是过去开发的计算机系统，通常使用了目前已经过时或不再使用的技术。◼这些系统的开发可能在生命周期中一直持续

，通过变更来适应新需求、新运行平台等方面的变化。◼遗留系统不仅包括硬件和软件，还包括遗留的业务过程和步骤。对这类系统的一部分进行变更将不可避免地导致其它组成部分的变更。遗留系统的组成支撑软件系统硬件应用软件应用数据业务策略和规则业务过程运行使用运行使用使用包含

应用知识遗留系统的层次模型业务过程应用软件支撑软件硬件内容10.1遗留系统10.2软件的进化策略10.3软件再工程10.4软件体系结构的进化10.5代码重构和数据重构10.6软件移植（1）进化策略的分类◼遗留软件的

维护和升级将会受到预算、期限等多种因素的约束，因此开发者需要对遗留软件系统的实际情况进行评价，然后选择最合适的进化策略：完全放弃该软件不改变该软件系统并继续进行常规的维护对软件系统实施再工程（re-engineer

ing）以提高可维护性用新系统替换遗留软件系统的全部或其中一部分（2）进化策略的选择◼选择合适的进化策略需要对遗留软件系统进行准确的评价。◼在对遗留软件进行评价时，业务需求和技术这两个方面均要进行考虑，评价结果分为四种类型：低业务价值，低系统质量（X）高

业务价值，低系统质量（进化或替代）低业务价值，高系统质量（X）高业务价值，高系统质量（常规维护）遗留软件系统的评价业务价值高业务价值低系统质量高业务价值高系统质量低业务价值低系统质量低业务价值高系统质量系统质量业务价值的评价◼为了评价一个系统的业务价值，首先需要明确系统最终用

户及其管理者，并从下面四个主要方面对系统进行考察：系统的使用系统支持的业务过程系统的可靠性系统的输出系统质量的评价◼从技术角度来评价一个软件系统，需要同时考虑应用软件本身以及软件运行的环境。◼环境包括硬件和所有相关的支撑软件，例如对于系统维护

所需要的编译器等。◼认为环境很重要的原因是，很多软件系统的变更是由于环境变更导致的，例如硬件或操作系统的升级。◼如果可能，在环境评价的过程中，应对系统及其维护过程的某些方面进行度量。环境评价考虑的因素因素问题厂商稳定性供应商是否仍然存在？供应商经济

上是否稳定并可能会继续存在？如果供应商不再存在，是否有其他人来维护系统？失效率硬件是否有较高的失效率？支撑软件是否会崩溃并迫使系统重启？已使用时间硬件和软件已经使用多久？硬件和支撑软件使用越久，就会越陈旧，尽管可能仍正常运转，但这时迁移到现代系统中有可能带来更显著的经济和商

业利益。性能系统的性能是否足够？性能问题是否对系统使用者有明显的影响？保障需求硬件和软件需要哪些本地保障？如果保障的成本较高，就值得考虑对现有系统进行替换。维护成本硬件维护和支撑软件许可证的成本如何？与现代系统相

比，陈旧的硬件可能有较高的维护成本。支撑软件每年的许可证收费也可能较高。互操作性该系统与其它系统的接口如何？例如，编译器能否在当前版本的操作系统中使用？是否需要硬件模拟器？技术评价考虑的因素因素问题可理解性理解当前软件源代码的困难程度如何？其使用的控制结构有多复杂？变量是

否具有能反映其使用的、有意义的命名？文档有哪些软件文档可用？文档是否完整、一致、有效？数据软件系统是否有数据模型？数据在文件间复制的程度有多大？系统使用的数据是否是最新和一致的？性能软件系统的性能是否足够？性能问题是否对用

户有显著影响？程序设计语言用来开发软件的程序语言是否有可用的现代编译器？该程序语言是否还在新软件的开发中使用？配置管理软件所有部分的所有版本是否由一个配置管理系统进行管理？当前软件系统中使用的组件版本是否有清楚的描述？测试数据是否存在系统测试数据？在往系统中加入新特征后，是否实施

了回归测试，并进行相应的记录？人员技术能力是否有人具有维护该系统的技术？是否只有有限数目的人员理解该系统？内容10.1遗留系统10.2软件的进化策略10.3软件再工程10.4软件体系结构的进化10.5代码重构和数据重构10.6软件移植再工程的概念◼软件系统的进化过程包括对必须改进的程

序进行理解，然后实现相应的改进。◼但是，对于许多存在已久的遗留系统，这些系统已经难以理解和更改。◼对这些遗留软件进行维护的成本甚至会超过用户所能容忍的程度。◼这样，就需要通过再工程来对软件系统进行重建，改进其功能和性能以满足用户的最新需要，并提高整个系统的可靠性和可维护性。再工程的优点◼减少风险。

对关键软件完全进行重新开发具有很高的风险。新开发的软件系统未在实践中充分应用，可能在开发过程中存在的某些问题还未暴露出来。而新系统开发如果延迟完成，将会造成极大的损失。◼减少成本。根据以往的实践经验和统计，再工程的成本要明显比开发一个全新的软件低。正向工程和再工程系统规格说明设计和实现新系

统正向工程现有软件系统理解和转换再工程后的系统再工程两个相关的概念◼重构：在同一抽象级别上转换系统描述形式。例如：设计重构、数据重构等。◼设计恢复：指借助工具从已有程序中抽象出有关数据设计、软件体系结构设计和过程设计等信息（和原设计可能会有所

不同），是从较低的抽象层次获取更高抽象层次的表示。（1）业务过程重构◼对于遗留系统，其支持的业务过程可能已经发生了变化，因此在实施软件再工程之前，应该对变化的业务过程进行重构。◼业务过程重构主要包括定义业务

目标、标识并评估现有的业务过程、以及创建修订后能更好满足目标的业务过程。业务过程重构模型求精和实例化过程标识过程评估过程规约和设计原型实现业务定义（2）软件再工程的过程模型软件清单分析文档重构逆向工程代码重构数据重构正向工程设计重构（3）软件再工程的

经济因素◼由于成本原因，软件再工程并不一定是用户的最终选择，用户可能希望能从成本-收益来判定是否实施再工程。◼而在面对多个遗留软件时，也可以通过成本-收益分析结果来确定哪个系统的重构优先级最高。软件再工程的成本－收益模型P1：软件当前的年度维护成本P2：软件当前的年度运作成

本P3：软件当前的年度业务价值P4：实施再工程后预期的年度维护成本P5：实施再工程后预期的年度运作成本P6：实施再工程后预期的年度业务价值P7：估计的再工程成本P8：估计的再工程所需时间P9：再工程风险因子L：期望的系统生存年数软件再工程的成本－收益模型◼如果继续进行维护（不实施再工程），该应用

软件的后续维护成本为：Cmaint=[P3-(P1+P2)]×L◼而再工程的相关成本定义为：Creeng=[P6-(P4+P5)]×(L-P8)-(P7×P9)◼于是，再工程的整体收益为：成本收益=Creeng-Cmaint（4）信息恢复的级

别和方法◼软件的逆向工程就是分析已有的程序，寻求比源代码更高层次的抽象表现形式。◼一般认为，凡是在软件生命周期内，将软件某种形式的描述转换成更为抽象形式的活动都属于逆向工程的一部分。◼逆向工程导出的信息可分为如下4个抽象层次：(1)实现级，包括程序的抽象语法树、符

号表等信息；(2)结构级，包括反映程序各部分之间相互依赖关系的信息，例如调用图、结构图等；(3)功能级，包括反映程序段功能及程序段之间关系的信息；(4)领域级，包括反映程序组成部分或程序诸实体与应用领域概念之间对应关系的信息。恢复信息的方

法◼用户指导下的搜索与变换◼变换式方法◼基于领域知识的方法◼模版识别法内容10.1遗留系统10.2软件的进化策略10.3软件再工程10.4软件体系结构的进化10.5代码重构和数据重构10.6软件移植（1）软件体系结构进化的过程

需求变化分析与归类软件体系结构的恢复软件体系结构进化计划搜索可复用或第三方构件软件体系结构的改善软件体系结构的评价与技术评审进化后的软件体系结构未通过软件体系结构的恢复◼从软件和源代码中抽取体系结构描述非常关键，这时从

软件的各个方面综合提取，包括软件的静态元素和动态元素：静态元素包括模块之间的调用关系、依赖关系、类之间的继承关系和继承的层次、包之间的导入关系、软件编译时构件间的依赖关系，等等；动态元素包括进程间的通信过程、运行时模块间的调用过程、对业务的执行过程、对输入和相关事

件的响应过程，等等。◼对抽取出的各种元素进行综合后，形成软件的体系结构描述。软件体系结构的恢复可视化模型（UML）体系结构描述提取和抽象源代码模型理解与分析遗留软件（源代码、文档、专家知识与经验）软件体系结构提取综合过程提取分类合并融合软

件体系结构软件体系结构的改善◼软件体系结构的恢复只是把遗留软件的体系结构设计信息重新提取和组织，而软件进化的目标是使遗留软件适应新的需求和环境，因此下一步就需要对软件体系结构进行改善。◼改善需要以恢复后的体系结构为基础，以新出现的需求为依据，结合遗留软

件系统之外的可复用构件或模块，对体系结构进行改造。集中式遗留系统向分布式系统的进化数据库应用服务用户界面用户终端用户终端用户终端用户终端遗留软件系统中间件层（包装）客户机支持用户界面分布的体系结构进化数据库应用服务用户界面

遗留软件系统屏幕管理中间件使用图形化界面的客户机屏幕描述内容10.1遗留系统10.2软件的进化策略10.3软件再工程10.4软件体系结构的进化10.5代码重构和数据重构10.6软件移植代码和数据重构◼在改善软

件体系结构之后，还需要通过更加具体的重构活动修改源代码和数据以适应未来的变化。◼通常，代码重构和数据重构并不修改整体的软件体系结构，它趋向于关注个体模块的设计细节以及模块中的局部数据结构定义。代码重构◼代码重构的目标是生成具有相同功能、但质量比原来程序更高的代码。◼代码重构可以有多种方

式，例如：用布尔代数对程序逻辑进行描述，然后应用一系列变换规则来重构逻辑，以从混乱、无结构的代码导出遵循良好程序设计思想的程序。用资源交换图（resourceexchangediagram）映射每个程序模块及其与其他模块之间交互的资源（数据类型、过程、变量等），通过创建资源流的表示，程序结构可

以被重构以达到模块间的最小耦合，提高软件质量和可维护性。数据重构◼需要对所有包含数据定义、文件描述、I/O和接口描述的程序语句进行分析，抽取数据项和对象，获取关键数据流的信息，理解现有的数据结构实现。◼进行数据重设计，要澄清数据定义，使现存数据结构或文件格式中的数据

项或物理记录格式之间保持一致，并保证所有数据命名遵从约定的标准以及删除程序流程中的别名。◼数据重构有可能包括从一种文件格式到另一种文件格式的转换，或从一种类型数据库到另一种类型数据库的转换。内容10.1遗留系统10.2软件的进化策略10.3软件再工程10.4软件体系结构的进化10.5代码

重构和数据重构10.6软件移植软件移植的概念◼软件移植（Migration）也可以看作是软件进化和再工程的一种形式，是应用软件的运行从一种操作环境迁移到另外一种操作环境的过程，例如操作系统、特定硬件平台、数据库系统等发生变化。◼一般情况下，软件移植应该是迁移到相对更加适合或更加先进的

环境中，该过程面临着较大的技术变更。◼软件移植大部分情况下都要对应用软件与运行环境的接口相关部分进行修改，不论是嵌入式软件还是一般信息管理软件，因此良好的接口定义能够促使软件移植更加顺利。移植需要考虑的问题◼移

植过程中最可能出现的主要问题有哪些？◼客户的要求以及优先级是什么？◼用户接口是否需要与以前保持一致，包括输入/输出、报告、文件等与用户日常使用相关的内容？◼资金和资源具有哪些约束？◼哪些因素可能会对满足客户目标产生影响？◼是否需要支持遗留系统和新系

统的重叠使用？如果是，需要多久？◼目标系统的数据库是否与遗留系统一致？◼是否需要软件工具来执行遗留数据库的转换？◼新系统要支持哪些与遗留系统具有接口的外部系统？等等移植需要综合考虑的内容◼编程语言◼用户界面◼平台和体

系结构◼数据库数据库优先的信息系统移植DSP结构转换遗留信息系统数据转换程序转换D’S’P’进化的信息系统映射结构转化◼数据库包含两部分：结构（Schema）和数据（Data），首先对数据库结构进行转化，当新的数据库结构确

定后再以此为基础进行数据转换和程序转换。数据库转换◼数据库转换可以分为物理转换（D1）和概念转换（D2）：物理转换：把遗留数据库的设施直接转换为目标数据库中最接近的设施。这种方式最节省成本，但可能导致较低的质量，不能体现出新系统的价值

。概念转换：对遗留数据库的精确语义描述进行恢复，并使用目标数据库的标准方法对结构进行开发。该方式具有较高质量，但成本较高。程序转换◼对于程序转换，可以分为三种不同层次的转换，即包装（P1）、语句重写（P2）和逻辑重写（P3），很明显其成本和移植后的系统质量都是递增的：包装

：对新数据库进行包装以符合遗留软件访问数据的逻辑，这使得遗留程序能直接访问新的数据库系统。语句重写：对数据库访问语句进行重写，使得能够使用新型数据库的数据访问特征。该方式和包装方式都不对程序的逻辑进行改变。逻辑重写：对整个程序进行重写，使其能够充分利用新型数据库的所有强大能力。但该方式需要对程

序逻辑具有深入的理解。信息系统移植策略<D1,P1><D2,P1><D1,P2><D2,P2><D1,P3><D2,P3>DP物理概念包装语句逻辑本章完人有了知识，就会具备各种分析能力，明辨是非的能力。所以我们要勤恳读书，广

泛阅读，古人说“书中自有黄金屋。”通过阅读科技书籍，我们能丰富知识，培养逻辑思维能力；通过阅读文学作品，我们能提高文学鉴赏水平，培养文学情趣；通过阅读报刊，我们能增长见识，扩大自己的知识面。有许多书籍还能培养我们的

道德情操，给我们巨大的精神力量，鼓舞我们前进。