软件设计与体系结构

第1章软件工程与软件设计1.1软件工程1.2软件生存周期1.3软件开发过程模型1.4软件设计1.5软件体系结构1.6小结第一页，共664页。第1章软件工程与软件设计以计算机为核心的信息社会软件是信息化的灵魂以工程化方法和思想开发软件软件设计是软件开发过程中的核心活动之一第二页，共664页。1.1软件工程软件危机：在计算机软件的开发和维护过程中所遇到的一系列严重问题软件设计：计算机软件发展到一定阶段，为了应对软件危机计算机软件=程序+数据+文档计算机软件是逻辑和智力产品，不是物理产品第三页，共664页。1.1软件工程软件的应用领域和分类系统软件实时软件嵌入式软件科学和工程计算软件事物务理软件人工智能软件个人计算机软件第四页，共664页。1.1软件工程软件危机软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。即包含两方面的问题：(1)如何开发软件(2)如何维护软件软件危机的原因软件产品生产效率较低软件供需失衡用户需求不明确整个软件开发过程缺乏正确的理论指导软件产品的规模越来越大软件产品开发的复杂度越来越高第五页，共664页。1.1软件工程软件工程软件工程是指导计算机软件开发和维护的工程学科；将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上述方法的研究；是用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术和管理方法；软件工程要素：方法、工具、过程方法：为软件开发提供了“如何做”的技术，是完成软件工程项目的技术手段工具：人类在开发软件的活动中智力和体力的扩展和延伸，为软件工程方法提供自动或半自动的软件支持环境过程：将方法和工具综合起来以达到合理、及时地进行软件开发的目的第六页，共664页。1.1软件工程软件工程的目标和原则在给定成本、进度的前提下，开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可复用性、可适应性、可移植性、可跟踪性并满足用户需求的软件产品。抽象、信息隐藏、模块化、局部化、一致性、完全性、可验证性第七页，共664页。目标可修改性有效性可靠性可理解性可维护性可复用性可适应性可移植性可追踪性基本目标：付出较低的开发成本达到要求的软件功能取得较好的软件性能开发的软件易于移植需要较低的维护费用能按时完成开发工作及时交付使用软件工程的目标是提高软件的质量与生产率，最终实现软件的工业化生产。

第八页，共664页。软件工程的原则抽象

采用分层次抽象，自顶向下、逐层细化的办法控制软件开发过程的复杂性信息隐蔽

将模块设计成“黑箱”，实现的细节隐藏在模块内部，不让模块的使用者直接访问。这就是信息封装，使用与实现分离的原则模块化

如C语言程序中的函数过程，C++语言程序中的类。模块化有助于信息隐蔽和抽象，有助于表示复杂的系统。第九页，共664页。软件工程的原则局部化

要求在一个物理模块内集中逻辑上相互关联的计算机资源，保证模块之间具有松散的耦合，模块内部具有较强的内聚。这有助于控制解的复杂性确定性

软件开发过程中所有概念的表达应是确定的、无歧义性的、规范的。一致性

整个软件系统的各个模块应使用一致的概念、符号和术语。程序内部接口应保持一致。软件和硬件、操作系统的接口应保持一致。系统规格说明与系统行为应保持一致。用于形式化规格说明的公理系统应保持一致第十页，共664页。软件工程的原则完全性

软件系统不丢失任何重要成分，可以完全实现系统所要求功能的程度。为了保证系统的完备性，在软件开发和运行过程中需要严格的技术评审。可验证性

开发大型的软件系统需要对系统自顶向下、逐层分解。系统分解应遵循系统易于检查、测试、评审的原则，以确保系统的正确性。第十一页，共664页。软件工程的原则复杂问题子问题1子问题2子问题n程序1程序2程序n软件系统解决原始问题集成分解第十二页，共664页。1.2软件生存周期Softwarelifecycle软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程称为软件生存周期软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存周期软件定义-软件开发-软件使用和维护软件定义(系统分析)：可行性研究(软件计划)、需求分析软件开发(系统设计)：概要设计、详细设计、软件实现(编码、单元测试)、软件测试(组装测试、确认测试)软件使用、维护退役第十三页，共664页。第十四页，共664页。软件生存周期可行性研究确定要开发软件系统的总目标给出功能、性能、可靠性以及接口等方面的要求完成该软件任务的可行性研究估计可利用的资源

、成本、效益、开发进度制定出完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查需求分析对用户提出的要求进行分析并给出详细的定义编写软件需求说明书或系统功能说明书及初步的系统用户手册提交管理机构评审第十五页，共664页。软件生存周期概要设计

—把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块，每个模块都和某些需求相对应，编写设计说明书，评审详细设计

—对每个模块要完成的工作进行具体的描述，为源程序编写打下基础，编写设计说明书，提交评审软件构造把软件设计转换成计算机可以接受的程序代码，即以某一种特定程序设计语言表示的“源程序清单”；程序应当是结构良好、清晰易读的，且与设计相一致的。第十六页，共664页。软件生存周期软件测试单元测试，查找各模块在功能和结构上存在的问题并加以纠正

