软件工程方法(精简版)资料

第一章系统工程与软件工程典型的软件开发方法了解各类软件开发方法的基本思想Parnas方法、面向数据结构、面向数据流、面向对象、基于构件、面向服务…软件工程过程了解软件工程过程的基本思想系统工程特点：系统性运用自然科学、管理科学理论对系统进行优化设计。即用数学模型和逻辑模型来描述系统，通过模拟系统行为、求得系统的最优组合方案和最优的运行方案。工程性 运用工程学原理，实施系统开发全过程管理，实现阶段性过程控制，达到软件开发和软件质量要求。工程实施过程文档的形式和管理符合通行标准。举例传送带分类系统该系统对零部件进行分类。每一个零部件上有一个条形码标识号，并在传送带末端分别送到六个箱子中。零部件以随机的顺序通过，且其间的距离相同建模准备零部件标识号的形式？其间的距离？到达频率？传送带的速度?末端可扩展空间？箱子的间距?错误标识？箱满情况？状态回传？出错率？进度和预算约束？建议方案方案一：人工完成方案二：条形码阅读器方案三：机器手寻求最优项目考虑：成本、进度效益分析：回报率、市场前景技术分析：技术可行性可用资源：人员、设备环境接口：内部、外部互联法律考虑：产权、风险软件工程学科范畴计算机科学和数学用于构造软件的模型与算法；工程科学用于制定规范、设计范型、评估成本以及确定权衡等；管理科学用于计划、资源、质量、成本等管理。软件开发的工程原则制订分阶段的项目计划;选取适宜的开发模型；采用合适的开发方法；合理配备开发小组人员；树立强烈的质量保证意识；不断改进软件过程。Parnas重要论述对于软件系统的设计和建造最重要的除数学基础（特别是数理逻辑）还有模块化设计、规范、抽象、信息隐藏等原则。软件学科的基础知识是计算机科学，就象电力工程的基础知识是物理学一样。但并不是每门计算机科学课程都与软件工程有关。过去三十多年以来，软件已经越来越成为一种产品，建造产品的学科应该是工程学科。面向数据结构的方法适用于小系统的程序设计方法JSP,它以数据结构作为开发程序的基础目标，采用逐步求精的思想构造中系统的程序结构。为满足大系统设计要求，Jackson又提出了系统开发方法JSD。特征：JSP运用三种基本结构及其组合表示数据结构，并据此导出程序结构。为保证数据之间一致性，JSP需要解决输入结构、输出结构的顺序冲突问题。JSD引入进程模型描述系统动态特征，通过模型中的进程与现实世界的实体联系起来，以确保模型行为和现实世界行为一致性。面向数据流的方法结构化方法，也称为面向功能的软件开发方法或面向数据流的软件开发方法。包括结构化分析(SA)、结构化设计(SD)、结构化程序设计(SP)。特征SA是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有解决方案为止。SD是根据分析成果构造软件结构，并基于模块化、自顶向下逐层细化，直到可实现模块设计为止。SP是从程序的控制结构入手，消除容易引起混乱的交叉跳转，并合理解决数据结构访问的规范化和标准化问题，直至能够编写出结构化的程序为止。结构化方法适合与瀑布模型结合。面向对象的软件开发面向对象技术就是基于对象概念，以对象为中心，以类和继承为构造机制，来认识、理解、刻画客观世界和设计、构建相应的软件系统。八十年代末，随着面向对象技术成为研究的热点出现了几十种支持软件开发的面向对象方法。统一建模语言UML综合了Booch,OMT,和Jacobson方法优点，被作为是一种通用表示。特征面向对象软件系统中的任何元素都是对象，复杂的软件对象由比较简单的对象组合而成。每个对象都归属于一个对象类，每个对象类都封装了一组数据和一组方法。若干对象类组成一个层次结构，下层的派生类继承上层的基类特性；低层的特性可屏蔽高层的同名特性（多态）。支持并发程序设计和迭代开发过程。基于构件的软件开发构件是指模块化的、可部署、可替换的软件系统组成部分,封装了内部的具体实现并对外提供一组接口。基于构件的软件开发(CBSD)通过整合已有的构件来完成大型软件系统的开发,其核心就是构件级的可重用。特征构件具有可重用性和互操作性，CBSD会增强系统可维护性、可扩展性；参数化框架使得系统适应性、灵活性增强。大粒度构件的重用使得平均开发费用降低,开发人员减少,开发速度加快。CBSD将软件实现从程序编写转移到了系统装配和整合，开发人员更能专注于对领域的了解和分析。支持业务与实现分离,逻辑与数据分离，使系统易于升级。线性顺序模型特点严格活动序列；严格阶段成果评审；不允许需求的不确定性；不显式支持活动迭代；要求用户极大的耐心；开发过程“阻塞”；RAD模型特点基于构件的快速线性开发；大型项目需要足够的人力组建足够的RAD组；要求较高的业务水平和开发水平；适合成熟领域的应用开发；模块划分的过分独立会带来性能的降低；演化过程模型——体现软件的变化特征，突出迭代思想——原型模型：以尽早占领市场为目的；可快速得到可演示版本；螺旋模型：不同版本、不同形式的不断进化；需要高水平的风险评估技术；并发开发模型：由用户要求、管理决策和评审结果驱动；每一个软件工程活动触发活动网络的状态变迁；形式化开发模型形式化方法分为形式化规约方法和形式化验证方法。形式化规约是通过具有明确数学定义的文法和语义的方法或语言对软件的期望特性或者行为进行的精确、简洁描述。形式化验证是基于已建立的形式化规约，对软件的相关特性进行评价的数学分析和证明。基于转换模型的软件开发过程形式化规约+形式化验证+求精或变换+规则集

