1、23（1）什么是软件 计算机软件是与计算机系统操作有关的程序、规程、规则及任何与之有关的文档及数据，即：计算机软件 程序 数据 文档 软件是逻辑产品而不是物理产品，因此软件在开发、生产、维护和使用等方面与硬件相比均存在明显的差异。4计算机软件的应用领域和类型 系统软件 实时软件 嵌入式软件 科学和工程计算软件 事务处理软件 人工智能软件 个人计算机软件 上述分类存在交叉5（2）软件危机 大型软件开发项目经常出现预算超支、软件交货时间延迟、软件质量差、维护困难、在软件维护过程中很容易引进新的错误、软件的可移植性差、软件很少能够复用等问题；工业界为维护软件支付的费用甚至占全部硬件和软件费用的40%
2、75%；许多重要的大型软件开发项目在耗费了大量的人力和财力之后，由于离预定目标相差甚远不得不宣布失败。6软件危机的原因（1/2）用户对软件需求的描述不精确，可能存在遗漏、二义性、错误等。甚至在软件开发过程中，用户还提出修改软件功能、界面、支撑环境等方面的要求，导致需求不断变化。软件开发人员对用户需求的理解与用户的本来愿望有差异，这种差异必然导致开发出来的软件产品与用户要求不一致。大型软件项目需要组织一定的人力共同完成，但多数管理人员缺乏开发大型软件系统的经验，而多数软件开发人员又缺乏管理方面的经验。各类人员的信息交流不及时、不准确，有时还会产生误解。7软件危机的原因（2/2）软件项目开发人员不
3、能有效地、独立自主地处理大型软件的全部关系和各个分枝，因此容易产生疏漏和错误。缺乏有力的方法学和工具方面的支持，过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件产品的个性化。软件产品的特殊性和人类智力的局限性，导致人们无力处理“复杂问题”。一旦人们采用先进的组织形式、开发方法和工具提高了软件的开发效率和能力，新的、更大更复杂的问题又摆在人们面前。8（3）软件工程的概念 软件工程的定义有不同的表述方式，典型的定义包括：软件工程是将系统的、规范的、可度量的方法应用于软件的开发、运行和维护过程，以及对上述方法的研究。软件工程是用工程、科学和数学的原则与方法，研制、维护计算机软件的有关技
4、术及管理方法。9软件工程的要素 方法软件工程 工具 过程10（4）软件工程的目标与原则 目标：可修改性 有效性 可靠性 可理解性 可维护性 可复用性 可适应性 可移植性 可追踪性 11软件工程的原则 抽象（Abstraction）信息隐藏（Information Hiding）模块化（Modularity）局部化（Localization）一致性（Consistency）完全性（Completeness）可验证性（Verifiability）1213软件生存周期可行性研究需求分析概要设计详细设计软件构造单元测试集成测试确认测试使用与维护退役14“V-模型”可行性研究需求分析概要设计详细设计软件
5、构造软件的使用确认测试集成测试单元测试1516软件开发过程模型 软件生命周期包含了软件从概念形成到最终退役的所有活动，而对于一个具体的软件项目，开发人员更加关注的是开发过程中包含的活动以及其具体安排。软件开发过程模型给出了软件开发中各个活动之间的关系，它是软件开发过程的概括，是软件工程的重要内容。能为软件工程管理提供里程碑和进度表，为软件开发过程提供原则和方法。17（1）瀑布模型可行性研究需求分析概要设计详细设计软件构造单元测试集成测试确认测试使用与维护18（2）快速原型模型初步需求分析快速设计构造原型用户评估原型（新需求）原型改进产品开发开始结束19（3）螺旋模型20统一软件开发过程RUP2
6、122设计的定义描述某个事物如何被制造出来的图样或模式；形成上述图样或模式的艺术；对人造产品中组成部分的一种安排，将对产品在实践中的可用性具有影响；人的头脑中的一种规划；等等。软件设计就可以看作是“对软件将如何被开发出来的一种描述”。如果把设计作为一个动词，那么软件设计就是“得到这种描述的活动或过程”。23（1）软件设计的重要性 软件设计是对软件需求的直接体现 软件设计为软件实现提供直接依据 软件设计将综合考虑软件系统的各种约束条件并给出相应方案 软件设计的质量将决定最终软件系统的质量 及早发现软件设计中存在的错误将极大减少软件修复和维护所需的成本 24（2）软件设计的特征 软件设计的开端是出
7、现某些新的问题需要软件来解决 软件设计的结果是给出一个方案 软件设计包含一系列的转换过程 产生新的想法或思路对软件设计非常重要 软件设计的过程是不断解决问题和实施决策的过程 软件设计也是一个满足各种约束的过程 多数软件设计是一个不断演化的过程 25（3）软件设计的要素 目标描述 设计约束 产品描述 设计原理 开发规划 使用描述 软件设计过程实际上就是逐渐形成这些要素的过程，而不同的软件开发方法可能会通过不同的方式和技术来达到该目标。一个良好的软件设计结果应该包含对上述要素的准确描述。2627（1）软件体系结构的定义 什么是体系结构：建筑的艺术或科学，特别是在考虑美感和实用因素的情况下，设计人类
8、使用的大型建筑物所需的技巧和实践。建筑风格，建筑物、组织机构、结构的一种样式、规矩或风格。体系结构的特征 体系结构是一种对复杂系统的抽象表示。体系结构是复杂系统的一种结构化模型，描述其组成部件及部件之间的关系。体系结构是具有特定工程目标的模型。28软件体系结构的定义 软件体系结构是软件系统的结构，包含软件元素、软件元素外部可见的属性以及这些软件元素之间的关系。软件体系结构是软件系统的基本组织，包含构件、构件之间、构件与环境之间的关系，以及相关的设计与演化原则。软件体系结构的风格（style）描述某一特定领域中系统组织方式的惯用模式，反映了领域中众多系统所共有的结构和语义特性。29（2）软件体系
9、结构的发展历程 1970年代中后期，随着结构化软件开发方法的出现与广泛应用，软件开发中出现了概要设计与详细设计，为将来软件体系结构的出现和发展建立了基础，到1990年代，面向对象技术已成为软件开发的主流技术，对大型软件系统进行设计、开发和维护的需要促使人们从更高的抽象层次关注软件，软件体系结构也在这一阶段得到广泛关注。1990年代后期，基于构件的软件开发逐渐受到重视和推广，软件体系结构已经作为一个明确的文档和中间产品存在于软件开发过程中。30（3）软件体系结构的内容 软件体系结构的描述 软件体系结构的设计方法 软件体系结构的分析方法 软件体系结构的复用 3233（1）UML的发展历程 多种面向
10、对象分析与设计方法的存在不利于面向对象方法的发展，也给用户的选择带来一些困惑。1994年Booch和Rumbaugh首先将各自先前的研究成果统一起来，于1995年10月发布了UM 0.8 经过Booch、Rumbaugh和Jacobson三人的共同努力，于1996年发布UML 0.9，并从此将UM命名为UML。UML结束了“模型论战”，融合了众多优秀的面向对象建模方法以及软件工程方法，消除了因建模方法相互独立带来的诸多不便。34UML 2.0 对象管理组织（Object Management Group，OMG）采纳UML作为其标准建模语言，并通过严格有序的OMG过程对其进行修订和维护。200
11、3年6月宣告完成了UML 2.0：Infrastructure（底层结构）Superstructure（上层结构）OCL（对象约束语言）Diagram Interchange（图形交换）35UML 2.0与MDA UML 2.0另一个显著特征就是加强了对模型驱动体系（Model Driven Architecture，MDA）的支持。MDA的目标是要实现从UML模型到最终代码的自动化生成，它将系统功能规范与该功能在某个特定平台上的实现规范分开，由同一个基础模型可以为不同的中间件平台产生应用程序。由于UML 2.0便于为不同领域（如金融、航空和通信等领域）、不同的平台（如COBRA、J2EE、.
12、NET）、不同的开发方法和开发过程（如RUP、Agile敏捷方法）定制UML方言，从而有利于模型驱动的软件开发。36（2）UML的特点和用途 为使用者提供了统一的、表达能力强大的可视化建模语言，以描述应用问题的需求模型、设计模型和实现模型。提供对核心概念的扩展机制，用户可加入核心概念中没有的概念和符号，可为特定应用领域提出具体的概念、符号表示和约束。独立于实现语言和方法学，但支持所有的方法学，覆盖了面向对象分析和设计的相关概念和方法学。独立于任何开发过程，但支持软件开发全过程。提供对建模语言进行理解的形式化基础，用元模型描述基本语义，OCL描述良定义规则，自然语言描述动态语义。增强面向对象工具
13、之间的互操作性，便于不同系统间的集成。支持较高抽象层次开发所需的各种概念，如协同、框架、模式和构件等，便于系统的重用。37（3）UML 2.0的建模机制 结构建模：类图 包图 对象图 构件图 组合结构图 部署图行为建模：行为建模：活动图活动图顺序图顺序图通信图通信图交互概览图交互概览图时序图时序图状态图状态图用例图用例图38UML 2.0的建模机制3940面向对象方法 面向对象方法的基础在于观察到客观世界中的应用问题都是由实体及其相互关系构成的，那么显然可以将客观世界中与应用问题有关的实体（包括其属性和操作）抽象为问题空间中的对象。面向对象开发方法通过提供对象、对象间消息传递等语言机制让软件开
14、发人员在解空间中直接模拟问题空间中的对象及其行为，从而削减了语义断层，拉近了问题空间与解空间的距离，从而简化了软件工程师为问题寻找解的工作，并为软件开发活动提供了直观、自然的语言支持和方法学指导。41（1）基本概念 对象 类 继承 聚集 多态 消息面向对象=对象+类+继承+聚集+多态+消息 42（2）面向对象方法的优势 简化软件开发过程 支持软件复用 改善软件结构 4344结构建模 结构建模常常也被称为静态建模，主要用来描述系统中包含的元素以及元素之间的关系。结构建模中的视图可以对各个层次和阶段的软件进行刻画，例如软件设计、软件实现、系统部署等等。这些模型对系统的逻辑结构或物理结构进行描述，并
15、不涉及系统的动态行为和过程。UML 2.0中的结构建模包括类图、包图、对象图、构件图、组合结构图和部署图 45（1）类图 类图是UML中最基本、也是最重要的一种视图，它用来刻画软件中类等元素的静态结构和关系。面向对象软件的最终实现体现为多个类的实现与组织，因此类图与面向对象软件实现之间的映射最为直观，对软件结构的设计至关重要，是软件实现要遵循的主要规格说明。46类47抽象类48接口49依赖关系 两个类之间存在依赖关系，表明一个类使用或需要知道另一个类中包含的信息。50关联关系 两个类之间存在关联关系，表明这两个类的实例之间存在语义上的联系。51整体部分关系 聚集关系 构成关系52泛化（继承）关
16、系53实现关系 实现关系表示一个元素是对另一个元素的实现 54关联类 关联类用来记录与关联有关的信息，提供与关联有关的操作。55（2）包图 包图在UML中可以看作是类图的一部分。包用来对一组元素进行划分，是对复杂模型的一种分而治之的层次划分，因此也常常用来描述一个复杂系统逻辑上的子系统划分。56包57导入关系58合并关系59（3）对象图 对象图可以看作类图的实例，对象之间的连接（link）是类之间关联关系的实例。60（4）构件图 由于基于构件的软件开发日益受到重视，UML 2.0对构件图进行较大的改进。构件的根本特征在于它的封装性和可复用性，其内部结构被隐藏起来，只通过接口向外部提供服务或请求
17、外部的服务。通过明确构件对运行环境的假设（即接口定义），可以将构件封装起来，尽可能的独立，从而为复用提供支持。构件图用来描述系统中存在的构件、构件具有的接口、以及各个构件怎样通过接口连接起来形成一个完整的系统。61构件62接口 提供接口（Provided Interface）需求接口（Required Interface）63装配连接子 把一个构件的服务和另一构件的需求连接起来 64委托连接子 把复杂构件的外部接口与内部子构件的接口映射起来 65（5）组合结构图 组合结构图通过内部结构、端口、协作等概念来描述复杂系统在运行时，系统、对象、协作实例等元素之间的结构关系。组合结构图中可以使用类图、
18、对象图、构件图中的有关图元，但也有自己独特的建模元素，66组合结构图中的端口67组合结构 组合结构图可用来描述系统及其组成部分，组成部分的描述类似于对象图中的对象，但组合结构图可以说明该部分属于哪个系统。68协作 组合结构图能够描述表示系统功能行为的协作（Collaboration）及其内部的实现结构，并且协作可以实例化，69（6）部署图 部署图用来描述软件开发过程中生成的物理文件形式的软件或信息、运行平台中的物理节点和通信，以及软件文件到相应硬件节点的部署或映射。7071行为建模 行为建模也常被称为动态建模，它主要用来刻画系统中的动态行为、过程和步骤。UML行为建模中提供的视图可以从不同侧面
19、来描述软件系统的动态过程，结构建模对系统中的元素及其关系进行描述，而行为建模对这些元素完成特定任务的过程进行描述，两者相互结合就能够完整地描述整个系统的特征。72（1）活动图 活动图主要描述一个系统行为的执行过程或步骤，它的适用范围非常广泛，能够用来描述工作流、过程流、算法步骤等从问题域到解空间的任何能够用流的形式描述的行为，可以用于概念层、设计层、实现层等不同抽象层次的系统行为建模。73活动和动作 活动是包含一组动作的行为，动作是活动中的一个步骤。74对象节点 为了增强对活动的表达能力，活动图还有一些特殊的节点，以表示活动的输入、输出，以及动作之间传递的复杂对象。75控制节点 在实际的活动流
20、程中，会经常出现分支选择情况。还有可能执行完一个动作后，下面需要同时开始执行几个流程，或几个流程完成后汇总为一个流程。76泳道 为了能够把动作按照执行该动作的对象进行划分，以明确活动中各个参与者的相应职责，活动图引入了泳道的概念。77（2）顺序图 顺序图用来描述对象之间动态的交互关系，主要强调完成某个场景的对象之间存在哪些消息传递以及消息的时间序。对象间的通信表示为对象生命线之间的消息传递，消息有简单消息、同步消息、异步消息等类型。消息有消息名，还可以有参数标识，可以用条件表达式表示消息发送的条件。78简单顺序图79交互操作 使用交互片段（Interaction Fragment）和片段组合（
21、Combined Fragment）对复杂交互进行建模。多个交互片段通过交互操作（Interaction Operator）组合成为一个复杂的交互图：ref,alt,opt,par,loop,critical,neg,assert,strict,seq,ignore,consider,break80（3）通信图81（4）交互概览图 交互概览图通过类似于活动图的方式，描述交互之间的流程，给出交互控制流的概览。在交互概览图中，节点不像活动图中那样是动作，而是一个交互图或对交互图的引用。82（5）时序图 时序图用来表示交互中关于消息时间的描述，并描述对象在生命线中，其所处状态或条件随着消息发生的变化
22、。83时序图的紧凑形式84（6）状态图 状态图使用有穷状态变迁图的方式刻画系统或元素的离散行为，可以用来描述一个类的实例、子系统甚至整个系统的在其生命周期内，所处状态如何随着外部激励而发生变化。在UML 2.0中，状态图又分为行为状态机和协议状态机，前者描述一个建模元素的行为（例如对象），而后者描述一个协议的行为。85状态与迁移 状态指所描述的元素在其生命周期中可位于一种相对稳定的位置，状态一般会（隐含）满足一组条件。状态之间存在迁移，即从一个状态变化为另一个状态。86状态图87复合状态 复合状态可以用来对状态进行层次划分，使得状态图具有良好的结构，并且易于理解。OR状态 AND状态88复合状
23、态89伪状态 伪状态是一些特殊的状态：初始状态和终止状态 选择（Choice）入口点（Entry）出口点（Exit）分岔（Fork）汇合（Join）深度历史（Deep History）浅度历史（Shallow History）90（6）用例图 用例图通常被用来描述系统的需求，从用户的角度对系统的功能视点进行建模。一个用例表示系统的一个特定功能，是用户与系统之间一次典型交互，能引发系统执行一系列动作，并且动作执行的结果能被用户（或外部实体）觉察到。用例图刻画了系统包含哪些用例以及用例之间、用例与外部角色之间的关系。91用例与参与者92用例之间的关系 包含关系（include）扩展关系（exten
24、d）9495软件设计 软件设计主要针对需求分析过程得到的软件需求规格说明，综合考虑各种制约因素，探求切实可行的软件解决方案并最终给出方案的逻辑表示，包括文档、模型等。软件设计基本概念是过去数十年里陆续提出的，软件设计者根据这组概念进行设计决策。96（1）抽象与逐步求精“抽象”是一个心理学概念，它要求人们将注意力集中在某一层次上考虑问题，而忽略那些低层次的细节。“逐步求精”可视为一种早期的自顶向下设计策略，其主要思想是，针对某个功能的宏观描述用逐步求精的方法不断地分解，逐步确立过程细节，直至该功能用程序语言描述的算法实现为止。在软件设计过程中，抽象与逐步求精是一般都是结合起来进行应用。97抽象与
25、逐步求精98（2）模块化与信息隐藏 把软件划分为可独立命名和访问的部件，每个部件称为一个模块，当把所有模块组装到一起时则获得满足问题需要的一个解。模块化使得开发活动更加简单的一个重要因素是模块的信息隐藏，即一个模块的开发者不必看到其它模块的内部，只需知道其接口即可，这使得每个模块的开发人员所要处理的复杂性显著降低。99模块数量与成本100内聚与耦合 内聚是前述信息隐藏和局部化概念的自然扩展，它标志一个模块内部各成分彼此结合的紧密程度。耦合是对软件结构中模块间关联程度的一种度量。耦合的强弱取决于模块间接口的复杂性、进入或调用模块的位置以及通过接口传送数据的多少等。追求高内聚、低耦合。101102
26、（1）软件设计的一般过程 软件设计可能是一个多次反复的过程，所以，软件设计一般都可以被看作是迭代的过程。迭代有两层含义：第一层含义是，针对给定的需求模型，通过多次从抽象到具体的设计过程，得出足够精细的设计模型以供软件实现之用。在需求模型发生变化并更新完成后，第一层含义的设计过程再随之展开，直至获得最终的目标软件产品。103软件设计的迭代104软件设计的一般过程105（2）软件设计的主要活动 在设计过程中，对设计活动进行计划应该最早进行，然后按照计划实施体系结构设计、界面设计、模块/子系统设计、数据模型设计、过程/算法设计等活动。1061）软件设计计划 软件设计计划的任务是：明确设计过程的输入制
27、品并使其处于就绪状态，定义设计过程的目标、输出制品及其验收准则，确定覆盖设计过程中各个阶段的全局性设计策略，分配设计过程相关人员的职责，针对设计过程中的活动制订工作计划。1072）体系结构设计 软件体系结构设计的目标是建立软件系统的体系结构，有时也称“顶层架构”。这种架构既要明确定义软件各子系统、关键构件、关键类的职责划分及协作关系，同时也要描绘它们在物理运行环境下的部署模型。此外，顶层架构还必须针对软件系统全局性、基础性的技术问题给出技术解决方案，这种方案往往构成目标软件系统的体系结构的技术基础设施。108软件结构有关概念1093）界面设计 用户界面设计的目标是，为用户使用目标软件系统以实现
28、其所有业务需求而提供友好的人机交互界面。软件界面设计需要考虑以下因素：适用于软件功能 易理解性 一致性 灵敏性 容错性 人性化 国际化 个性化 合理的布局 和谐的色彩 1104）模块/子系统设计 子系统和模块的区别：一个子系统独立构成系统，不依赖其它子系统提供的服务。一个模块通常是一个能提供一个或多个服务的系统部件。它能利用其它模块提供的服务，一般不被看成一个独立的系统。由于模块和子系统都是软件组成部分，它们一般都有层次结构，相互之间存在接口，其设计方法有很多类似的方面，因此我们统一称为模块设计。111模块设计的目标 模块设计的目标是，确定模块的具体接口定义，并设计模块的内部结构，即，设置包含
29、于其中的（更小粒度的）模块、构件和设计类，明确它们之间的协作关系，确保它们能够协同实现高层模块接口规定的所有功能和行为。在进行模块设计时，要尽量保持模块的功能独立性，遵循“高内聚、低耦合”的设计思想。此外，还要力求将模块的影响限制在模块的控制范围内，使得软件日后的修改和维护工作更加简单。1125）过程/算法设计 过程/算法设计的任务就是对模块内部的工作和执行过程进行描述，给出有关处理的精确说明，例如事件的顺序、确切的决策位置、循环操作以及数据的组成等。软件结构与软件过程相互关联，软件结构中任何模块的所有从属模块必将被引用出现在该模块的过程说明中。因此，软件过程对应的结构设计亦构成一个层次结构。
30、1136）数据模型设计 我们把数据结构设计、数据库设计、甚至数据文件设计等统一称为数据模型设计。在数据模型设计中有一个重要概念：持久数据操作，它包括写入、查询、更新和删除四类基本操作以及由它们复合而成的业务数据操作。在很多软件系统中，数据是其核心，因此，对数据元素的格式、结构、访存、表示等机制进行良好建模和优化，是提高软件设计质量和系统性能的基础，对软件系统的应用具有重要意义。114115软件设计质量的重要性 软件设计是软件开发过程中的核心活动，软件设计的质量不但对最终软件产品的质量起着决定性作用，还对软件开发过程以及软件日后在使用过程中维护的难易程度有着重要的影响。高质量的软件设计，能够有效
31、缩短软件开发时间，减少开发成本，提高最终软件产品质量。116软件设计的质量要素 结构良好 充分性 可行性 简单性 实用性 灵活性 健壮性 可移植性 可复用性 标准化117118（1）软件体系结构设计方法概述 软件体系结构的设计方法是指通过一系列的设计活动，获得满足系统功能性需求、并且符合一定非功能性需求约束的软件体系结构模型。目前存在多种体系结构设计方法，它们的侧重点有所不同。在实际应用过程中，这些体系结构设计方法并不是绝对互斥的，根据需要，有可能综合运用不同体系结构设计方法的思想，得到最终所需的设计结果。1191）多视图建模1202）基于评估与转换的设计方法121转换方式 使用合适的体系结构
32、风格和模式，或者设计模式来改进体系结构设计。把非功能需求转化为功能性解决方案，该功能性方案可以与问题域无关，但可以满足质量属性的要求。采用“分而治之”的方式，可以把系统级的质量需求分配到子系统或模块中，或者把质量需求分解为多个与功能相关的质量需求，分解后的质量需求能够比较容易得到满足。1223）模式驱动的设计方法123体系结构风格的分类体系结构风格分类独立构件体系结构数据流体系结构数据为中心的体系结构虚拟机体系结构调用与返回体系结构1244）领域特定的软件体系结构设计 领域特定的软件体系结构（Domain Specific Software Architecture，DSSA）是领域工程的核心
33、部分，领域工程分析应用领域的共同特征和可变特征，对刻画这些特征的对象和操作进行选择和抽象，形成领域模型，并进一步生成DSSA。领域特定的软件体系结构借鉴领域中已经成熟的软件体系结构，实现解决方案在某个领域内的复用。虽然这些系统实例的细节会有不同，但共同的体系结构在开发新系统时是能够复用的。125DSSA与体系结构风格的区别 DSSA与软件体系结构风格是从不同角度出发研究问题的两种结果，前者从问题域出发，而后者从解决域出发。DSSA只在某个特定领域中进行经验知识的提取、总结与组织，但可以同时使用多种软件体系结构风格；而一种软件体系结构风格所呈现的公共结构和设计方法可以扩展到多个应用领域。DSSA
34、的体系结构表示和工具一般只适用于一个较小的范围，在其它领域中是不适用并难以复用的。1265）软件产品线方法 软件产品线指一组具有公共的、可管理特征（系统需求）的软件系统，这些系统满足特定的市场需求或者任务领域需求，并且按照预定义的方式基于公共的核心资产（Core Assets）集合开发得到。软件产品线主要由两部分组成：核心资产库 产品集合127软件产品线过程模型128新产品形成步骤从公共资产库中选取合适的构件；使用预定义的变化机制进行裁剪，如参数化、继承等；必要时增加新的构件；在整个产品线范围内共同的体系结构指导下，进行构件组装，形成系统。1296）其它软件体系结构设计方法 基于目标图推理的体
35、系结构设计方法 基于属性的体系结构设计方法 一些常用的软件开发方法学中也包含了软件体系结构的设计，例如：面向数据流的软件开发方法 面向对象的软件开发方法 面向方面的软件开发方法 130（2）软件体系结构设计步骤1.开发软件顶层架构 2.搜索并选取可用设计资产 3.设计技术支撑方案 4.确定设计元素 5.开发软件部署模型 6.设计并发机制 7.构建软件体系结构模型 8.评审软件体系结构模型 131132（1）可信软件的特点 计算机系统的缺陷很大一部分是由于软件的问题引发的。纵观软件应用的发展历史，国际上由于软件可信性问题所导致的重大灾难、事故和严重损失屡见不鲜，软件的可信性问题已经成为一个相当普
36、遍的问题。所谓“可信软件”，是指软件系统的运行行为及其结果总是符合人们的预期，且在受到干扰（包括操作错误、环境影响、外部攻击等）时仍能提供连续的服务。133可信属性 可靠性（Reliability）：在规定的环境下和规定的时间内，软件无失效运行的概率；可靠安全性（Safety）：软件运行不引起危险、灾难的能力；保密安全性（Security）：软件系统对数据和信息提供保密性、完整性、可用性、真实性保障的能力；可生存性（Survivability）：软件在受到攻击或失效出现时连续提供服务并在规定时间内恢复所有服务的能力；实时性（Real Time）：软件在指定的时间内完成反应或提交输出的能力。13
37、4成本可信曲线135（2）容错设计 为了保证高可信系统即使在极端条件下也能按其规格说明执行，对硬件和软件同时采用容错计算非常重要。为了保护软件免受软件故障的影响，软件逻辑和数据也必须被备份。软件容错设计是使得软件能发现失效危险并从临失效状态恢复的软件设计技术，有两种主要的软件容错设计方法：恢复块（Recovery Blocks）N-版本（N-version）编程 1361）恢复块技术1372）N-版本编程138设计多样性 当不同的开发者采用不同方法实现相同的需求时，一个合理的假设是不同版本的软件不大可能包含相同的缺陷，因此，也就不会产生相同的失效。设计多样性可以通过以下多种方式达到：使用不同的
38、设计方法来实现需求。使用不同的程序设计语言来完成实现。使用不同的开发工具，且在不同的开发环境中完成。明确要求在实现某些关键过程时使用不同的算法。139（3）软件失效模式和影响分析 软件失效模式和影响分析（Failure Model and Effects Analysis，FMEA）主要是在软件开发阶段的早期，通过识别软件失效模式，研究分析各种失效模式产生的原因及其造成的后果，寻找消除和减少其有害后果的方法，以尽早发现潜在的问题，并采取相应的措施，从而提高软件的可靠性和安全性。140相关概念 软件失效（software failure）。软件失效就是泛指程序在运行中丧失了全部或部分功能、出现偏
39、离预期的正常状态的事件。软件失效模式（software failure mode）。软件失效模式是指软件失效的不同类型，通常用于描述软件失效发生的方式以及对设备运行可能产生的影响。软件失效的影响（software failure effect）。软件失效的影响是指软件失效模式对软件系统的运行、功能或状态等造成的后果。141软件系统级FMEA过程142（4）软件故障树分析 软件故障树分析（Fault Tree Analysis，FTA）就是在软件系统设计过程中，通过对可能造成系统故障的各种因素（包括硬件、软件、环境、人为因素等）进行分析，画出逻辑框图（即故障树），从而确定系统故障原因的各种可能组
40、合，采取相应的纠正措施，提高系统可靠性的一种设计分析方法。143故障树的构造过程 广泛收集并分析有关技术资料 选择顶事件 生成故障树 简化故障树144（5）形式化方法 形式化方法是关于在计算系统的开发中进行严格推理的理论、技术和工具，它主要包括形式规约技术（Formal Specification）和形式验证技术（Formal Verification）。形式规约技术使用具有严格数学定义语法和语义的语言刻画软件系统及其性质，可以尽早发现需求和设计中的错误、歧义、不一致和不完全。形式化验证是在形式化规约的基础上建立软件系统及其性质的关系，即分析系统是否具有所期望性质的过程，主要分为两类：模型检验
41、（Model Checking）和定理证明（Theorem Proving）。145形式化方法 模型检验技术是通过搜索待验证软件系统模型的有穷状态空间来检验系统的行为是否具备预期性质的一种有穷状态系统自动验证技术。定理证明技术是将软件系统和性质都用逻辑方法来规约，基于公理和推理规则组成的形式系统，以如同数学中定理证明的方法来证明软件系统是否具备所期望的关键性质。146（6）净室方法 净室软件工程（Clean-room Software Engineering）将形式化方法的规范、设计和验证与可靠性认证的统计测试有效地结合起来。它将软件开发视作严格的工程化开发，软件的正确性是通过数学上可靠的设计
42、方法来保障。147净室软件工程的要点 在统计质量控制下的增量式开发。基于数学原理的软件开发。基于统计原理的软件测试。148（7）嵌入式和实时软件设计 按照IEEE的定义，嵌入式系统是作为某个更大规模系统组成部分之一的计算机系统，按照其所属系统的某些要求来进行执行。一般说来，嵌入式系统是计算机软件与硬件的综合体，通常具有专用的功能，并作为某个设备或机器的组成部分，用来控制、监测、辅助其运作。嵌入式系统已经普遍应用在与人类生活密切相关的各种电子产品、电器中，并在航空、汽车等领域的控制系统中起到关键作用。149嵌入式软件的特征 嵌入式软件一般用于单一任务。嵌入式软件有多种类型的处理器体系结构支持。嵌
43、入式软件的资源约束更加严格。嵌入式软件需要更高的可靠性和安全性。嵌入式软件对反应性和实时性要求很高。嵌入式软件通常固化存储。150嵌入式系统的设计过程阶段一：产品定义阶段二：软硬件划分阶段三：软件设计与硬件设计阶段四：软硬件集成阶段五：产品测试与发布阶段六：维护与升级软件设计过程硬件设计过程151嵌入式系统中的一般软件结构152无操作系统的嵌入式软件设计 前后台系统 中断（事件）驱动系统 巡回服务系统 基于定时器的巡回服务系统 153有操作系统的嵌入式软件设计 分时系统 实时系统 非抢占式系统 抢占式系统 154155软件设计规格说明 软件设计过程中的各个活动的结果最终应该文档化，形成正式的软
44、件设计规格说明，作为软件设计的输出。形成的软件设计规格说明将被评审，并作为后续软件实现活动的依据。软件设计规格说明并没有统一的格式，例如IEEE标准、ISO标准以及我国的国家标准、各行业标准所建议的格式都不尽相同。使用不同的软件设计方法学所得到的设计模型也会有很大区别，导致设计规格说明的结构也会明显不同。156157设计评审 设计评审的目标是，确保设计规格说明书能够实现所有的软件需求，及早发现设计中的缺陷和错误，并确保设计模型已经精化到合格的软件实现工程师能够构造出符合软件设计者期望的目标软件系统。评审分正式与非正式两种方式。158设计评审关注的内容设计模型是否能够充分地、无遗漏地支持所有软件
45、需求的实现；设计模型是否已经精化至合理的程度，可以确保合格的软件实现工程师能够构造出符合软件设计者期望的目标软件系统；设计模型的质量属性，即，设计模型是否已经经过充分的优化，以确保依照设计模型构造出来的目标软件产品能够表现出良好的软件质量属性。159设计评审的原则 对产品进行评审，而不是开发人员。要有针对性，不要漫无目的。进行有限的争辩。阐明问题所在，但不要试图去解决问题。要求事先准备，如果评审人没有准备好，则取消会议并重新安排时间。为被评审的产品开发一个检查表。确定软件元素是否遵循其规格说明或标准，记录任何不一致的地方。列出发现的问题、给出的建议和解决该问题的负责人。坚持记录并进行文档化。1
46、61162基于UML的分析与设计 UML是独立于软件开发过程的，它几乎可以用于任何类型的软件开发过程，包括瀑布式、迭代式、螺旋式等不同模型。在软件分析和设计中，可以根据项目的特征、开发组织在已有实践中定义的相关规范、设计人员本身的偏好等因素，对基于UML的软件设计过程进行定制。163基于UML的分析与设计过程164165案例：银行ATM自动柜员机的需求简述 本案例将要开发的ATM系统能够为顾客提供以下基本服务（它们统一称为交易）：取款服务。顾客可以用银行卡从对应的账户中支取现金，现金必须是100元的整数倍，且每次取款不能超过2000元。存款服务。顾客可以把现金存入与银行卡对应的账户中。转帐服务
47、。顾客可以把一个银行卡对应的账户中的款项转帐到另一个银行账户中。查询服务。顾客能够查询一个银行卡对应的账户中的余额。166（1）确定用例 采用用例模型描述系统需求时，首先需要开发人员从业务需求描述出发获取参与者（Actor）和场景，对场景进行汇总、分类、抽象，形成用例。场景是从单个参与者的角度观察目标软件系统的功能和外部行为，这种功能通过系统与用户之间的交互来表示。场景是用例的实例，而用例是某类场景的共同抽象。167获取场景目标软件系统有哪些参与者？参与者希望系统执行的任务有哪些？参与者希望获得哪些信息？这些信息由谁生成？由谁修改？参与者需要通知系统哪些事件？系统响应这些事件时会表现出哪些外部
48、行为？系统将通告参与者哪些事件？168定义用例 在场景确定之后，通过对场景的汇总、分类归并、抽象即可形成用例。需要特别注意的是，参与者并只限于人员，其它与目标软件发生交互的外部实体或系统也是参与者；用例应该是对参与者可见的系统需求或功能，否则不能作为用例。169ATM案例的参与者“顾客”（Customer）“操作管理人员”（Operator）“银行服务器”（Bank System）“读卡器”（Card Reader）“存款器”（Cash Acceptor）“取款器”（Cash Dispenser）“打印机”（Printer）170ATM案例的用例“取款”（Withdrawal）“存款”（Dep
49、osit）“转帐”（Transfer）“查询余额”（Inquiry）“开机”（System Startup）“关机”（System Shutdown）171（2）生成用例图 生成用例图是一个逐步精化的过程，首先可以建立初步的用例图，包括前面发现的参与者和用例；然后对用例图进行细化，定义用例之间“包含”、“扩展”、“继承”等关系，并可能需要定义新的用例，以能够更准确地使用用例图描述系统需求。172生成初步用例图173用例图的细化 包含（include）关系 扩展（extend）关系 继承关系 174细化后ATM用例图175（3）用例描述 对用例的完整描述包括用例名称、参与者、前置条件、一个主事件
50、流、0到多个辅事件流、后置条件。主事件流表示正常情况下参与者与系统之间的信息交互及动作序列，辅事件流则表示特殊情况或异常情况下的信息交互及动作序列。176“取款用例”描述用例名称：Withdrawal参与者：Customer，Bank System，Card Reader，Cash Dispenser，Printer前置条件：顾客已插入银行卡，密码验证正确，顾客按下“取款”按钮主事件流：1.顾客输入取款金额，并确认。2.系统认可取款金额，并发送指令给取款器。3.取款器把相应金额的现金送出。4.打印机打印回执。辅事件流：1.如果取款金额不是100的整数倍，则显示信息“输入金额必须是100的整数倍