集成测试，将已测试过的模块按一定顺序组装测试确认测试，按规定的各项需求，逐项进行有效性确认测试，决定已开发的软件是否合格，能否交付用户使用使用与维护：在用户特定的环境中，在测试通过后移交用户使用改正性维护：运行中发现软件中的错误需要修正适应性维护：为了适应变化了的软件工作环境，需做适当变更完善性维护：为了增强软件的功能需做变更第十七页，共664页。1.3软件开发过程模型软件开发过程模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架瀑布模型原型模型螺旋模型统一软件开发过程第十八页，共664页。瀑布模型（生存周期模型）W.W.Royce1970提出瀑布模型，是既自顶向下结构化开发模型优点：奠定了软件工程方法的基础；流水依赖；便于分工协作；推迟现实；文档易修改；有复审质量保证。缺点：用户需求明确困难；用户见面晚；纠错慢；难于克服系统分析员不懂专业领域的知识，用户不懂计算机的困难，成功率低。适合于系统要求明确的小系统。第十九页，共664页。带反馈的瀑布模型第二十页，共664页。快速原型模型rapidprototypemodel根据用户提出的软件定义，快速的开发一个原型，在征求用户对原型意见的过程中，再进一步修改、完善，直至达成一致。模拟软件的人机界面开发一个原型，实现部分功能向用户展示正在运行的类似软件优点：与用户见面快；开发成功率高，适合于需求不确定的大系统。缺点：周期长，开发成本高。第二十一页，共664页。快速原型模型第二十二页，共664页。螺旋模型螺旋模型沿着螺线旋转（一个螺旋式周期），在四个象限上分别表达四个方面的活动，即：制定计划──确定软件目标，选定实施方案，弄清项目开发的限制，选定完成目标的策略风险分析──分析所选方案，考虑如何识别和消除风险，风险角度分析该策略实施工程──实施软件开发，启动一个开发阶段客户评估──评价前一步开发工作，提出修正建议，计划下一轮的工作特点瀑布模型+快速原型+风险分析迭代过程第二十三页，共664页。第二十四页，共664页。统一软件开发过程统一软件开发过程(RUP,RationalUnifiedProcess)是一套软件工程过程，是一套软件工程方法的框架，各个组织可根据自身的实际情况，以及项目规模对RUP进行裁剪和修改，以制定出合乎需要的软件工程过程。适合与统一建模语言(UML,UnifiedModelLanguage）结合起来使用支持六大最佳软件开发实践迭代式开发管理需求基于构建的软件体系结构可视化建模验证软件质量控制变更第二十五页，共664页。统一软件开发过程第二十六页，共664页。统一软件开发过程横轴：时间轴，表示软件开发的顺序开启阶段精化阶段构建阶段产品化阶段纵轴：“谁”在“何时”、“如何”去做“何事”9个工作流程各个阶段实施的工作流程，在不同的时间段内工作流所占工作量不同第二十七页，共664页。1.4软件设计对软件如何被开发出来的一种规范化描述软件需求分析和软件设计受到重视编码所占比例越来越少软件设计的重要性对软件需求的直接体现为软件实现提供直接依据考虑软件系统的各种约束条件并给出相应方案决定最终软件系统的质量及早发现软件设计中存在的错误减少软件修复和维护的成本第二十八页，共664页。1.4软件设计软件设计的特征出现新的问题需要软件来解决、解决问题和实施决策的过程、一系列转换过程、满足各种约束的过程过程、不断演化的过程、给出一个方案、新思路、新想法软件设计的要素目标描述、设计约束、产品描述、设计原理、开发规划、使用描述第二十九页，共664页。1.5软件体系结构软件设计是从软件需求到软件实现的活动，它把各种软件需求转换为能直接实现的软件结构软件需求与软件设计之间存在难以逾越的鸿沟，如何有效的将软件需求软化为相应的设计？软件需求——？——软件设计——软件实现—软件体系结构第三十页，共664页。1.5软件体系结构软件体系结构的定义软件体系结构是软件系统的结构，包含软件元素、软件元素外部可见的属性以及这些软件元素之间的关系；软件体系结构是软件系统的基本组织、包含构件、构件之间、构件与环境之间的关系，以及相关的设计与演化原则；软件体系结构是程序或系统中组件的结构、组件之间的相互关系、设计的基本原则以及随时间进化的指导方针；第三十一页，共664页。1.5软件体系结构软件体系结构的发展历程“无体系结构”设计阶段萌芽阶段以汇编语言进行小规模应用程序开发为特征以描述系统的高层抽象结构为中心，不关心具体的建模细节，划分了体系结构模型与传统软件结构的界限，该阶段以Kruchten提出的“4+1”模型为标志出现了从不同侧面描述系统的结构模型，以UML为典型代表。出现了程序结构设计主题，以控制流图和数据流图构成软件结构为特征高级阶段初期阶段第三十二页，共664页。1.5软件体系结构软件体系结构的内容软件体系结构的描述：软件体系结构描述语言软件体系结构的设计方法软件体系结构的分析方法软件体系结构的复用第三十三页，共664页。本章完第三十四页，共664页。

第二章：统一建模语言UML第三十五页，共664页。内容2.1 UML概述2.2 面向对象开发方法2.3 UML2.0结构建模2.4 UML2.0行为建模第三十六页，共664页。（1）UML的发展历程多种面向对象分析与设计方法的存在不利于面向对象方法的发展，也给用户的选择带来一些困惑。1994年Booch和Rumbaugh首先将各自先前的研究成果统一起来，于1995年10月发布了UM0.8。经过Booch、Rumbaugh和Jacobson三人的共同努力，于1996年发布UML0.9，并从此将UM命名为UML。UML结束了“模型论战”，融合了众多优秀的面向对象建模方法以及软件工程方法，消除了因建模方法相互独立带来的诸多不便。第三十七页，共664页。UML2.01997年对象管理组织（ObjectManagementGroup，OMG）采纳UML作为其标准建模语言，并通过严格有序的OMG过程对其进行修订和维护。1999，UML1.3，相对稳定成熟阶段2001-05，UML1.42003年6月宣告完成了UML2.0：Infrastructure（底层结构）Superstructure（上层结构）OCL（对象约束语言）DiagramInterchange（图形交换）第三十八页，共664页。UML2.0UML2.0另一个显著特征就是加强了对模型驱动体系（ModelDrivenArchitecture，MDA）的支持。MDA的目标是要实现从UML模型到最终代码的自动化生成。UML已经迅速成为软件设计语言的事实标准。本章介绍UML2.0上层结构中规定的各种模型的语法和用途。第三十九页，共664页。（2）UML的特点和用途为使用者提供了统一的、表达能力强大的可视化建模语言，以描述应用问题的需求模型、设计模型和实现模型。提供对核心概念的扩展机制，用户可加入核心概念中没有的概念和符号，可为特定应用领域提出具体的概念、符号表示和约束。独立于实现语言和方法学，但支持所有的方法学，覆盖了面向对象分析和设计的相关概念和方法学。独立于任何开发过程，但支持软件开发全过程。提供对建模语言进行理解的形式化基础，用元模型描述基本语义，OCL描述良定义规则，自然语言描述动态语义。增强面向对象工具之间的互操作性，便于不同系统间的集成。支持较高抽象层次开发所需的各种概念，如协同、框架、模式和构件等，便于系统的重用。第四十页，共664页。（3）UML2.0建模机制13种视图模型，分为结构视图和行为视图结构视图：描述系统中各种元素之间的组织结构关系行为视图：描述系统中有关元素的行为过程第四十一页，共664页。（3）UML2.0的建模机制结构建模：类图包图对象图构件图组合结构图部署图行为建模：活动图顺序图通信图交互概览图时序图状态图用例图第四十二页，共664页。UML2.0的建模机制第四十三页，共664页。内容2.1 UML概述2.2 面向对象开发方法2.3 UML2.0结构建模2.4 UML2.0行为建模第四十四页，共664页。面向对象方法面向对象开发方法通过提供对象、对象间消息传递等语言机制让软件开发人员在解空间中直接模拟问题空间中的对象及其行为。削减了语义断层，拉近了问题空间与解空间的距离，简化了软件工程师为问题寻找解的工作，并为软件开发活动提供了直观、自然的语言支持和方法学指导。第四十五页，共664页。面向对象的基本概念基本概念

面向对象=对象+类+继承+聚集+多态+消息对象:现实世界中个体或事物的抽象表示，是其属性和相关操作的封装。类:某些对象的共同特征（属性和操作）的表示。对象是类的实例，类是创建对象的模板。继承聚集:部分—整体关系多态:父类及其子类中，对外接口的定义形式相同，却可以对应多种接口的实现形态（重写、重载）。消息:对象和对象之间是通过传递消息来完成相互通信，对象与外部世界相互关联的唯一途径。第四十六页，共664页。（2）面向对象方法的优势简化软件开发过程支持软件复用改善软件结构第四十七页，共664页。内容2.1 UML概述2.2 面向对象开发方法2.3 UML2.0结构建模2.4 UML2.0行为建模第四十八页，共664页。结构建模结构建模也称为静态建模，主要用来描述系统中包含的元素以及元素之间的关系。结构建模中的视图可以对各个层次和阶段的软件进行刻画，例如软件设计、软件实现、系统部署等。这些模型对系统的逻辑结构或物理结构进行描述，并不涉及系统的动态行为和过程。UML2.0中的结构建模包括类图、包图、对象图、构件图、组合结构图和部署图。第四十九页，共664页。结构建模本节结构建模视图模型如下：包图包、依赖关系、导入关系、合并关系对象图构件图构件、接口、装配连接子、委托连接子组合结构图部署图第五十页，共664页。（1）类图类图是UML中最基本、也是最重要的一种视图，它用来刻画软件中类等元素的静态结构和关系。类图的图元：类、抽象类、接口、依赖关系、关联关系、聚集关系、构成关系、泛化（继承）关系、实现关系、关联类第五十一页，共664页。类描述具有相同特征、约束和语言的一类对象，这些对象具有共同的属性和操作。Customer+Buy():void+Pay():void+name:string#address:stringCustomer类名属性：类型操作+:Visiblea：详细设计的类b：简单表示的类：仅给出类名第五十二页，共664页。抽象类一个类只提供操作名，而不对其进行实现，对这些操作的实现可以由其子类进行，并且不同的子类可以对同一操作进行不同的实现。不能被实例化的类，一般至少包含一个抽象操作+Buy():void+Pay():voidCustomer类名，斜体字符表示抽象类第五十三页，共664页。接口声明一些属性或方法，但并不实现它们。用来规定一种契约，对接口进行实现的元素（类）必须遵循该契约。构造型和圆圈两种表示。构造型表示的接口接口名标识元素类型与接口相连的是对接口进行实现的类第五十四页，共664页。依赖关系两个类之间存在依赖关系，表明一个类使用或需要知道另一个类中包含的信息，用虚线箭头表示第五十五页，共664页。关联关系两个类之间存在关联关系，表明这两个类的实例之间存在语义上的联系。关联可以具有方向性(有单方向关联，双方向关联)。

多重性意义11个并且只有一个0。。*或者*0到无限1。。*1到无限2。。42到4的范围2，42或者4第五十六页，共664页。聚集关系聚集关系是一种特殊的关联，表示两个类的实例之间存在一种拥有或属于关系，是较弱的“整体—部分”关系，或是逻辑上的“隶属”关系。整体（上级）类一侧有一个空心菱形的图。PersonCompany*1第五十七页，共664页。构成关系构成关系表明两个类的实体间存在一种包含关系，是比聚聚关系更强的“整体—部分”关系，部分对象在任何时候都只能属于一个整体对象，整体对象被破坏则部分对象也被破坏。用实心菱形表示，菱形在整体一侧。第五十八页，共664页。泛化（继承）关系第五十九页，共664页。实现关系实现关系表示一个元素是对另一个元素的实现第六十页，共664页。关联类关联类用来记录与关联（关系）有关的信息，提供与关联有关的操作。第六十一页，共664页。（2）包图包图在UML中可以看作是类图的一部分。包用来对一组元素进行划分，是对复杂模型的一种分而治之的层次划分。常用来描述一个复杂系统逻辑上的子系统划分。包图主要由包和包之间的关系组成。包的划分应遵循高内聚、低耦合的原则，一个包中可以包含多个类和子包。包图的图元：包、依赖关系、导入关系、合并关系第六十二页，共664页。包第六十三页，共664页。依赖关系如果包中的元素之间存在依赖关系，则包存在依赖关系。OrderManager包中的类依赖于SystemInterface包中的某个类第六十四页，共664页。导入关系当一个包（CustomerManager）中的元素访问另一个包（OrderManager）中的元素时，需要给出被访问元素的完整名称，如OrderManager::Order。如果把OrderManager包中的元素导入到CustomerManager中，则可以使用直接访问Order类。《import》导入。《acess》导入：被导入元素的可见性是private，不可以被其他包使用。第六十五页，共664页。导入关系第六十六页，共664页。导入关系第六十七页，共664页。合并关系把一个包中的内容合并到另一个包中，合并后的包拥有两个包中的内容，可见性为private的元素不被合并，具有相同名字的元素通过泛化关系连接起来。第六十八页，共664页。（3）对象图对象图是看作类图的实例，对象之间的连接是类之间关联关系的实例。对象名：所属的类；可以出现一个类的多个实例。第六十九页，共664页。（4）构件图基于构件的软件开发日益受到重视，UML2.0对构件图进行较大的改进。构件的根本特征在于它的封装性和可复用性，其内部结构被隐藏起来，只通过接口向外部提供服务或请求外部的服务。通过明确构件对运行环境的假设（即接口定义），可以将构件封装起来，尽可能的独立，从而为复用提供支持。构件图用来描述系统中存在的构件、构件具有的接口、以及各个构件怎样通过接口连接起来形成一个完整的系统。第七十页，共664页。（4）构件图构件图的图元：构件、接口、装配连接子、委托连接子构件是系统中具有良好封装、可替换的模块简单构件构件的表示符号：复杂构件内部有实现细节，可以是构件或者是类第七十一页，共664页。（4）构件的依赖关系一个构件需要用到另一个构件的信息第七十二页，共664页。接口一个构件与其他构件之间通过具有规范定义的接口进行交互，这使得一个构件可以被另一个具有相同接口定义的构件替换（换灯泡）。需求接口（RequiredInterface）提供接口（ProvidedInterface）第七十三页，共664页。装配连接子把一个构件的服务和另一构件的需求连接起来第七十四页，共664页。委托连接子复杂构件包括多个子构件，复杂构件的需求和提供接口的功能应由其某个子构件完成。把复杂构件的外部接口与内部子构件的接口映射起来，由端口（port）和委托连接子（delegate）描述。端口由一个小方框表示，一个端口可以对应多个接口，方向是从需求方指向提供服务方。第七十五页，共664页。委托连接子需求接口委托给Customer子构件的Account需求接口提供接口委托给Order子构件的OrderState提供接口第七十六页，共664页。（5）组合结构图为了描述复杂系统在运行时的结构，组合结构图通过内部结构、端口、协作等概念，描述系统、对象、协作实例等元素之间的结构关系。组合结构图中可以使用类图、对象图、构件图中的有关图元，也可以有自己独特的建模元素。第七十七页，共664页。组合结构图中的端口端口q是一个行为端口，与一状态连接，状态用来解释端口运行时的行为端口p在运行中有两个实例第七十八页，共664页。组合结构组合结构图可用来描述系统及其组成部分，组成部分的描述类似于对象图中的对象，但组合结构图可以说明该部分属于哪个系统。第七十九页，共664页。协作组合结构图能够描述表示系统功能行为的协作（Collaboration）及其内部的实现结构，并且协作可以实例化，第八十页，共664页。（6）部署图部署图用来描述软件开发过程中生成的物理文件形式的软件或信息、运行平台中的物理节点和通信，以及软件文件到相应硬件节点的部署或映射。制品：物理文件形式的软件或信息，如：源代码文件、文档、模型文件等。节点：运行平台中的硬件，节点间通过通信路径进行消息传递。描述制品怎样在节点上部署以及节点之间如何连接第八十一页，共664页。（6）部署图

第八十二页，共664页。内容2.1 UML概述2.2 面向对象开发方法2.3 UML2.0结构建模2.4 UML2.0行为建模第八十三页，共664页。行为建模行为建模也常被称为动态建模，它主要用来刻画系统中的动态行为、过程和步骤。UML行为建模中提供的视图可以从不同侧面来描述软件系统的动态过程。结构建模对系统中的元素及其关系进行描述，而行为建模对这些元素完成特定任务的过程进行描述，两者相互结合就能够完整地描述整个系统的特征。第八十四页，共664页。（1）活动图活动图主要描述一个系统行为的执行过程或步骤，它的适用范围非常广泛，能够用来描述工作流、过程流、算法步骤等从问题域到解空间的任何能够用流的形式描述的行为，可以用于概念层、设计层、实现层等不同抽象层次的系统行为建模。第八十五页，共664页。活动和动作活动是包含一组动作的行为，动作是活动中的一个步骤。初始/终止节点、初始/动作、动作第八十六页，共664页。对象节点为了增强对活动的表达能力，活动图还有一些特殊的节点，以表示活动的输入、输出，以及动作之间传递的复杂对象。示例：两个动作之间传递Order对象第八十七页，共664页。控制节点在实际的活动流程中，会经常出现分支选择情况。还有可能执行完一个动作后，下面需要同时开始执行几个流程，或几个流程完成后汇总为一个流程。分支节点，可标明分支条件分叉节点汇合节点第八十八页，共664页。控制节点第八十九页，共664页。泳道为了能够把动作按照执行该动作的对象进行划分，以明确活动中各个参与者的相应职责，活动图引入了泳道的概念。泳道可以是水平的，也可以是垂直的，或者二者同时存在。第九十页，共664页。泳道第九十一页，共664页。交互图顺序图通信图交互概览图时序图第九十二页，共664页。（2）顺序图顺序图用来描述对象之间动态的交互关系，主要强调完成某个场景的对象之间存在哪些消息传递以及消息的时间序。顺序图的水平轴表示交互的不同对象，垂直虚线表示对象的生命线。对象间的通信表示为对象生命线之间的消息传递，消息有简单消息、同步消息、异步消息等类型。消息有消息名，还可以有参数标识，可以用条件表达式表示消息发送的条件。[发送条件]消息标号：消息名（消息参数）第九十三页，共664页。简单顺序图第九十四页，共664页。顺序图—交互操作对象的交互是一个很复杂的过程，使用交互片段（InteractionFragment）和片段组合（CombinedFragment）对复杂交互进行建模。多个交互片段通过交互操作（InteractionOperator）组合成为一个复杂的交互图。片段组合：交互操作（1..*交互片段）=复杂交互图交互操作：ref,alt,opt,par,loop,critical,neg,assert,strict,seq,ignore,consider,break图2-31第九十五页，共664页。（3）通信图关注参与交互的对象通过连接组成的结构，消息和方向附属于对象间的连接，并通过编号表示消息的顺序。第九十六页，共664页。（3）通信图第九十七页，共664页。（4）交互概览图交互概览图(interactionoverviewdiagram)是把顺序图和活动结合起来描述交互流程和交互细节的一种交互图。交互概览图通过类似于活动图的方式，描述交互之间的流程，给出交互控制流的概览。在交互概览图中，节点不像活动图中那样是动作，而是一个交互图或对交互图的引用。图2-33第九十八页，共664页。（4）交互概览图第九十九页，共664页。（5）时序图时序图用来表示交互中关于消息时间的描述，并描述对象在生命线中，其所处状态或条件随着消息发生的变化。每个事件可给出时间约束。第一百页，共664页。时序图的紧凑形式第一百零一页，共664页。（6）状态图状态图使用有穷状态变迁图的方式刻画系统或元素的离散行为，可以用来描述一个类的实例、子系统甚至整个系统的在其生命周期内，所处状态如何随着外部激励而发生变化。在UML2.0中，状态图又分为行为状态机和协议状态机，前者描述一个建模元素的行为（例如对象），而后者描述一个协议的行为。第一百零二页，共664页。状态与迁移状态指所描述的元素在其生命周期中可位于一种相对稳定的位置，状态一般会（隐含）满足一组条件。状态的表示：状态名，状态中发生的动作/动作的类型，状态之间存在迁移，即从一个状态变化为另一个状态。迁移条件：事件[条件]/动作第一百零三页，共664页。状态图第一百零四页，共664页。状态图—复合状态一个状态还可以再细分为若干个子状态。复合状态可以用来对状态进行层次划分，使得状态图具有良好的结构，并且易于理解。复合状态也有自己的初始状态和终止状态。第一百零五页，共664页。状态图—复合状态（1）第一百零六页，共664页。状态图—复合状态（2）把内部分成几个正交的区域，每个区域内都有一个状态图，几个区域之间是并行执行的，适用于描述具有并发状态的对象。第一百零七页，共664页。伪状态伪状态是一些特殊的状态：初始状态和终止状态选择（Choice）入口点（Entry）出口点（Exit）分岔（Fork）汇合（Join）深度历史（DeepHistory）浅度历史（ShallowHistory）……第一百零八页，共664页。（7）用例图用例图通常被用来描述系统的需求，从用户的角度对系统的功能视点进行建模。一个用例表示系统的一个特定功能，是用户与系统之间一次典型交互，能引发系统执行一系列动作，并且动作执行的结果能被用户（或外部实体）觉察到。用例图刻画了系统包含哪些用例、用例之间、用例与外部角色之间的关系。第一百零九页，共664页。用例和参与者一个用例代表系统执行的一组动作，这些动作完成特定的任务，并产生对用户或外部实体可观察的结果。用例用来描述系统对外可见的需求或功能。参与者是与用例发生交互的系统外部角色，必须是被开发的系统范围之外的角色（不必在本开发系统中实现），它们只与系统发生某种形式的交互。第一百一十页，共664页。用例图第一百一十一页，共664页。用例之间的关系包含关系（include）：表示一个用例执行过程中，另一个用例也必须被执行。通常把多个用例共享的行为提取出来形成一个用例，然后用包含关系连接起来。扩展关系（extend）：一个用例的功能需要通过其他用例进行扩展（在线帮助）。扩展用例只有在某些条件下才会被用到，UML提供了扩展点机制，在被扩展的用例中描述什么条件下执行扩展用例。第一百一十二页，共664页。用例之间的关系第一百一十三页，共664页。本章完第一百一十四页，共664页。第3章

软件设计基础115第一百一十五页，共664页。什么是软件架构？办公室里，关于什么是软件架构，争论正酣。程序员说，软件架构就是要决定需要编写哪些类、使用哪些现成框架。程序经理说，软件架构就是模块的划分和接口的定义。系统分析员说，软件架构就是为业务领域对象的关系建模。配置管理员说，软件架构就是开发出来的以及编译过后的软件到底是个啥结构。数据库工程师说，软件架构规定了持久化数据的结构，其他一切只不过是对数据的操作而已。部署工程师说，软件架构规定了软件部署到硬件的策略。用户说，软件架构就是决定一个个功能子系统如何划分。大家想了想说，这些架构视图好像我们都需要啊，软件架构师哭了。……上述争论可以总结为一句话：不同涉众看待软件架构的视角是不同的。第一百一十六页，共664页。软件设计是软件开发过程中至关重要的部分，它的结果直接影响到最终的软件质量。不等同于“编程序”或“写代码”结构化开发方法、面向对象开发方法、基于构件的软件开发方法形成各种系统化的软件设计过程和技术。软件设计是一个精化的过程，其中也包含多种活动，并需要灵活运用抽象、模块化、求精等多种技术。第一百一十七页，共664页。内容3.1 软件设计的基本概念3.2 软件设计过程3.3 软件设计的质量3.4 软件体系结构设计3.5 高可信软件设计3.6 软件设计规格说明3.7 软件设计评审第一百一十八页，共664页。3.1软件设计的基本概念软件设计主要针对需求分析过程得到的软件需求规格说明，综合考虑各种制约因素，探求切实可行的软件解决方案并最终给出方案的逻辑表示，包括文档、模型等。软件设计受到资源和技术两方面的制约。资源：时间、人力、财力、开发工具。技术：方法、技术、平台。第一百一十九页，共664页。软件设计的最终目标是获得满足软件需求的、明确的、可行的、高质量的软件解决方案。明确：设计模型易于理解可行：在可用的技术平台和软件项目的可用资源条件下，须用预定的开发语言可构造技术可以完整地实现设计模型高质量：设计模型给出需求的实现方案，非功能需求的约束，设计模型优化软件设计基本概念是过去数十年里陆续提出的，软件设计者根据这组概念进行设计决策。第一百二十页，共664页。（1）抽象与逐步求精“抽象”是一个心理学概念，它要求人们将注意力集中在某一层次上考虑问题，而忽略那些低层次的细节。是管理、控制复杂性的基本策略。软件设计过程是在不同抽象级别考虑、处理问题的过程。最初应该在最高抽象级别上，用面向问题域的语言概述问题，包括问题解的形式，然后不断具体化，不断用接近计算机域的语言描述问题，最后，在最低的抽象级别上给出可直接实现的问题解，即程序。第一百二十一页，共664页。（1）抽象与逐步求精软件设过程的每一步都是对较高以及抽象的解作一次更具体化的描述。过程抽象：把完成特定功能的动作序列抽象为一个过程名和参数表，以后通过指定过程名和实际参数调用此过程。数据抽象：把一个数据对象的定义（或描述）抽象为一个数据类型名，用此类型名可定义多个具有相同性质的数据对象。第一百二十二页，共664页。（1）抽象与逐步求精“逐步求精”可视为一种早期的自顶向下设计策略，其主要思想是，针对某个功能的宏观描述用逐步求精的方法不断地分解，逐步确立过程细节，直至该功能用程序语言描述的算法实现为止。在软件设计过程中，抽象与逐步求精是一般都是结合起来进行应用。系统的层次结构的上一层是下一层的抽象，下一层是上一层的求精。第一百二十三页，共664页。第一百二十四页，共664页。（2）模块化与信息隐藏软件体系结构体现了模块化思想，即把软件划分为可独立命名和访问的部件，每个部件称为一个模块，当把所有模块组装到一起时则获得满足问题需要的一个解。模块化使得开发活动更加简单的一个重要因素是模块的信息隐藏，即一个模块的开发者不必看到其它模块的内部，只需知道其接口即可，这使得每个模块的开发人员所要处理的复杂性显著降低。信息隐藏指导的模块化设计不仅支持模块的并行开发，而且还可以减少测试和维护的工作量。第一百二十五页，共664页。（2）模块化与信息隐藏问题求解的研究表明，把两个问题组合起来进行求解的复杂性，一般要比分别对两个问题进行求解的复杂度之和更大，这个结论导致“分治法”的出现，即把一个复杂问题分割成若干个可管理的、更易于求解的小问题。但这种分割并不意味着“无限”分割，当模块数量增加时，模块接口所需要的代价也随之增加。第一百二十六页，共664页。模块数量与成本第一百二十七页，共664页。（2）模块化与信息隐藏恰当的定义模块范围和大小非常重要，这与采用的设计方法密切相关，评价所采用设计方法的标准：模块可分解性模块的组装性模块的可理解性模块连续性模块保护第一百二十八页，共664页。内聚与耦合每个模块应相对独立，其功能相对单一，而模块之间的接口应尽可能简单。内聚是前述信息隐藏和局部化概念的自然扩展，它标志一个模块内部各成分彼此结合的紧密程度。耦合是对软件结构中模块间关联程度的一种度量。耦合的强弱取决于模块间接口的复杂性、进入或调用模块的位置以及通过接口传送数据的多少等。追求高内聚、低耦合。（1）抽象与逐步求精第一百二十九页，共664页。内聚内聚按其高低程度可划分为不同等级，内聚度越高越好，从而获得较高的模块独立性。低等级内聚：偶然性内聚：最低程序的内聚逻辑性内聚时序内聚中等级内聚：过程性内聚通信性内聚高级内聚：顺序性内聚功能性内聚：最高程度的内聚第一百三十页，共664页。三、内聚与耦合偶然性内聚：一个模块内各成分为完成一组功能而组合在一起，它们相互之间即使用关系，也很松散逻辑性内聚：模块完成的诸任务逻辑上相关时序内聚：一个模块包含的任务必须在同一时间内执行过程性内聚：模块内成分彼此相关，并且必须按特定的次序执行通信内聚：模块中各成分都将对数据结构的同一区域进行操作顺序性内聚：各成分均与同一功能相关，且处理按序执行功能性内聚：所有成分形成一个整体，完成单个功能第一百三十一页，共664页。模块内聚A:Readinputsfromdiskfromtapefrom……

逻辑内聚（Logicalcohesion）：Logicallyrelatedfunctionsordataareplacedinthesamemodule.例如：

偶然性内聚（Coincidentalcohesion）：Unrelatedfunctions,processes,ordataarefoundinthesamemodule(forconvenience).例如：工具模块第一百三十二页，共664页。

时序内聚（Temporalcohesion）：Thefunctionsarerelatedonlybythetiminginvolved.例如：系统的初始化问题：不同功能混在一个模块中，有时共用部分编码，使局部功能的修改牵动全局。第一百三十三页，共664页。

通信内聚（Communicationalcohesion）：Allthefunctionsinamoduleoperateonorproducethesamedataset.例如：从同一磁带上读取不相干的数据——

可能破坏独立性。

过程内聚（Proceduralcohesion）：Functionsaregroupedtogetherinamoduletoensureacertainorderofperformance.例如：enterdatacheckdatamanipulatedata第一百三十四页，共664页。

高内聚：

顺序内聚（Sequentialcohesion）：Theoutputfromonepartofamoduleistheinputtothenextpart.

功能内聚（Functionalcohesion）：Everyprocessingelementisessentialtotheperformanceofasinglefunction.第一百三十五页，共664页。

c

模块内聚第一百三十六页，共664页。耦合耦合的强弱取决于模块间接口的复杂性、进入或调用模块的位置、通过接口传输数据量等。模块间的耦合程度直接影响着系统的可理解性、可测试性、可靠性和可维护性，软件设计应追求尽可能松散的耦合，模块间的联系越少，错误在模块间传递的可能性就越小。第一百三十七页，共664页。耦合耦合等级的划分低等级耦合：非直接耦合中等级耦合数据耦合特征耦合控制耦合外部耦合公共耦合高等级耦合：内容耦合传递的信息含有控制信息第一百三十八页，共664页。非直接耦合：两个模块中的任一个都不依赖对方能独立工作。数据耦合：两模块间通过参数交换信息，数据仅限于数据。控制耦合：模块间传递的信息含有控制信息。特征耦合：介于数据耦合和控制耦合之间。外部耦合：若干模块均与同一外部环境关联。公共耦合：若干模块通过全局的数据环境相互作用。内容耦合：一个模块使用另一模块内部的数据或控制信息，或一个模块直接转移到另一模块内部。第一百三十九页，共664页。⑴耦合(Coupling)GreatdealofdependenceIndependent

HighlycoupledLooselycoupledUncoupled

第一百四十页，共664页。例1：A访问C的内部数据或不通过正常入口而转入C的内部。……ABCDA:……………………gotoC1……………………C:……………………C1:…………

内容耦合(ContentCoupling):Onemodulemodifiesanother.第一百四十一页，共664页。例2：部分代码重叠（常出现在汇编程序中）B

A例3：一个模块有多个入口（功能）A:………………………………entry1:………………………………entry2:………………………………

Theleastdesirable第一百四十二页，共664页。

公共耦合

(Commoncoupling)：Dataareaccessiblefromacommondatastore.Global:V1V2A:……………………A1=V1+V2……………………B:……………………V1=B1……………………Global:V1V2A:……………………V1++……………………B:……………………V2=B1+V1……………………问题：

公共部分的改动将影响所有调用它的模块；

公共部分的数据存取无法控制；

复杂程度随耦合模块的个数增加而增加。第一百四十三页，共664页。

控制耦合(Controlcoupling)：Onemodulepassesparameterstocontroltheactivityofanothermodule.ABFlagF2F1Fn…………Flag接口单一，但仍然影响被控模块的内部逻辑。

数据耦合(Datacoupling):Onlydataarepassed.Itiseasytotracedataandmakechanges.

Themostdesirable.原则：尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，完全不用内容耦合。第一百四十四页，共664页。模块间的耦合第一百四十五页，共664页。启发性规则1.争取低耦合、高内聚（增加内聚>减少耦合）2.模块规模适中：过大不易理解；太小则接口开销过大。注意分解后不应降低模块的独立性。3.适当控制——

深度=分层的层数。过大表示分工过细。

宽度=同一层上模块数的最大值。过大表示系统复杂度大。第一百四十六页，共664页。启发性规则系统结构第一百四十七页，共664页。启发性规则扇出=一个模块直接调用\控制的模块数。3fan-out9AA的扇出AA的扇入

扇入=直接调用该模块的模块数在不破坏独立性的前提下，fan-in

大的比较好。第一百四十八页，共664页。启发性规则尽可能减少高扇出结构，随着深度增大扇入。

如果一个模块的扇出数过大，就意味着该模块过分复杂，需要协调和控制过多的下属模块。应当适当增加中间层次的控制模块第一百四十九页，共664页。启发性规则4、作用域在控制域内

控制域MACBM的控制域为{M，A，B，C}

作用域：M中的一个判定所影响的模块。例如：A:…………if……thengotoB1……………………B:……………………B1:……………………作用域在控制域内A:…………if……thengotoM1……………………M:……………………M1:gotoC1……………………作用域超出了控制域上例中A的作用超出了控制域。改进方法之一，可以把A中的if

移到M中；方法之二，可以把C移到A下面。第一百五十页，共664页。启发性规则5、降低接口的复杂程度：接口复杂可能表明模块的独立性差。6、单出单入，避免内容耦合。7、模块功能可预测——相同输入必产生相同输出。反例：模块中使用全局变量或静态变量，则可能导致不可预测。第一百五十一页，共664页。内聚和耦合的量化指标类耦合度类的耦合度为与它耦合的其它类的数目，包括调用其他类的方法、使用其它类的实例变量。一个类越独立，它在应用中就越容易被重用，类之间的耦合度应尽可能的小。方法内聚缺乏程度“不访问相同成员变量的方法对数目”减去“访问相同成员变量的方法对数目”如果一个类中没有任何两个方法对同一变量进行访问，则它们没有相似性，该类的内聚程度将会很低，缺乏内聚度意味着该类可以分为两个或更多的类。第一百五十二页，共664页。内容3.1 软件设计的基本概念3.2 软件设计过程3.3 软件设计的质量3.4 软件体系结构设计3.5 高可信软件设计3.6 软件设计规格说明3.7 软件设计评审第一百五十三页，共664页。（1）软件设计的一般过程软件设计可能是一个多次反复的过程，所以，软件设计一般都可以被看作是迭代的过程。迭代有两层含义：第一层含义是，针对给定的需求模型，通过多次从抽象到具体的设计过程，得出足够精细的设计模型以供软件实现之用。第二层含义是，在需求模型发生变化并更新完成后，第一层含义的设计过程再随之展开，直至获得最终的目标软件产品。第一百五十四页，共664页。软件设计的迭代第一百五十五页，共664页。软件设计的一般过程软件设计过程包括在不同抽象层次上开发系统的多个模型。软件设计可以看作是将需求规格说明转换为可直接提供软件代码实现使用的设计规格说明。工程管理的角度：概要设计：根据需求确定软件和数据总体框架。详细设计：进一步精化成软件的算法表示和数据结构。技术上，概要设计和详细设计由若干活动组成，包括软件体系结构设计、界面设计、模块/子系统设计、数据模型设计、过程/算法设计。第一百五十六页，共664页。软件设计的一般过程第一百五十七页，共664页。1）软件设计计划在设计过程中，对设计活动进行计划应该最早进行，然后按照计划实施体系结构设计、界面设计、模块/子系统设计、数据模型设计、过程/算法设计等活动。软件设计计划的任务是：明确设计过程的输入制品并使其处于就绪状态，定义设计过程的目标、输出制品及其验收准则，确定覆盖设计过程中各个阶段的全局性设计策略，分配设计过程相关人员的职责，针对设计过程中的活动制订工作计划。第一百五十八页，共664页。1）软件设计计划软件设计计划的步骤：确定设计的目标和验收标准明确目标软件系统应遵循的技术标准或规范重新审视项目风险管理计划制定本次设计过程的工作计划对设计过程的工作计划进行评审第一百五十九页，共664页。2）体系结构设计软件体系结构设计的目标是建立软件系统的体系结构，有时也称“顶层架构”。这种架构既要明确定义软件各子系统、关键构件、关键类的职责划分及协作关系，同时也要描绘它们在物理运行环境下的部署模型。顶层架构还必须针对软件系统全局性、基础性的技术问题给出技术解决方案，这种方案往往构成目标软件系统的体系结构的技术基础设施。第一百六十页，共664页。2）体系结构设计评价软件体系结构宽度和深度：软件控制的层数和跨度扇出率和扇入率：扇出率：一个模块的扇出率指该模块直接控制的其他模块数。扇入率：一个模块的扇入率指直接控制该模块的模块数。可见性和联通性模块的可见性：该模块可直接或间接引用的一组模块。模块的联通性：模块可直接引用的一组模块。第一百六十一页，共664页。软件结构有关概念第一百六十二页，共664页。3）界面设计用户界面设计的目标是，为用户使用目标软件系统以实现其所有业务需求而提供友好的人机交互界面。软件界面设计需要考虑以下因素：适用于软件功能易理解性一致性灵敏性容错性人性化国际化个性化合理的布局和谐的色彩界面的易用性界面的美观性第一百六十三页，共664页。4）模块/子系统设计子系统和模块的区别：一个子系统独立构成系统，不依赖其它子系统提供的服务。一个模块通常是一个能提供一个或多个服务的系统部件。它能利用其它模块提供的服务，一般不被看成一个独立的系统。由于模块和子系统都是软件组成部分，它们一般都有层次结构，相互之间存在接口，其设计方法有很多类似的方面，因此我们统一称为模块设计。第一百六十四页，共664页。模块设计的目标模块设计的目标是，确定模块的具体接口定义，并设计模块的内部结构，即，设置包含于其中的（更小粒度的）模块、构件和设计类，明确它们之间的协作关系，确保它们能够协同实现高层模块接口规定的所有功能和行为。在进行模块设计时，要尽量保持模块的功能独立性，遵循“高内聚、低耦合”的设计思想。此外，还要力求将模块的影响限制在模块的控制范围内，使得软件日后的修改和维护工作更加简单。第一百六十五页，共664页。5）过程/算法设计过程/算法设计的任务就是对模块内部的工作和执行过程进行描述，给出有关处理的精确说明，例如事件的顺序、确切的决策位置、循环操作以及数据的组成等。软件结构与软件过程相互关联，软件结构中任何模块的所有从属模块必将被引用出现在该模块的过程说明中。因此，软件过程对应的结构设计亦构成一个层次结构。可以使用UML对模块进行设计第一百六十六页，共664页。使用UML的模块过程设计第一百六十七页，共664页。6）数据模型设计我们把数据结构设计、数据库设计、甚至数据文件设计等统一称为数据模型设计。在数据模型设计中有一个重要概念：持久数据操作，它包括写入、查询、更新和删除四类基本操作以及由它们复合而成的业务数据操作。在很多软件系统中，数据是其核心，因此，对数据元素的格式、结构、访存、表示等机制进行良好建模和优化，是提高软件设计质量和系统性能的基础，对软件系统的应用具有重要意义。第一百六十八页，共664页。内容3.1 软件设计的基本概念3.2 软件设计过程3.3 软件设计的质量3.4 软件体系结构设计3.5 高可信软件设计3.6 软件设计规格说明3.7 软件设计评审第一百六十九页，共664页。软件设计质量的重要性软件设计是软件开发过程中的核心活动，软件设计的质量不但对最终软件产品的质量起着决定性作用，还对软件开发过程以及软件以后在使用过程中维护的难易程度有着重要的影响。高质量的软件设计，能够有效缩短软件开发时间，减少开发成本，提高最终软件产品质量。第一百七十页，共664页。软件设计的质量要素评价软件设计的质量结构良好充分性可行性简单性实用性灵活性健壮性可移植性可复用性标准化第一百七十一页，共664页。软件设计的质量软件设计对最终软件产品质量产生的影响包括：正确性可靠性运行效率可移植性可维护性可复用性第一百七十二页，共664页。软件设计的质量软件设计对软件开发过程可能产生的影响包括：开发效率交付时间风险管理资源使用成本人员培训合法性第一百七十三页，共664页。正确性目标:每个项目都要满足指定的需求，然后一起满足所有应用程序的需求实现正确性的途径：达到正确性的非正式方法完全理解－>模块化达到正确性的正式方法第一百七十四页，共664页。达到正确性的非正式方法：充分设计一个设计足以实现需求一个正确的设计有时称为设计必须完全可理解接下来设计非常模块化达到这个目标的方法是：。。。最小目标第一百七十五页，共664页。达到正确性的正式方法基于在严密的控制下跟踪变量的变化，一般会指定一个不变式。不变式在变量值之间表示的是一种不变关系。例如：length>=0length*breadth==areaoverdraft<OVERDRAFT_MAX用在类级别设计中的不变式称为类不变式。例如1）mileage>=02)mileage<10000004)value>=-3005）originalPrice>=06）(type==“REGULAR”&&value<=originalPrice)||(type==“VINTAGE”&&value>=originalPrice)考虑不变式，将变量设为私有，只能通过公有的存取方法才能改变他们的值。可以对存取方法进行编码来保持不变式。如通过setter方法来设置类不变式精心设计的类通常拥有可理解的不变式集。第一百七十六页，共664页。1.防止错误输入用户输入不是用户的输入数据通信其他应用方法调用2.防止开发错误错误的设计错误的实现健壮性第一百七十七页，共664页。健壮性检查输入在继续进行处理之前，可以检查应用程序的所有输入的方法。检查类型（例如：整形);