第二章软件需求与需求规格说明结构化需求分析建模数据需求：实体关系图建模功能需求：数据流图建模行为需求：控制流图设计的基本思想数据抽象、过程抽象、逐步求精模块独立性、高内聚和低耦合结构化设计从数据流图构造软件结构过程设计技术：图形化、表格和语言工具实体关系图设计的基本思想数据抽象、过程抽象、逐步求精模块独立性、高内聚和低耦合结构化设计方法:基本原则:模块化、先集中再分权、先分解再整合,逐步求精基本思想:以结构化分析阶段所产生的文档(包括数据流图、数据字典和软件需求说明书)为基础,自顶向下,逐步求精和模块化的过程。结构化设计通常可分为概要设计和详细设计。概要设计的任务是确定软件系统的结构,进行模块划分,确定每个模块的功能、接口及模块间的调用关系。详细设计的任务是为每个模块设计实现的细节。

第三章面向对象的基本概念对象、类、抽象、封装、继承和多态、接口UML基础需求调研和需求分析需求调研方法构造用例图面向对象的分析分析类：边界类、控制类和实体类构造顺序图面向对象分析(OOA,Object-OrientedAnalysis)定义待解决问题的类(对象)、类之间相互关联和交互的方式、对象的内在结构和允许对象在一起工作的通信机制面向对象设计(OOD,Object-OrientedDesign)定义分析类在具体环境下的实现机制面向对象编程(OOP,Object-Orientedprogramming)利用面向对象的编程语言实现设计元素对象：定义：对象是由数据及其操作所构成的封装体特点每一个对象必须有一个名字以区别于其他对象(对象的标识Identity)；用状态来描述对象的某些特征(对象的状态State)；有一组操作，每一个操作决定了对象的一种行为(对象的行为Behavior)类：定义：类是对一组具有相同的属性、行为、关系和语义的对象的抽象描述类和对象的关系：对象是类的实例(Instance)，类是创建对象的模板，类是抽象的，对象是具体的属性(attributes)：类所知道的数据/信息，每个类的对象为其指定特定的值操作(operations)：类所拥有的“能力”，类的对象通过操作对外提供行为关系(relationships)：类与外界通信的”桥梁”类的属性和操作定义也取决于项目上下文，基于特定上下文对对象的特征和行为的抽象通过可见性支持封装：公有（+）私有（-）保护（#）包（~）抽象(Abstraction)抽象是通过特定的实例抽取共同特征后形成概念的过程，强调主要特征，而忽略次要特征，类即是对象的抽象封装(Encapsulation)是将相关的概念组成一个单元，然后通过一个名称来使用它，是软件模块化思想的体现实现信息隐藏和数据抽象，信息隐藏：对象的私有数据不能被外界存取，只能以合法的手段访问，将数据抽象为一组行为，而不是内部的具体数据结构，把用户隔离在细节之外继承(inheritance)表示类之间的层次关系，这种关系使得某类对象可以继承另外一个或多个对象的全部属性和操作，isa或iskindof关系，在UML中这种类间的关系称之为泛化(generalization)。单继承、多重继承接口和抽象类-抽象类抽象类：不能被实例化(生成任何对象)的类定义抽象类的两种方式：显示地声明为抽象的；类中至少定义了一个没有实现的操作抽象类主要是为了定义类的公共行为，与之对应的为具体类抽象类与继承父类可以是抽象类，也可以是具体类；处于继承关系底层的类，肯定是具体类接口是声明而不是实际的类，目的是显示地支持多态；没有属性，而且所定义的操作不能有任何实现；接口的实现有赖于和接口相连的具体类接口和抽象类的区别抽象类本质上是一个类，来自对象的抽象；而接口则更关注行为的抽象；接口不能有任何操作的实现，而抽象类的部分或全部的操作都可以拥有实现；接口类不能有属性，而抽象类可以多态一种在一个接口下隐藏不同实现的机制：多个类型（从相同的父类型中派生出来）可被当作同一种类型对待用父类代表多个子类，外部代码只访问父类运用多态性可以简化设计、使设计灵活采用继承或接口来支持多态多态性依赖于动态绑定机制实现，即在运行期间确定被执行的代码需求分析过程主要工作：获取需求：从非形式化的需求陈述中提取用户的实际需求，归纳、整理用户提出的各种问题和要求文档化需求：形成软件需求的文档化描述分析需求：采用软件观点表述需求需求获取的启发技术：1.对现有文档、表格和数据库进行抽样2.调研和实地访问3.观察工作环境4.调查表5.面谈6.原型7.联合需求计划从现有文档收集事实第一份文档：组织结构图：该项目的关键所有者和用户，以及他们之间的组织关系其它文档：产生这个项目的历史文档，收集并检查描述问题的文档；描述正被研究或设计的业务功能的文档；以前系统研究和设计文档调研和实地访问：全面研究问题领域：联系或实地考察对类似问题有经验的公司；通过互联网、计算机期刊杂志和参考书等获取相关信息；专业社团、工作组等提供了对相关问题的集中解决方案观察工作环境：系统分析员或者参与到活动中，或者观察他人执行活动来了解系统；为了获得对系统的理解，观察是一种有效的数据收集技术；当通过其它方法收集的数据有效性值得怀疑时，或者当系统某方面的复杂度妨碍了用户作出清晰的解释时，使用该技术；优点：收集的数据可能十分可靠；能够确切地明白要做什么：复杂的任务有时难以用语言解释，只能求助于观察；系统分析员可以进行工作度量缺点：人们在被观察时通常会觉得不舒服，可能会不自觉地表现得与平常不一样；效率较低，没有时间询问所有的问题，把每一点都弄清楚；有遗漏，有些任务可能在特定时间发生；观察只能反映当前状况，无法体现系统未来的状况调查表：调查表是一种具有特殊目的的文档，分析员使用它从回答者那里收集信息和观点，由一组用来收集信息的问题组成调查表的类型：自由格式调查表：为回答者提供了很大的回答范围，提出一个问题，回答者在问题后面提供的空白区填写答案固定格式调查表：由需要从预先定义的答案中工作选择的问题构成特点：能够得到用户的匿名回答；可能会受到用户态度的影响，具有主观性；对于大规模的调查，要考虑聘请经过专门培训的专业人员来设计调查问题和调查表，并分析问卷调查结果面谈系统分析员从个人那里通过面对面的交互收集信息，可以一对一，也可以多对多地进行特点：通过建立相互之间的友善关系，系统分析员能够给用户一种主动为系统项目作出贡献的感觉，并能够获得更多的反馈；面谈的成功极大地取决于系统分析员的人际关系能力非结构化面谈：仅用一个头脑中的一般目标或目的以及几个特定问题进行组织。面谈者指望被面谈者提供一个框架并引导谈话过程；涉及一般性问题，被面谈者可以引导谈话过程；常常会偏离主题，分析员要注意引导结构化面谈：面谈者有一套专门的问题询问被面谈者，根据被面谈者的回答，面谈者将提出额外的问题以获得澄清或进一步深入开放式问题：允许被面谈者以任何认为合适的方式回答封闭式问题：把回答严格限制在特定范围内，或限制为简短的直接回答选择被面谈者：与最终用户面谈，要事先预约，并获得其主管同意；被面谈者的管理级别越高，安排的面谈时间就应该越短；不要在同事或与被面谈者同级的人在场的情况下进行面谈准备面谈；制定面谈指南，明确面谈的问题进行面谈；有礼貌、仔细聆听、充分利用肢体语言面谈的后续工作；总结了面谈内容的备忘录，并反馈给被面谈者原型：为了发现或验证用户需求而构造那些需求的一个小规模的，有代表性的活动或初步的工作模型原型应该被快速地开发出来，并只对那些没有被清楚地理解的需求建立原型特点用户和开发人员获得对系统可能如何工作的一致理解，并可作为给用户的一种培训机制；有助于定义更稳定、更可靠的需求；用户可能基于原型的性能、可靠性和特征产生出不现实的预期；制作原型可能延长了开发进度并增加开发费用7.联合需求计划：是一个过程，其中高度结构化的小组会议被用来分析问题并定义需求JRP会议包括一些不同的参与者和角色，每个参与者都被期望能够参加并主动地参与整个JRP会议；主要包括：负责人、主持人、用户和管理人员、抄写员、IT职员总结：需求获取综合利用各种启发技术获取需求1.了解现有文档、表格、报告和文件，能在没有同任何人接触的情况下了解很多2.如果合适，观察工作中的系统3.根据已经收集到的所有事实，设计并分发调查表，澄清没有完全理解的事情4.进行面谈(或小组工作会议)，因为已经通过较少的用户接触收集了大部分相关事实，所有现在可以使用面谈来验证和澄清最困难的问题(可考虑用JRP代替或补充面谈)5.作为备选，对没有理解的功能需求或需要被验证的需求构造原型6.追查到底，使用合适的调查研究技术验证事实(面谈或观察)根据备选构架定义三类分析类边界类：系统及其参与者的边界控制类：系统的控制逻辑实体类：系统使用的信息

第六章软件复用和面向的软件开发面向构件的软件开发过程：鉴定、适配、组装和更新设计模式基本概念典型设计模式应用：策略、抽象工厂、组合和观察者构件级设计基本概念，构件和对象的区别和联系CBSD的产生背景：1）COTS(Commercial-Off-The-Shelf，商用现成品或技术”或“商用货架产品”）构件质量的提高和种类的增加；2）要求降低系统开发和维护成本的经济压力；3）构件集成技术的出现；4）软件开发组织内可以用于新系统开发的已有软件制品的数量增加。CBSD整个过程从需求开始，由开发团队使用传统的需求获取技术建立系统的需求规约。在完成体系结构设计后，并不立即开始详细设计，而是确定哪些部分可由构件组装而成。此时开发人员面临的设计决策包括:“是否存在满足某种需求的COTS构件”，“是否存在满足某种需求的内部开发的可复用构件”，“这些可用构件的接口与体系结构的设计是否匹配”等。对于那些无法通过已有构件满足的需求，就只能采用传统的或面向对象的软件工程方法开发新构件。Qualification（鉴定）通过接口以及其它约束判断COTS构件是否可在新系统中复用。构件鉴定分为发现和评估两个阶段。发现阶段需要确定COTS构件的各种属性，如构件接口的功能性（构件能够提供什么服务）及其附加属性（如，是否遵循某种标准）、构件的质量属性（如，可靠性）等。评估阶段根据COTS构件属性以及新系统的需求判断构件是否可在系统中复用。评估方法常常涉及分析构件文档、与构件已有用户交流经验、甚至开发系统原型。构件鉴定有时还需要考虑非技术因素，如构件提供商的市场占有率、构件开发商的过程成熟度等级等。Adaptation（适配）独立开发的可复用构件满足不同的应用需求，并对运行上下文做出了某些假设。系统的软件体系结构定义了系统中所有构件的设计规则、连接模式和交互模式。如果被复用的构件不符合目标系统的软件体系结构就可能导致该构件无法正常工作，甚至影响整个系统的运行，这种情形称为失配（mismatch）。——调整构件使之满足体系结构要求的行为就是构件适配。构件适配可通过白盒、灰盒或黑盒的方式对构件进行修改或配置。白盒方式允许直接修改构件源代码；灰盒方式不允许直接修改构件源代码，但提供了可修改构件行为的扩展语言或编程接口；黑盒方式是指调整那些只有可执行代码且没有任何扩展机制的构件。如果构件无法适配，就不得不寻找其它适合的构件。AbstractFactory（抽象工厂）提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类抽象工厂的优缺点：首先，抽象工厂的话，其可以更加方便的实现交换一个产品系列，就像上面的Demo中可以轻易的实现从Linux上转换为Windows，同时，客户端代码中依赖的是抽象，而非具体的实现，但是，抽象工厂也是有缺点的，其实这个缺点也很明显，那就是显得过于臃肿，上面的Demo尽管还只有两个产品族，类图就显得有些难看了，如果产品族一多的话，那么总的类数是成几倍的增加，这样使整个结构变得过于复杂，类的结构也会变得更为庞大。Composition（组装）构件必须通过某些良好定义的基础设施才能组装成目标系统。体系风格决定了构件之间连接或协调的机制，是构件组装成功与否的关键因素之一。典型的体系风格包括黑板、消息总线、对象请求代理等。Updation（更新）基于构件的系统演化往往表现为构件的替换或增加，其关键在于如何充分测试新构件以保证其正确工作且不对其它构件的运行产生副面影响，对于由COTS构件组装而成的系统，其更新的工作往往由提供COTS构件的第三方完成。设计模式：组合Composite意图：将对象组合成一种树结构，以表示部分—整体的层次关系。组合模式用于将单个对象有机地组合到一起。动机：一些部件对象经过组合构成的复合部件对象仍然具有单个部件对象的接口，这样的复合部件对象被称为“容器(container)”‘复合部件与单个部件具有同样的接口，所有接口包含两部分：单个部件的功能、管理子部件的功能；递归组合策略Strategy动机：定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。意图：有些算法对于某些类是必不可少的，但是不适合于硬编进类中。客户可能需要算法的多种不同实现，允许增加新的算法实现或者改变现有的算法实现我们可以把这样的算法封装到单独的类中，称为strategy观察者模式（Observerpattern）意图：定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。动机：1.把系统分成一些相互关联的类或者对象，如何维护这些类的实例一致性？--不希望为了维护一致性而使各类紧密耦合。2.这一模式中的关键对象是目标(subject)和观察者(observer)。一个目标可以有任意数目的依赖它的观察者。一旦目标的状态发生改变,所有的观察者都得到通知。作为对这个通知的响应，每个观察者都将查询目标以使其状态与目标的状态同步。3.这种交互也称为发布－订阅(publish-subscribe)。目标是通知的发布者。它发出通知时并不需知道谁是它的观察者。可以有任意数目的观察者订阅并接收通知

传统构件设计过程设计的基本方法数据库设计数据模型基本概念数据库设计基本原理：数据完整性、函数依赖和三个范式用户界面设计对象设计用例设计和类设计细节应用设计模式完善类设计构件级设计则针对系统各组成部分建立其程序和数据结构，从而将设计模型转换为运行软件可以采用编程语言来表示构件级设计但对一些复杂场景，应该采用能够容易转化为代码的中间表示进行构件级设计构件：是计算机软件中一个模块化的构造块结构化观点(传统构件设计)：构件是程序的功能要素，包括：处理逻辑、实现处理逻辑所需的内部数据结构、保证构件被调用和实现数据传递的接口面向对象观点：构件包括一组协作的类，构件中的每一个类都被详细描述，包括所有的属性和与其实现相关的操作(对象设计)过程设计方法提出结构化编程：1.所有的程序都可以建立在一组限定好的逻辑构造之上，强调对功能域的支持2.其中每一个逻辑构造都有可预测的逻辑结构，从顶端进入，从底端退出，形成过程流包括三种类型的逻辑构造，通过这三种结构就可以表达程序的全部处理流程，是结构化编程的核心技术顺序型：提供任何算法规则说明中的核心处理步骤条件型：允许根据逻辑情况选择处理的方式重复型：提供对循环的支持数据库设计数据库是绝大多数信息系统的关键组件，数据库设计贯穿整个系统开发生命周期需求阶段确定数据需求：确定哪些数据需要存储和处理分析阶段建立数据库的逻辑模型：描述将会存储在数据库中的实体和属性，使用实体关系图(ER图)建立数据模型构件级设计阶段确定数据库的物理(存储)模型：创建数据库表结构、确定存储过程、规划数据服务等实体：是指作为数据资源应管理的对象,由多个属性构成；每个实体的数值称为实例；可以转换成数据表，实例可以成为表中的记录属性：描述实体的特征，仅与实体一同存在；定义了数据库中的字段确定实体和属性实体：在需求分析阶段确定，并在设计阶段转换成数据表；属性：通过描述每个实体确定主键：唯一标识了表中的每一条记录‘主键要求唯一、稳定复合主键实体中需要一个主键；当一个属性不能唯一识别一个实例时，将多个属性组合起来作为主键，叫做复合主键外键：通过引用另一张表的主键作为外键，已连接两张数据表数据库设计基本原理：数据完整性字段完整性：为字段定义一组有效的取值类型和范围并确定是否允许空值实体完整性：表中每行都有唯一的标识，即主键值参照完整性：确保主键与外键的关系一直存在函数依赖性：若某个属性的值确定的话，其他属性的值就能唯一确定，这种关系即函数依赖规范化：着眼于用户业务所使用的数据项，将其整理为理想的数据结构，想的数据结构是满足“OneFactinOnePlace”(一个事物只存在于一处)规范化存在着从第一范式到第五范式：一般完成第三范式就能达到“OneFactinOnePlace”的目标用户界面设计用户界面(UI)设计在用户与系统之间搭建了一个有效的交流媒介软件工程知识体(SWEBOK)中，将用户界面设计的内容整合为软件人类工程学(SoftwareErgonomics)人类工程学(或称人的因素)是一个科学的学科，它涉及对人和其它系统元素之间交互性的理解，以及为了优化人的地位和整个系统的性能用户界面可以由两部分组成用户界面组件：图形用户界面的组成部分用户处理组件：协调用户界面元素和控件与用户间的交互用户界面组件的功能提示用户输入；捕获用户事件；限制用户仅在预先设定的区域中输入；验证并格式化用户提供的数据；本地化的显示；提示用户应用程序和系统的状态；按用户需要，自定义应用程序的外观用户界面设计的指导方针原则：必须以最直观的方式实现用户的需求实现：在界面设计的每个阶段都要让用户参与进来重要性：应用程序成败的关键处理简单控制类：考虑是否需要哪些简单的控制类下列情况下，控制类可变为真正的设计类封装非常重要的控制流行为封装的行为很可能变化必须跨越多个进程或处理器进行远程封装的行为要求一些事务管理处理复杂的控制类臃肿的控制类：低内聚、缺乏重点并且处理过多的职责区；即违背高内聚、低耦合的设计原则解决方案：加入更多的控制器（更多的分层）、将部分职责委托给其它对象典型的处理情况如针对数据库访问增加数据访问层和相应的访问控制类实体类的设计策略实体对象通常是被动的和持久性的；性能需求可能要对实体类进行重构；引入数据库持久化后会影响到实体类的设计

形式化方法基础形式化方法的特点，与传统方法的区别形式化方法分类和一些典型的形式化方法PetriNetPetriNet基本原理PetriNet的基本特性形式化规约是对程序“做什么”(whattodo)的数学描述,是用具有精确语义的形式语言书写的程序功能描述,它是设计和编制程序的出发点,也是验证程序是否正确的依据。对形式规约通常要讨论其一致性(自身无矛盾)和完备性(是否完全、无遗漏地刻画所要描述的对象)等性质。形式化规约有一个共同的特点：每种规约语言均由基本成分和构造成分两部分构成。前者用来描述基本(原子)规约,后者把基本部分组合成大规约。构造成分是形式规约研究和设计的重点，也是衡量规约语言优劣的主要依据。形式化验证与形式规约之间具有紧密的联系，形式验证就是验证已有的程序(系统)P，是否满足其规约(φ,ψ)的要求(即P(φ,ψ)),它也是形式化方法所要解决的核心问题。传统的验证方法包括模拟(simulation)和测试(testing)，它们都是通过实验的方法对系统进行查错。早期的形式验证主要研究如何使用数学方法，严格证明一个程序的正确性(即程序验证)。形式化方法可以分为五类：1）基于模型的方法：通过明确定义状态和操作来建立一个系统模型（使系统从一个状态转换到另一个状态）。用这种方法虽可以表示非功能性需求（诸如时间需求），但不能很好地表示并发性。如：Z语言，VDM，B方法等。2）基于逻辑的方法：用逻辑描述系统预期的性能，包括底层规约、时序和可能性行为。采用与所选逻辑相关的公理系统证明系统具有预期的性能。用具体的编程构造扩充逻辑从而得到一种广谱形式化方法，通过保持正确性的细化步骤集来开发系统。如：ITL（区间时序逻辑），区段演算（DC），hoare逻辑等。3）代数方法：通过将未定义状态下不同的操作行为相联系，给出操作的显式定义。与基于模型的方法相同的是，没有给出并发的显式表示。如：OBJ，Larch族代数规约语言等；4）过程代数方法：通过限制所有容许的可观察的过程间通信来表示系统行为。此类方法允许并发过程的显式表示。如：通信顺序过程（CSP），通信系统演算（CCS），通信过程代数（ACP）等。5）基于网图的方法：由于图形化表示法易于理解，而且非专业人员能够使用，因此是一种通用的系统确定表示法。该方法采用具有形式语义的图形语言，为系统开发和再工程带来特殊的好处。如Petri图，状态图等。一种基于模型的形式化方法描述数据不变量（Datainvariant）——表示包含一个或多个数据的关系表达式，在系统执行过程的任何时刻，该表达式的值都为真。状态（State）——存储于系统中，可被访问和改变的数据。操作（Operation）——系统中作用于状态数据的读写等动作，与其相关的有两类条件：前置条件（Precondition）：是指操作能够有效执行的环境条件后置条件（Postcondition）：是指操作执行后的环境条件Z语言基于几何理论和一阶谓词逻辑，支持数据抽象和过程抽象：数据抽象：利用抽象的数据结构（关系、函数、集合、序列、包）来进行数据类型描述；过程抽象：通过以抽象数据结构为定义域或值域的映射，描述抽象算法与操作。以Z描述的软件系统由若干模式构成。模式从系统的状态和状态变化两个方面描述软件特征。Z规约包括四个部分:1. 给定集合（Givensets）,数据类型（datatypes）,和常量（constants）2. 状态定义（Statedefinition）3. 初始状态（Initialstate）4. 操作（Operations）Z规约由一系列模式组成。每个模式包括：一组变量声明\一个谓词列表Petri网主要特性可达性如果Petri网（N，M0）存在从M0到Mn的启动序列，则称Mn是从M0可达的，并将Mn的集合称为可达集，记为R（N，M0）。问题:$Mn，MnÎR（N，M0）？有界性对Petri网（N，M0），若存在一个整数，使得M0的任一可达标识的每一位置中的标记数都不超过K，则称Petri网为K有界。问题:$K，"pÎP，"MÎR（M0）：M（p）£K？可覆盖性对Petri网（N，M0）和给定标识M，存在一个可达标识M’，使得对于每个位置p，都有M’（p）³M（p），则称M是可覆盖的。问题:$M’，M’ÎR（N，M0），"pÎP:M’（p）³M（p）？可逆性R（N，M0）的每个标识M，M0都从M可达，则称Petri网是可逆的问题:"M，MÎR（N，M0）:M0ÎR（N，M）？守恒性若N的每个(某些)位置p存在一个正整数Y（p），使得对任何给定的初始标识M0和每个MÎR（M0），都有标识的加权和MTY=M0TY为一个常量，则称N为(部分)守恒的。问题:"Mn，MnÎR（N，M0），åyi*Mn(pi)=常量？重复性若N存在一个标识M0和一个从M0开始的启动序列s，使得每个转移在s中可以无限次发生，则称Petri网为重复的。问题:$s，s为包括每个转移的无限转移序列？一致性若N存在一个标识M0和一个从M0返回到M0的启动序列s，使得每个转移在s中至少出现一次，则称Petri网为一致的。问题:$s，s为包括每个转移的有限转移序列？活性:对于Petri网（N,M0）和变迁tÎT，若对于任意MÎR（N,M0）,都存在M¢ÎR（N,M0）,使得M¢[t>，则称t为四级活的。如果每个t都是四级活的，则称网（N,M0）为四级活的，简称为活的。若存在一个无限变迁启动序列，使得t在该启动序列中可以无限次出现，则称t为三级活的。若对于任意正整数k，都存在一个包括k个t的变迁启动序列σ，有M0[σ>M¢，则称t为二级活的。若存在MÎR（N,M0）,使得M[t>，则称t为一级活的。如果MÎR（N,M0）使得ØM[t>，则称t为死变迁。

软件质量如何评价一个软件产品的好坏软件质量与明确确定的功能和性能需求的一致性与明确成文的开发标准的一致性与所有专业开发的软件所期望的隐含的特性的一致性软件测试是一种提高软件质量的有效手段是为了发现错误而执行程序的过程根据软件开发各阶段的规格说明和内部结构而精心设计一批测试用例（即输入数据及其预期的输出结果）并利用这些测试用例去运行程序，以发现程序错误的过程测试目标测试是一个为了寻找错误而运行程序的过程一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例一个成功的测试是指发现了至今未发现的错误的测试测试目的验证软件实现了规格说明（需求、设计）的要求发现程序中的错误/缺陷确定是否可以使用、可交付了解性能的限制了解系统不能做什么评估系统的能力和质量验证文档测试用例为证实程序符合/不符合要求的程序的一次执行展示软件实现是否符合预期的要求测试用例的主要内容初始状态、输入数据、预期输出、测试过程实际结果、结果评价设计测试用例的两种技术白盒测试、黑盒测试白盒测试：基于代码的测试：代码结构黑盒测试：基于规格说明测试：设计规格说明、需求规格说明、业务规格说明白盒测试利用构件层设计中所描述的程序控制结构来生成测试用例利用白盒测试设计测试用例，达到以下目标：保证一个模块中所有独立路径至少被执行一次对所有的逻辑值均需测试真和假在上下边界及可操作的范围内执行所有的循环检测内部数据结构以确保有效性逻辑覆盖以程序内部逻辑为基础的测试技术，考虑的是程序内部逻辑被覆盖的程度按覆盖程度不同，逻辑覆盖分为：语句覆盖：每条语句至少执行一次分支覆盖：每个分支都至少通过一次条件覆盖：分支中各个条件的所有可能都至少执行一次分支/条件覆盖：分支中的每个条件的所有结果至少出现一次，同时使各分支本身的所有可能也至少出现一次多重覆盖：使各分支中条件的所有可能组合至少出现一次循环覆盖：用来检查循环构造的有效性黑盒测试根据程序的规格说明设计测试用例检查目标是否有不正确或遗漏了的功能在接口上，输入能否正确地输入和输出是否存在数据结构错误或外部信息访问错误性能能否满足要求是否有初始化和终止性错误基于输入域等价类划分、边界值分析域测试基于图的测试因果图决策表、功能图其他测试错误推测法、变异测试、比较法测试等价类指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误是等效的有效等价类对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合无效等价类对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合等价类测试步骤识别每个功能单元的参数参数可影响功能单元操作的环境对象系统参数、外部数据对象、外部设备状态识别每个参数的特性：类型、长度、状态值等将每个特性类划分为不同的等价类：有效等价类和无效等价类确定各个等价类之间的限制，如在一个等价类和另一个等价类中值不能同时存在一个值必须比另一个值大等设计测试用例为每个等价类规定一个唯一的编号设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复到所有的有效等价类都被覆盖为止设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复到所有的无效等价类都被覆盖为止边界值分析着重检查等价类边界上和边界附近的错误实际工作应用中通常把逻辑覆盖、等价划分和边界值分析测试结合使用从而能把白盒和黑盒测试技术结合起来，既可检查设计的内部要求，又可以检查设计的接口要求因果图(cause-effectdiagrams)利用条件与对应动作之间的逻辑关系，着重检查各输入条件的组合如：两个输入值的乘积超过了存储的限制，程序发生错误，等价划分和边界值分析，都不能发现这类错误它们均未考虑输入情况的各种组合因果图的基本原理是通过画因果图把用自然语言描述的功能说明转换为决策表最后为决策表的每一列设计一个测试用例测试步骤分析软件规格说明描述中，哪些是原因（即输入条件或输入条件的等价类），哪些是结果（输出条件），并给出每个原因和结果赋予一个标识符分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的关系，画出因果图由于语法或环境限制，有些原因与原因，原因与结果之间的组合情况不可能出现，为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件把因果图转换为决策表把决策表中每一列表示的情况写成测试用例单元测试是针对程序单元进行正确性检验的测试工作目的：发现各单元的功能是否满足详细设计的要求。测试重点：模块内部逻辑测试技术：白盒测试测试内容模块接口测试：保证在测试时进出程序单元的数据流是正确的局部数据结构测试：保证临时存储的数据在算法执行的整个过程中都能维持其完整性路径测试：测试所有独立路径，保证在一个模块中的所有语句都能至少执行一次边界测试：保证模块在极限或严格的情况下仍能够正确执行错误处理测试：对不正确的输入或异常情况的处理集成测试将软件单元逐步集成为软件系统时所进行的测试目的保证低层的系统组件在集成为高层系统组件之前可正确操作，最终获得正确的软件系统测试重点功能接口之间的有效性和接口的兼容性与集成有关的问题:配置/版本控制I/O格式，协议不匹配不一致的数据的显示/使用数据集成问题错误的调用次序/错误的参数遗漏/重叠的功能资源问题（内存等）接口数据，接口参数是否正确匹配在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失一个模块的功能是否会对另一个模块的功能产生不利的影响各个子功能组合起来，是否达到预期要求全局数据结构是否有问题单个模块的误差积累起来，是否会放大，从而达到不能接受的程度确认测试Validationtesting、Qualificationtesting针对全部集成好的软件系统，验证软件的功能和性能及其他特性是否与指定的要求一致依据:需求规格说明书确认测试中所测试的软件特性常常只有在整个系统运行时才能表现出来有效性测试主要目标：保证所有的功能需求都得到了满足、所有性能需求都达到了、文档是正确且便于使用的、其他需求都得到了满足可靠性、强度、可移植性、兼容性、错误恢复、可维护性系统测试:将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行的一些列的集成和确认测试目的:确认整个计算机系统满足用户需求依据:系统需求规格说明验收测试:以用户为主的测试，验证软件系统是否满足需求规格说明的要求目的:确定软件产品的质量，决定软件产品是否可以交付给用户并投入使用。依据:用户需求（用户需求规格说明）关注:需求的实现、关注隐含的需求:是否“合适使用”验收测试内容：功能测试；性能测试；可靠性测试；可移植性、兼容性、可维护性、错误恢复等功能；文档等测试结果：测试通过；列出问题清单，规定在某个日期后复查；测试不通过回归测试在修改之后进行，保证没有引入新的错误\保证变更不会引入不期望的特性或额外的错误\重新运行测试用例在修复/改变/增强之后、对应用程序的每个构造重新验证所有的功能、在修复/改变中有没有新的问