检查与前置条件和不变式的输入为提高健壮性而初始化提供静态方法，用来为类产生标准的默认值提高健壮性的参数传递技术保证方法正确调用引入一个捕获参数的类并将约束条件合并强化意图通过防止设计和实现中的错误来提高健壮性强化计划，按计划使用相应功能第一百七十八页，共664页。Example:intcomputeArea(intaLength,intaBreadth){…}如果可行，捕获在类中的参数约束intcomputeArea(RectangleDimensionaRectangleDimension)

在方法中说明所有的参数约束aLength>0andaBreadth>0andaLength>=aBreadth在方法代码中首先检查约束if(aLength<=0)……如果预计这种情况将会出现，则抛出异常否则，如果可能就中止程序否则如果返回的默认值在上下文之间有意义，就将其返回并且产生警告或日志参数的约束第一百七十九页，共664页。ReplaceintcomputeArea(intaLength,intaBreadth) {..}with intcomputeArea(RectangleaRectangle) {..}--whereclassRectangle {… Rectangle(intaLength,intaBreadth) { if(aLength>0)this.length=aLength; else….. } …} 只在一个地方进行错误处理，改进了设计与维护性，不足是产生了类的激增。第一百八十页，共664页。健壮性在使用数据之前进行检查，可以提高健壮性。第一百八十一页，共664页。灵活性灵活性的预期目标：用于增加更多类型功能的设计例如（银行应用）：处理更多类型的账号而不需要修改已存在的代码用于增加不同类型功能的设计例如：在存款功能的基础上增加提款功能修改功能例如：可透支第一百八十二页，共664页。应用中增加同类型功能的设计举例：网站成员注册WebSiteregister()Member0..nmembersclassWebsite{ Member[]members;//ormaybe:vectormembers; voidregister(MemberaMember){...}}怎样才能使设计更灵活以注册新类型的成员？第一百八十三页，共664页。注册网站的灵活性WebSiteMember0..nStandardMemberXMemberYMembermembers解决方案：引入一个基类，将基类抽象化，根据需要产生继承类第一百八十四页，共664页。灵活性我们之所以进行灵活的设计，因为变化和重用是经常出现的第一百八十五页，共664页。可重用性尽可能的降低成本重用原有的工作可以获得最大生产率重用：函数重用、类重用、重用类组合可重用设计，可重用组件函数设计的可重用性基于重用的类选择用于重用的类组合第一百八十六页，共664页。使一个方法具有可重用性完全指定前置条件等避免不必要的封装类耦合如果可行，让方法成为静态的参数化让方法功能化但要限制参数的个数让名字更具表达性可理解性促进可重用性解释算法重用者要知道算法如何工作重用的方法必须给出完整的定义，以便使重用者知道这些方法的功能及使用条件一个方法对于上下文越独立，其可重用性的性能就越高。静态方法就属于这种类型第一百八十七页，共664页。使一个类成为可重用的完整的描述类使类名与功能与实际情况相符定义一个有用的抽象类以获得更广泛的应用减少对其他类的依赖性通过继承获得第一百八十八页，共664页。减少类间的依赖性如果类A依赖于类B，没有类B就不可以使用类A，这就减少了类A的重用性。Piano类依赖Custumer类，因为钢琴是卖给用户的，限制了Piano类的使用。一个库存应用程序可能需要Piano类，但却不需要Customer类。重用Piano类。能否让Custumer类依赖Piano类，因为用户只有购买钢琴时才成为用户。有没有更好的解决方案呢？降低依赖性。CustomerReplace…Piano第一百八十九页，共664页。减少类间的依赖性引入第三个类PianoOrder将其关联起来。这个设计具有一定的作用，但在现实情况中可能是不行的。例如，可能需要访问某一给定用户的订单，而不必检查每个PianoOrder订单对象。中介者设计模式解决问题减少类之间的依赖关系，抽象级的依赖关系是可以接受的。通过减少类的依赖性来增加其可重用性with…CustomerPianoPianoOrder第一百九十页，共664页。高效性应用程序必须在给定的时间内完成特定的功能执行效率处理循环问题消除远程调用消除或制定函数调用存储效率

RAM的大小（运行时）代码本身的规模辅助存储器的大小第一百九十一页，共664页。执行效率影响执行效率的一些因素循环while,for,do远程调用：消除远程调用Requiringanetwork需要网络LANTheInternet函数调用：消除函数调用如果函数调用导致以上情况发生对象创建高效的设计并不要求简单，甚至会比较凌乱高效原则会减少函数调用，会导致产生大量的方法和类，难于扩展和重用第一百九十二页，共664页。

先按其它原则设计，再考虑效率以灵活性，可重用性等原则进行设计找出效率低的部分有针对性的修改一开始就按效率原则进行设计确认当前关键的效率需求在整个阶段都按需求进行设计以上两种方法的结合在设计时为效率需求做出折中在初始设计之后，也要继续考虑效率问题针对时间效率的基本方法第一百九十三页，共664页。时空折中Space处理一个项目的时间通常的目标第一百九十四页，共664页。时间、空间、开发的折中空间时间开发的设备限制可接受的值不可接受的值好于可接受的值第一百九十五页，共664页。内容3.1 软件设计的基本概念3.2 软件设计过程3.3 软件设计的质量3.4 软件体系结构设计3.5 高可信软件设计3.6 软件设计规格说明3.7 软件设计评审第一百九十六页，共664页。（1）软件体系结构设计方法概述软件体系结构的设计方法是指通过一系列的设计活动，获得满足系统功能性需求、并且符合一定非功能性需求约束的软件体系结构模型。目前存在多种体系结构设计方法，它们的侧重点有所不同(功能、非功能、复用)。在实际应用过程中，这些体系结构设计方法并不是绝对互斥的，根据需要，有可能综合运用不同体系结构设计方法的思想，得到最终所需的设计结果。第一百九十七页，共664页。软件体系结构设计方法‘4+1’多视图建模基于评估与转换的设计方法模式驱动的设计方法领域特定的软件体系结构设计复用软件产品线方法其它软件体系结构设计方法第一百九十八页，共664页。

“4+1”模型概述

Kruchten在1995年提出了“4+1”的视图模型。

“4+1”视图模型从5个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，