软件工程基础软件工程基础 有效地开展软件开发和软件测评有效地开展软件开发和软件测评, , 既要知其然既要知其然, ,也要知其所以然也要知其所以然. . 北京大学北京大学软件工程国家工程研究中心件工程国家工程研究中心王立福王立福2009年年4月月一、概论一、概论-试图回答软件开发的本质及开发的基本手段试图回答软件开发的本质及开发的基本手段二二、软件过程、软件过程 -试图回答开发所涉及的活动及活动组织试图回答开发所涉及的活动及活动组织三、软件需求及系统三、软件需求及系统/ /产品产品( (需求需求) )规约规约 -试图回答软件开发的启始点及其工作产品试图回答软件开发的启始点及其工作产品是是产品产品/系统系统确认确认( (测试测试) )的标尺的标尺四四、软件开发方法学软件开发方法学 -试图回答如何从事开发活动试图回答如何从事开发活动五五、CMMCMM（theCapabilityMaturityModelforsoftware） -试图回答获得正确产品试图回答获得正确产品/ /系统的过程能力保障系统的过程能力保障软件开发软件开发本质本质软软件件生生存存周周期期过过程程导出导出软软件件生生存存周周期期模模型型软软件件工工程程生生存存周周期期过过程程支支持持过过程程方方向向(活活动动与与定定序序)的的建建立立形形成成软件开发方法学软件开发方法学结构化方法结构化方法面向对象方法面向对象方法面向数据结构面向数据结构方法方法维也纳开发方维也纳开发方法（法（VDM）给给出出实实现现开开发发过过程程的的途途径径支持支持/管理技术与方法管理技术与方法作用于作用于软件工程基本知识结构软件工程基本知识结构一、概论一、概论-软件开发的本质是什么软件开发的本质是什么? ? - -软件开发的基本手段是什么软件开发的基本手段是什么? ? 正确认识软件开发正确认识软件开发, , 是从事软件开发的思想基础是从事软件开发的思想基础. .1软件开发的本质软件开发的本质问题域问题域-客观事物系统客观事物系统概念不同，解决问概念不同，解决问题的思维逻辑不同题的思维逻辑不同-“距离距离”操作系统与语言处理系统操作系统与语言处理系统网络网络计算机计算机-异构异构VB、VC-程序设计环境程序设计环境中间件技术与产品中间件技术与产品应用框架应用框架领域软件生产线领域软件生产线映射映射运行（计算）平台运行（计算）平台本质本质:问题域到不同抽象层之间概念和计算逻辑的映射问题域到不同抽象层之间概念和计算逻辑的映射.例如例如1:1:问题空间的概念问题空间的概念 与与 解空间的模型化概念解空间的模型化概念 之间的映射之间的映射 对象对象 = F= F（张山）（张山） （模型化概念）模型化概念） （问题空间的概念（问题空间的概念） 这是一个抽象的过程这是一个抽象的过程- -数据抽象数据抽象. . 其中，其中， 对应的过程：需求分析对应的过程：需求分析 使用的方法：面向对象方法使用的方法：面向对象方法 基于的原理：数据抽象基于的原理：数据抽象 目标：形成计算的客体。目标：形成计算的客体。 例如例如2 2：问题空间的处理逻辑问题空间的处理逻辑 与与 解空间处理逻辑解空间处理逻辑 之间的映射之间的映射 加工加工1 1（及相关的数据流）（及相关的数据流）=F=F（计算学生成绩）（计算学生成绩） 加工加工1计算学生平均成绩计算学生平均成绩科目科目+年级年级/班班学生成绩文件学生成绩文件学生平均成绩学生平均成绩规约后的处理逻辑规约后的处理逻辑这也是一个抽象的过程这也是一个抽象的过程- -过程抽象过程抽象 其中：对应的过程：需求分析其中：对应的过程：需求分析; ; 使用的方法：结构化方法；使用的方法：结构化方法； 基于的原理：过程抽象基于的原理：过程抽象 目标目标: :形成一种可构造的计算逻辑形成一种可构造的计算逻辑. .例如例如3：交互图交互图1=H（计算学生成绩）（计算学生成绩）其中：对应的过程：需求分析设计其中：对应的过程：需求分析设计使用的方法：面向对象方法使用的方法：面向对象方法基于的原理：行为结构抽象（简称基于的原理：行为结构抽象（简称行为抽象行为抽象）目标：目标：形成一种可构造的计算逻辑形成一种可构造的计算逻辑.：教务员：教务员：教员：教员递交A科学生成绩表A科学生成绩表：教学主任：教学主任求A科平均A科平均2 2 实现映射的基本手段实现映射的基本手段何谓建立问题的模型何谓建立问题的模型:运用所掌握的知识运用所掌握的知识,通过抽象，给出该问题的一个结构。通过抽象，给出该问题的一个结构。问题的结构化谱系问题的结构化谱系例如例如1：y=x+5结构化结构化问题问题非非结构化结构化或半结构化问题或半结构化问题建模：是解决问题的一般途径建模：是解决问题的一般途径!其中其中:采用数学作为建模工具采用数学作为建模工具例如例如2:2:信用卡确认系统的功能模型信用卡确认系统的功能模型财务结算机构（负责信财务结算机构（负责信用卡帐户的结算服务）用卡帐户的结算服务）零售机构（顾客通过该零售机构（顾客通过该机构刷卡，购买商品或机构刷卡，购买商品或服务。服务。其中其中:采用采用UML作为建模工具作为建模工具何谓模型何谓模型anyabstractionthatincludesallessentialcapabilities,properties,oraspectsofwhatisbeingmodeledwithoutanyextraneousdetails.Firesmith,Henderson-Sellers具体地说，模型是在具体地说，模型是在特定意图特定意图下所确定的下所确定的角度角度和和抽象层抽象层次次上对物理系统的描述，通常包含对该系统边界的描述，给上对物理系统的描述，通常包含对该系统边界的描述，给出系统内各模型元素以及它们之间的语义关系。出系统内各模型元素以及它们之间的语义关系。问题空间问题空间3 3 软件系统或项的模型分类软件系统或项的模型分类- -概念模型概念模型- -设计模型设计模型- -实现模型实现模型- -部署模型部署模型软件模型软件模型问题域问题域-客观事物系统客观事物系统分层的基本动机是控制开发的复杂性分层的基本动机是控制开发的复杂性,一个抽象层是由一组确定的术语定义的一个抽象层是由一组确定的术语定义的.二、软件过程二、软件过程 -软件开发要做那些映射软件开发要做那些映射- -活动活动? ? - -应如何正确组织开发活动应如何正确组织开发活动, ,形成求解软件的形成求解软件的 逻辑逻辑? ? 开发逻辑开发逻辑, ,是获取正确软件的关键是获取正确软件的关键. .软件开发软件开发本质本质软软件件生生存存周周期期过过程程定义定义软软件件生生存存周周期期模模型型软软件件工工程程生生存存周周期期过过程程支支持持过过程程方方向向(活活动动与与定定序序)的的建建立立形形成成软件开发方法学软件开发方法学结构化方法结构化方法面向对象方法面向对象方法面向数据结构面向数据结构方法方法维也纳开发方维也纳开发方法（法（VDM）给给出出实实现现开开发发过过程程的的途途径径支持支持/管理技术与方法管理技术与方法作用于作用于1 1 开发所涉及的活动开发所涉及的活动-软件生存周期过程软件生存周期过程1)基本概念基本概念为了表述软件开发需要做为了表述软件开发需要做“什么活什么活(映射映射)”,引入了以下三引入了以下三个概念：个概念： 软件过程软件过程(process)：活动的一个集合；：活动的一个集合； 活动活动(activity)：任务的一个集合；：任务的一个集合；注注:”软件过程软件过程”和和”活动活动”相当于复合映射相当于复合映射. 任务任务(task)：将输入转换为输出的操作。将输入转换为输出的操作。注注:”任务任务”相当于原子映射相当于原子映射. 2) 2) 过程分类过程分类 按过程的主体按过程的主体, ,可分为三类过程可分为三类过程： (1)(1)基本过程基本过程(primary processes)(primary processes) 是指那些与是指那些与软件生产软件生产直接相关的活动集。直接相关的活动集。 (2(2）支持过程）支持过程(supporting processes )(supporting processes ) 是有关各方按其目标所从事的一系列是有关各方按其目标所从事的一系列支持支持活动集。活动集。 (3(3）组织过程）组织过程(institutional processes)(institutional processes)是指那些与是指那些与软件生产组织软件生产组织有关的活动集。有关的活动集。 基本过程基本过程支持过程支持过程组织过程组织过程(1(1）基本过程基本过程 又按过程中活动的不同主体，将基本过程（类）分又按过程中活动的不同主体，将基本过程（类）分 为为5 5个过程个过程：获取过程、供应过程、开发过程、：获取过程、供应过程、开发过程、 运行过程、维护过程运行过程、维护过程获取过程获取过程基本过程基本过程支持过程支持过程组织过程组织过程组织为组织为供应过程供应过程开发过程开发过程运行过程运行过程维护过程维护过程例如例如1 1：供应过程：供应过程 供供应应过过程程是是供供方方为为了了向向客客户户提提供供满满足足需需求求的的软软件件产产品品或或服服务务所从事的一系列活动和任务。所从事的一系列活动和任务。其目的是向客户提供一个满足已达成需求的产品或服务。其目的是向客户提供一个满足已达成需求的产品或服务。该该过过程程的的启启动动，或或通通过过为为应应答答需需方方的的招招标标书书而而开开始始编编制制投投标标书书的的决决定定，或或通通过过与与需需方方签签订订一一项项提提供供系系统统、软软件件产产品品或或软软件服务的合同。件服务的合同。继继之之，确确定定为为管管理理和和保保证证项项目目所所需需的的规规程程和和资资源源，包包括括编编制制项项目目计计划划，执执行行计计划划，一一直直到到将将系系统统、软软件件产产品品或或软软件件服服务务交付给需方为止。交付给需方为止。该过程包括的基本活动为：该过程包括的基本活动为：a)启动；启动；b)准备投标；准备投标；c)签订合同；签订合同；d)规划；规划；e)执行和控制；执行和控制；f)复审和评估；复审和评估；g)交付和完成。交付和完成。 其其中中每每一一活活动动又又包包含含一一组组特特定定的的任任务务。例例如如“规规划划”活活动动包包括下述任务：括下述任务：（1）供供方方应应复复审审获获取取需需求求，以以便便定定义义管管理理该该项项目目、保保证证可可交交付的软件产品或服务质量的框架。付的软件产品或服务质量的框架。（2）如如果果合合同同中中没没有有规规定定采采用用什什么么软软件件生生存存周周期期模模型型，那那么么供供方方就就应应确确定定或或选选择择一一个个适适合合于于该该项项目目的的范范围围、规规模模和和复复杂杂度度的的软软件件生生存存周周期期模模型型，并并应应从从本本章章中中所所述述的的过过程程、活活动动和和任任务务中中进进行行选选择择，并并将将它它们们映映射射到到所所选选择择的的软软件件生生存存周期模型。周期模型。（3）供供方方应应为为关关于于项项目目的的计计划划建建立立适适当当的的需需求求，以以便便管管理理该该项项目目和和保保证证可可交交付付软软件件产产品品或或服服务务的的质质量量。这这样样的的需需求求应应包括资源的需要以及需方的参与。包括资源的需要以及需方的参与。（4）一旦建立了有关规划的需求，供方就应该考虑：一旦建立了有关规划的需求，供方就应该考虑：a)是否利用内部资源来开发该软件产品或提供软件服务；是否利用内部资源来开发该软件产品或提供软件服务；b)是否通过分包合同来开发该软件产品或提供软件服务；是否通过分包合同来开发该软件产品或提供软件服务；c)是否从内部或外部来获得现货软件产品；是否从内部或外部来获得现货软件产品；d)是否采用是否采用a)b)c)的组合。的组合。并针对以上每一种选择给出风险分析。并针对以上每一种选择给出风险分析。（5）供供方方应应基基于于有有关关规规划划的的需需求求和和以以上上的的选选择择，制制订订项项目目管管理计划并形成文档。计划中应主要考虑包含以下条目：理计划并形成文档。计划中应主要考虑包含以下条目：A)开发单位（包括外包单位）的项目组织结构、职责和职权；开发单位（包括外包单位）的项目组织结构、职责和职权；B)工工程程环环境境，包包括括可可用用的的开开发发环环境境、运运行行环环境境、维维护护环环境境以以及及测测试试环环境、程序库、设备、设施、标准、规程和工具；境、程序库、设备、设施、标准、规程和工具；C)生生存存周周期期过过程程和和活活动动的的工工作作分分解解结结构构，包包括括要要完完成成的的软软件件产产品品、软软件件服服务务和和非非交交付付项项以以及及预预算算、人人员员配配备备、物物理理资资源源、软软件件规规模模和和与与任任务有关的进度；务有关的进度；D)软件产品或服务的质量特性的管理，可以制订独立的质量计划；软件产品或服务的质量特性的管理，可以制订独立的质量计划；E)软软件件产产品品或或服服务务的的安安全全、安安全全保保密密和和其其他他关关键键需需求求的的管管理理，可可以以制制订独立的安全、安全保密计划；订独立的安全、安全保密计划；F)分包方管理，包括分包方选择以及分包方与需方之间的参与等；分包方管理，包括分包方选择以及分包方与需方之间的参与等；g)质量保证（见支持过程）；质量保证（见支持过程）；H)验验证证和和确确认认（见见支支持持过过程程）；包包括括指指明明与与验验证证机机构构和和确确认认机机构构的的接接口口途径；途径；i)需需方方参参与与，其其手手段段如如联联合合复复审审、审审核核、非非正正式式会会议议、报报告告、修修改改和和变变更更等；等；J)用户参与，其手段如需求是否实现的演练、原型演示和评估等；用户参与，其手段如需求是否实现的演练、原型演示和评估等；K)风险管理，即管理项目有关技术、成本和进度等方面的潜风险；风险管理，即管理项目有关技术、成本和进度等方面的潜风险；L)安安全全保保密密策策略略，即即在在每每一一个个项项目目组组织织层层面面上上那那些些按按需需所所知知并并访访问问信信息息的的准则；准则；M)诸诸如如规规章章、所所需需的的认认证证、专专利利权权、使使用用权权、所所有有权权、担担保保权权以以及及许许可可证授予权等方面所要求的批准；证授予权等方面所要求的批准；N)进度安排、追踪和报告的方法；进度安排、追踪和报告的方法；O)人员培训（见组织过程）。人员培训（见组织过程）。注注: :关于该过程的其它活动和任务，请参见相关的标准。关于该过程的其它活动和任务，请参见相关的标准。总的来说，成功实现该过程的结果是：总的来说，成功实现该过程的结果是：）对客户请求产生了一个响应；）对客户请求产生了一个响应；）在客户与供方之间建立了一个关于开发、维护、运行、）在客户与供方之间建立了一个关于开发、维护、运行、包装、交付和安装产品和包装、交付和安装产品和/或服务的协定；或服务的协定；）供方开发了一个符合协定需求的产品和）供方开发了一个符合协定需求的产品和/或服务；或服务；）根据协定的需求，向客户交付了该产品和）根据协定的需求，向客户交付了该产品和/或服务；或服务；）根据协定的需求，安装了该产品。）根据协定的需求，安装了该产品。例如例如2：开发过程开发过程是是软件开发者软件开发者所从事的一系列活动。所从事的一系列活动。包括包括13个活动：个活动：过程的实施准备过程的实施准备 系统需求分析系统需求分析 系统结构设计系统结构设计 软件需求分析软件需求分析 软件体系结构设计软件体系结构设计 软件详细设计软件详细设计 软件编码和测试软件编码和测试 软件集成软件集成 软件合格测试软件合格测试 系统集成系统集成 系统合格测试系统合格测试 软件安装软件安装 软件验收支持软件验收支持其中的活动：其中的活动：过程的实施准备过程的实施准备（process implementationprocess implementation）主要任务主要任务：-规划软件工程过程规划软件工程过程 依据项目的规模依据项目的规模、 重要程度以及复杂性，定义或选重要程度以及复杂性，定义或选择软件生存周期模型并将开发过程的活动和任务择软件生存周期模型并将开发过程的活动和任务映射到该软件生存周期模型映射到该软件生存周期模型 依据文档过程，建立该过程文档；并将该文档置于依据文档过程，建立该过程文档；并将该文档置于 配置管理过程之下，并作为实施变更控制的依据；配置管理过程之下，并作为实施变更控制的依据； 依据问题解决过程，发现软件工作产品和任务中的依据问题解决过程，发现软件工作产品和任务中的问题和不一致性，并建立相应的文档；问题和不一致性，并建立相应的文档；按合同规定，实现相应的支持过程按合同规定，实现相应的支持过程 为执行开发过程和支持过程的活动，对开发组织所建为执行开发过程和支持过程的活动，对开发组织所建 立的标准立的标准、方法、工具和计算机程序设计语言进行选、方法、工具和计算机程序设计语言进行选 择、剪裁和应用择、剪裁和应用依据开发和验收的所有需求（包括安全），为执行过依据开发和验收的所有需求（包括安全），为执行过 程的活动制定相应计划，例如风险管理计划程的活动制定相应计划，例如风险管理计划、质量保、质量保 证计划等，这些证计划等，这些同样也包括标准同样也包括标准、方法方法、工具工具、措施措施 以及以及责任等必要时这些计划可以分别建立责任等必要时这些计划可以分别建立其中的活动：其中的活动：软件需求分析软件需求分析主要任务主要任务： 建立软件需求规格说明书，其中包括：建立软件需求规格说明书，其中包括：功能和能力规约，包括性能以及为执行软件的物理特功能和能力规约，包括性能以及为执行软件的物理特征和环境条件；征和环境条件；质量特征规约（参考）；质量特征规约（参考）；软件接口规约；软件接口规约；安全规约；安全规约；数据定义和数据库需求；数据定义和数据库需求；用户操作和执行需求；用户操作和执行需求；用户维护需求等用户维护需求等 考虑以下准则，对软件需求进行评估：考虑以下准则，对软件需求进行评估： 是否能够跟踪到系统需求、系统结构；是否能够跟踪到系统需求、系统结构； 从外部上，是否与系统需求保持一致；从外部上，是否与系统需求保持一致； 需求内部的一致性；需求内部的一致性； 是否具有可测性；是否具有可测性；设计、实现和维护的可行性等设计、实现和维护的可行性等 依据联合评审过程，对软件需求进行评审依据联合评审过程，对软件需求进行评审 其中的活动其中的活动: :软件体系结构设计软件体系结构设计 该活动是针对该活动是针对每一个软件项（或已标识的软件配置项）每一个软件项（或已标识的软件配置项）主要任务为主要任务为: : 把那些对软件项的需求转变为一种体系结构，即把那些对软件项的需求转变为一种体系结构，即: : 其其中中该该体体系系结结构构描描述述了了该该项项的的顶顶层层结结构构并并标标识识各各个个软软件件部部件件。其其中中应应确确保保对对软软件件项项的的所所有有需需求求都都被被分分配配给给了了相相应应的的软软件件部部件件，并并为为了了进进行行详详细细设设计计而而使使该该项项的的需需求求得得到到进进一一步细化。软件项的体系结构应形成文档。步细化。软件项的体系结构应形成文档。 软件体系结构设计软件体系结构设计In该软件项的需求该软件项的需求Out该项的软件体系结构该项的软件体系结构开发关于软件项的外部接口以及软件项的各个软件部开发关于软件项的外部接口以及软件项的各个软件部件间的接口的顶层设计，并形成文档。件间的接口的顶层设计，并形成文档。 编制数据库的顶层设计，并形成文档。编制数据库的顶层设计，并形成文档。 编制用户文档的最初版本，并形成文档。编制用户文档的最初版本，并形成文档。 确定软件集成的初步测试需求和进度安排，并形成文确定软件集成的初步测试需求和进度安排，并形成文档。档。 根据下列评价准则根据下列评价准则, ,评价软件项的体系结构、接口和数据库评价软件项的体系结构、接口和数据库 设计，评价结果应形成文档：设计，评价结果应形成文档： 软件项需求的可追踪性；软件项需求的可追踪性； 与软件项需求的外部一致性；与软件项需求的外部一致性； 软件部件之间的内部一致性；软件部件之间的内部一致性； 所应用的设计方法和标准的适宜性；所应用的设计方法和标准的适宜性； 详细设计的可行性；详细设计的可行性； 运行与维护的可行性。运行与维护的可行性。按照联合评审按照联合评审, ,对软件体系结构进行评审。对软件体系结构进行评审。注注: :关于开发过程的其他活动和任务关于开发过程的其他活动和任务, ,可参阅有关标准可参阅有关标准. .总的来说，成功实现开发过程的结果是：总的来说，成功实现开发过程的结果是：a)收集了软件开发需求并达成协定；收集了软件开发需求并达成协定；b)开发了软件产品或基于软件的系统；开发了软件产品或基于软件的系统；c)开发了证明最终产品是基于需求的中间工作产品；开发了证明最终产品是基于需求的中间工作产品；d)在开发过程的产品之间，建立了一致性；在开发过程的产品之间，建立了一致性；e)根根据据系系统统需需求求，优优化化了了系系统统质质量量因因素素，例例如如，速速度度、开开发发成本、易用性等；成本、易用性等；f)提供了证明最终产品满足需求的证据（例如，测试证据）；提供了证明最终产品满足需求的证据（例如，测试证据）；g)根据协定的需求，安装了最终产品。根据协定的需求，安装了最终产品。（2 2）支持过程支持过程 又按过程中活动的不同主体，将支持过程（类）分为又按过程中活动的不同主体，将支持过程（类）分为 8 8个过程个过程：文档过程、配置管理过程、质量保证、验证过程、文档过程、配置管理过程、质量保证、验证过程、确认过程、联合评审、审计过程、确认过程、联合评审、审计过程、问题解决等。问题解决等。文档过程文档过程基本过程基本过程支持过程支持过程组织过程组织过程组织为组织为配置管理过程配置管理过程质量保证过程质量保证过程验证过程验证过程联合评审过程联合评审过程确认过程确认过程审计过程审计过程问题解决过程问题解决过程例如例如3:3:文档过程文档过程是记录由某一过程或活动所产生信息的过程是记录由某一过程或活动所产生信息的过程包括包括4 4个活动个活动：过程的实施准备：过程的实施准备设计与开发设计与开发制作与发行制作与发行维护维护其中的活动：其中的活动：过程的实施准备过程的实施准备主要任务主要任务：开发一个计划，用于标识软件产品生存周期中要开发一个计划，用于标识软件产品生存周期中要产生的文档对于所标识的每一个文档，应给出：产生的文档对于所标识的每一个文档，应给出：标题或名字标题或名字目的目的读者读者文档输入文档输入、开发、评审、修改、提交、存储、开发、评审、修改、提交、存储、维护以及配置管理等的规程和责任维护以及配置管理等的规程和责任其中的活动：其中的活动：设计与开发设计与开发主要任务主要任务：根据适用的文档标准，设计每一文档的格式、内根据适用的文档标准，设计每一文档的格式、内容说明、图表设置以及包装等。容说明、图表设置以及包装等。可以使用自动化的文档工具，确保每个文档输入可以使用自动化的文档工具，确保每个文档输入数据的来源和适用性；数据的来源和适用性； 按文档标准，编辑并评审每一文档的格式、技术按文档标准，编辑并评审每一文档的格式、技术内容和表示风格在分发前需经主管人员批准。内容和表示风格在分发前需经主管人员批准。例如例如4：验证过程：验证过程 为什么要进行验证和确认为什么要进行验证和确认? ? 出现这一问题的基本原因出现这一问题的基本原因: : 由于人们的认知能力由于人们的认知能力, ,在抽象一个事物或一个问题时在抽象一个事物或一个问题时, ,往往 往只描述其一些必要性往只描述其一些必要性, ,但不是充分的但不是充分的. .例如例如: : “操作系统是一组管理计算机系统资源的程序操作系统是一组管理计算机系统资源的程序”. . Allmodelsarewrong,somemodelsareuseful.-Fox何谓何谓验证过程验证过程是一个确定某项活动的软件产品是否满足在以前的活动中是一个确定某项活动的软件产品是否满足在以前的活动中施加于它们的需求和条件的过程。施加于它们的需求和条件的过程。可见，该过程的目的是：证实一个过程和可见，该过程的目的是：证实一个过程和/或项目的每一或项目的每一软件工作产品和软件工作产品和/或服务恰当地反映了已规定的需求。或服务恰当地反映了已规定的需求。验证过程可应用于供应、开发、运行或维护等过程。该过验证过程可应用于供应、开发、运行或维护等过程。该过程可以由来自同一组织一个人或多个人来实施，也可以由程可以由来自同一组织一个人或多个人来实施，也可以由来自另一组织的人员来实施。来自另一组织的人员来实施。活动1活动2活动3 该过程包括的活动该过程包括的活动a)过程实现；过程实现；b)验证。验证。1）过程实现）过程实现 该活动包括以下该活动包括以下6 6项任务：项任务：（1）确定项目是否需要进行一定的验证工作，以及验证工作确定项目是否需要进行一定的验证工作，以及验证工作是否需要一个独立组织。分析项目需求的关键性。是否需要一个独立组织。分析项目需求的关键性。关键关键性的计量可按以下各项进行：性的计量可按以下各项进行：A)在系统需求或软件需求中，可能引起死亡、人身伤害、任务失败、在系统需求或软件需求中，可能引起死亡、人身伤害、任务失败、财经损失或灾难性的设备损坏等未被发现的错误之潜在性；财经损失或灾难性的设备损坏等未被发现的错误之潜在性；B)所用软件技术的成熟度，以及应用这种技术的风险；所用软件技术的成熟度，以及应用这种技术的风险；C)可用的经费和资源。可用的经费和资源。（2）如如果果一一个个项项目目需需要要进进行行验验证证工工作作，就就应应为为验验证证该该软软件件产产品而建立一个验证过程。品而建立一个验证过程。（3）如如果果一一个个项项目目需需要要进进行行独独立立的的验验证证工工作作，就就要要选选择择一一个个负负责责进进行行验验证证的的合合格格组组织织，并并确确保保该该组组织织具具有有实实施施验验证证活活动的独立性和权力。动的独立性和权力。（4）基基于于以以上上有有关关范范围围、重重要要程程度度、复复杂杂性性和和关关键键性性的的分分析析，确确定定需需要要进进行行验验证证的的生生存存周周期期活活动动和和软软件件产产品品。为为这这些些生生存存周周期期活活动动和和软软件件产产品品，选选择择以以下下定定义义的的验验证证活活动动和和任任务务，以及执行这些任务所需要的方法、技术和工具。以及执行这些任务所需要的方法、技术和工具。（5）根根据据已已确确定定的的验验证证任任务务，制制定定验验证证计计划划并并形形成成文文档档。该该计计划划应应描描述述：要要验验证证的的生生存存周周期期活活动动和和软软件件产产品品、每每个个生生存存周周期期活活动动和和软软件件产产品品所所需需的的验验证证任任务务，以以及及有有关关资资源源、职职责责和和进进度度安安排排。该该计计划划还还应应描描述述向向需需方方和和其其他他有有关关组组织织提交验证报告的规程。提交验证报告的规程。（6）实实现现该该验验证证计计划划。其其中中，由由验验证证工工作作发发现现的的问问题题和和不不符符合合项项应应作作为为问问题题解解决决过过程程的的输输入入；应应对对所所有有问问题题和和不不符符合合项项给给出出解解决决方方案案；应应为为需需方方和和其其他他有有关关组组织织给给出出可可用用的的验验证活动的结果。证活动的结果。2）验证验证该活动包括以下该活动包括以下7项任务：项任务：（1）合同验证。其中应考虑下面列出的准则：）合同验证。其中应考虑下面列出的准则：a)供方具有满足需求的能力；供方具有满足需求的能力；b)需求一致并覆盖了用户的需要；需求一致并覆盖了用户的需要；c)规定了可处理需求变更和处理问题蔓延的规程；规定了可处理需求变更和处理问题蔓延的规程；d)规规定定了了各各方方之之间间进进行行接接口口和和合合作作的的规规程程及及其其范范围围，包包括括所所有权、许可权、版权和保密性；有权、许可权、版权和保密性；e)规定了符合需求的验收准则和规程。规定了符合需求的验收准则和规程。注：该活动可用于合同评审。注：该活动可用于合同评审。（2）过程验证。其中应考虑下面列出的准则：过程验证。其中应考虑下面列出的准则：A)项目规划的需求是足够的、及时的；项目规划的需求是足够的、及时的；B)为项目所选择的过程是可行的、已实现的，是按计划执为项目所选择的过程是可行的、已实现的，是按计划执行的，并是符合合同的；行的，并是符合合同的；C)用于项目过程的标准、规程和环境是满意的；用于项目过程的标准、规程和环境是满意的；D)根据合同要求，为项目配备了经过培训的人员。根据合同要求，为项目配备了经过培训的人员。（3）需求验证。其中应考虑下面列出的准则：需求验证。其中应考虑下面列出的准则：a)系统需求是一致的、可行的且是可测试的；系统需求是一致的、可行的且是可测试的；b)根据设计准则，系统需求被适当地分配给了硬件项、软根据设计准则，系统需求被适当地分配给了硬件项、软件项和手工操作；件项和手工操作；c)软件需求是一致的、可行的且是可测试的，并准确地体现软件需求是一致的、可行的且是可测试的，并准确地体现了系统需求；了系统需求；d)通过适当严格的方法表明，有关安全保密性和关键性的软通过适当严格的方法表明，有关安全保密性和关键性的软件需求是正确的。件需求是正确的。(4)设计验证。其中应考虑下面列出的准则：设计验证。其中应考虑下面列出的准则：a)设计是正确的、与需求一致并可追踪到需求；设计是正确的、与需求一致并可追踪到需求；b)设计实现了适当的事件序列、输入、输出、接口、逻辑设计实现了适当的事件序列、输入、输出、接口、逻辑流，实现了按时和规模预算的分配以及错误定义、问题隔流，实现了按时和规模预算的分配以及错误定义、问题隔离及恢复；离及恢复；c)可以依据需求导出所选择的设计；可以依据需求导出所选择的设计；d)通过适当严格的方法表明，设计正确地实现了安全保密性通过适当严格的方法表明，设计正确地实现了安全保密性以及其他关键性的需求。以及其他关键性的需求。（5）编码验证。其中应根据下面列出的准则：）编码验证。其中应根据下面列出的准则：a)编码可追踪到设计和需求，是可测试的和正确的，并且编码可追踪到设计和需求，是可测试的和正确的，并且符合需求和编码标准；符合需求和编码标准；b)编码实现了适当的事件顺序、一致的接口、正确的数据编码实现了适当的事件顺序、一致的接口、正确的数据和控制流、完备性、恰当的按间和规模预算的分配、错和控制流、完备性、恰当的按间和规模预算的分配、错误定义、问题隔离和恢复；误定义、问题隔离和恢复；c)可以由设计或需求导出所选择的编码；可以由设计或需求导出所选择的编码；d)通过适当严格的方法表明，编码正确地实现了安全保密通过适当严格的方法表明，编码正确地实现了安全保密和其他关键性的需求。和其他关键性的需求。（6）集成验证。其中应考虑下面列出的准则：）集成验证。其中应考虑下面列出的准则：a)每个软件项的软件构件和软件单元已被完整的且正确的每个软件项的软件构件和软件单元已被完整的且正确的集成到该软件项中；集成到该软件项中；b)系统的硬件项、软件项和手工操作已被完整的且正确的集系统的硬件项、软件项和手工操作已被完整的且正确的集成到该系统中；成到该系统中；c)已根据集成计划执行了相应的集成任务。已根据集成计划执行了相应的集成任务。（7）文档验证。其中应考虑下面列出的准则：文档验证。其中应考虑下面列出的准则：a)文档是充分的、完备的和一致的；文档是充分的、完备的和一致的；b)文档制订是及时的；文档制订是及时的；c)文档的配置管理遵循了规定的规程。文档的配置管理遵循了规定的规程。总的来说，成功实施该过程的结果是：总的来说，成功实施该过程的结果是：a)制定并实现了验证策略；制定并实现了验证策略；b)标识了验证所有要求的软件工作产品的准则；标识了验证所有要求的软件工作产品的准则；c)执行了所要求的验证活动；执行了所要求的验证活动；d)标识并记录了缺陷；标识并记录了缺陷；e)给出了对顾客和其他相关方可用的验证活动的结果。给出了对顾客和其他相关方可用的验证活动的结果。例如例如5 5：确认过程确认过程定义：定义：确认过程是一个确定需求和最终的、已建成的系确认过程是一个确定需求和最终的、已建成的系统或软件产品是否满足特定预期用途的过程。统或软件产品是否满足特定预期用途的过程。可见，该过程的目的是：证实对软件工作产品特定预期使可见，该过程的目的是：证实对软件工作产品特定预期使用的需求已予实现。该过程可以作为开发过程中软件验收用的需求已予实现。该过程可以作为开发过程中软件验收支持活动的一个部分来执行。该过程可以由来自同一组织支持活动的一个部分来执行。该过程可以由来自同一组织一个人或多个人来实施，也可以由来自另一组织的人员来一个人或多个人来实施，也可以由来自另一组织的人员来实施。实施。活动1活动2活动3该过程包括的活动该过程包括的活动a)过程实施；过程实施；b)确认。确认。1）过程实现）过程实现该活动包括以下项任务：该活动包括以下项任务：（1）确定项目是否需要进行确认工作，以及确认工作所需要确定项目是否需要进行确认工作，以及确认工作所需要的一定组织上的独立性。的一定组织上的独立性。（2）如果项目需要进行确认工作，就应建立确认系统或软件如果项目需要进行确认工作，就应建立确认系统或软件产品的一个确认过程，并选择以下定义的确认任务，其产品的一个确认过程，并选择以下定义的确认任务，其中包括用于执行确认任务的方法、技术和工具。中包括用于执行确认任务的方法、技术和工具。（3）如果项目需要进行独立的确认工作，就应选择一个负责如果项目需要进行独立的确认工作，就应选择一个负责执行确认工作的合格组织，并确保执行者具有执行确认任执行确认工作的合格组织，并确保执行者具有执行确认任务的独立性和权力。务的独立性和权力。（4）制定确认计划并形成文档。该计划主要包括以下内容：制定确认计划并形成文档。该计划主要包括以下内容：a)要确认的软件项；要确认的软件项；b)待执行的确认任务；待执行的确认任务；c)用于确认工作的资源、职责和进度；用于确认工作的资源、职责和进度；d)向需方和有关各方提交确认报告的规程。向需方和有关各方提交确认报告的规程。(5)实现该确认计划。其中，由确认工作查出的问题和不符实现该确认计划。其中，由确认工作查出的问题和不符合性，应作为问题解决过程的输入；应对全部问题和不符合性，应作为问题解决过程的输入；应对全部问题和不符合性给出解决方案；应为需方和其他有关组织给出可用的合性给出解决方案；应为需方和其他有关组织给出可用的确认结果。确认结果。2)确认确认该活动包括以下项任务：该活动包括以下项任务：（1）为了对测试结果进行分析，准备所选择的测试需求、测为了对测试结果进行分析，准备所选择的测试需求、测试用例和测试规格说明。试用例和测试规格说明。（2）确保这些测试需求、测试用例和测试规格说明体现了特确保这些测试需求、测试用例和测试规格说明体现了特定预期用途的特殊需求。定预期用途的特殊需求。（3）进行（进行（1）、（）、（2）中确定的测试，一般包括：）中确定的测试，一般包括：A)强度、边界和异常输入的测试；强度、边界和异常输入的测试；B)软软件件产产品品隔隔离离错错误误影影响响测测试试以以及及使使错错误误影影响响最最小小化化能能力力的的测测试试，即即：在在失失效效时时，测测试试该该软软件件产产品品是是否否能能得得体体降降级级；在在过过载载、边边界界和和异异常常条条件下，测试该软件产品是否能向操作者提出协助请求；件下，测试该软件产品是否能向操作者提出协助请求；c)代表性用户使用该软件产品成功完成其预期任务的测试。代表性用户使用该软件产品成功完成其预期任务的测试。（4）确认软件产品满足它的预期用途。确认软件产品满足它的预期用途。（5）在目标环境选定区域中，适当对该软件产品进行测试。在目标环境选定区域中，适当对该软件产品进行测试。注：确认可使用除了测试之外的其他方法，例如，分析、建注：确认可使用除了测试之外的其他方法，例如，分析、建模、模拟等。模、模拟等。总的来说，成功实施确认过程的结果是：总的来说，成功实施确认过程的结果是：a)制定并实现了确认策略；制定并实现了确认策略；b)标识了确认所有要求的工作产品的准则；标识了确认所有要求的工作产品的准则；c)执行了要求的确认活动；执行了要求的确认活动；d)标识并记录了问题；标识并记录了问题；e)提供了所开发的软件工作产品适合于其预期用途的证据；提供了所开发的软件工作产品适合于其预期用途的证据；f)给出了对顾客和其他相关方可用的确认活动的结果。给出了对顾客和其他相关方可用的确认活动的结果。关于其他支持过程，例如联合评审过程、审计过程、问题解关于其他支持过程，例如联合评审过程、审计过程、问题解决过程等，可参阅相关标准。决过程等，可参阅相关标准。关于关于验证和确认的执行验证和确认的执行不论是验证还是确认的不论是验证还是确认的”确定确定”,都要进行一个分析都要进行一个分析,即即:系统化地使用一些信息系统化地使用一些信息,对对”是否一致是否一致”这一问题给出估这一问题给出估算算.而评估即是一个比较而评估即是一个比较,如下所示如下所示:分析一般分为动态分析和静态分析分析一般分为动态分析和静态分析:-在动态分析中，以选定的输入在动态分析中，以选定的输入,有规程地执行程序或程序有规程地执行程序或程序段段,来得到一个估算来得到一个估算,例如某功能可正确执行例如某功能可正确执行,而在特定条件而在特定条件下下,会发生某类错误会发生某类错误.标尺标尺(目标目标)分析结果分析结果(主观的主观的)显然显然,测试获得的信息可作为分析中使用的信息测试获得的信息可作为分析中使用的信息.-静态分析是不执行程序的分析，例如模型评审、代码静态分析是不执行程序的分析，例如模型评审、代码“走走查查”以及程序的形式化验证等。以及程序的形式化验证等。可见可见,测试、分析和评估的关系可概括为测试、分析和评估的关系可概括为:分析分析评估评估评价评价测试测试支持测试获得的数据可作为测试获得的数据可作为分析中使用的信息分析中使用的信息+系统化地使用信息对一个系统化地使用信息对一个问题的估算问题的估算关于关于软件测试软件测试 概念概念 发现错误发现错误, ,减少错误带来风险的过程减少错误带来风险的过程. .环境环境被测对象被测对象人员素质人员素质被测对象模型被测对象模型测试执行测试执行正确正确?环境模型环境模型错误模型错误模型 软件测试过程所涉及的要素软件测试过程所涉及的要素,以及以及 这些要素之间的关系这些要素之间的关系正确正确测试过程模型测试过程模型（）（）error(错误错误)deviationfromtheintendeddesignwhichcouldresultinunintendedsystembehaviororfailure.与所期望的设计之间的偏差与所期望的设计之间的偏差,该偏差可能会产生不期望的系该偏差可能会产生不期望的系统行为或失效统行为或失效.（）（）fault(故障故障)abnormalconditionthatcouldleadtoanerrororafailureinasystem.Afaultcanberandomorsystematic导致错误或失效的不正常的条件导致错误或失效的不正常的条件.故障可以是偶然性的或是系故障可以是偶然性的或是系统性的统性的.（）（）failure(失效失效)deviationfromthespecifiedperformanceofasystem.Afailureistheconsequenceofafaultorerrorinasystem。与所规约的系统性能之间的偏差与所规约的系统性能之间的偏差.失效是系统的故障或错误的失效是系统的故障或错误的后果后果.(3)(3)组织过程组织过程（Organizational life cycle processesOrganizational life cycle processes）分为分为4 4个过程个过程：管理过程、基础设施过程、培训过程、改进过程管理过程、基础设施过程、培训过程、改进过程 管理过程管理过程基本过程基本过程支持过程支持过程组织过程组织过程组织为组织为基础设施过程基础设施过程培训过程培训过程过程改进过程过程改进过程例如例如3 3：管理过程：管理过程管理过程包括由管理其对应过程的任何一方所执行的一般管理过程包括由管理其对应过程的任何一方所执行的一般性活动和任务，管理人员负责：性活动和任务，管理人员负责：产品管理；产品管理；项目管理，以及项目管理，以及 对所应用的那些过程（例如，获取、供应、开发、运对所应用的那些过程（例如，获取、供应、开发、运行、维护或支持过程）的任务管理。行、维护或支持过程）的任务管理。主要活动包括主要活动包括:过程的启动和范围定义过程的启动和范围定义规划规划实施与控制实施与控制评审与评估评审与评估测量测量表决（表决（closure）其中的活动：其中的活动：过程的启动和范围定义过程的启动和范围定义 主要任务主要任务： 通过建立那些要承担的过程的需求，启动该管理过程通过建立那些要承担的过程的需求，启动该管理过程通过检查执行并管理这些过程所需要的资源（人通过检查执行并管理这些过程所需要的资源（人、物物 资资、技术和环境）是否可用技术和环境）是否可用、充分和适用，以及时间充分和适用，以及时间 上是否可达，来建立这些过程的可行性上是否可达，来建立这些过程的可行性 必要的话，按各方共识，修改这些过程的需求，以必要的话，按各方共识，修改这些过程的需求，以达成完成准则达成完成准则. . 其中的活动其中的活动: :规划规划 主要任务主要任务： 为过程的执行制定计划。该计划应包括有关活动和任务的为过程的执行制定计划。该计划应包括有关活动和任务的描述，并标识即将提供的软件产品。该计划的主要内容描述，并标识即将提供的软件产品。该计划的主要内容:既时完成任务的进度安排；既时完成任务的进度安排； 工作量的估计；工作量的估计； 执行任务所需要的适当资源；执行任务所需要的适当资源； 任务的分配；任务的分配； 职责的分派；职责的分派； 与任务或过程自身有关的风险与任务或过程自身有关的风险( (量化量化) )； 在整个过程中采用的质量控制测量；在整个过程中采用的质量控制测量； 与过程执行有关的费用；与过程执行有关的费用； 环境和基础设施的规约。环境和基础设施的规约。 其中的活动其中的活动: :实施与控制实施与控制 主要任务主要任务：启启动动管管理理计计划划的的实实施施，以以满满足足所所设设定定的的目目标标和和准准则则，并对过程实施控制。并对过程实施控制。 监监督督过过程程的的执执行行，提提供供过过程程进进展展的的内内部部报报告告，并并按按照照合同的规定向需方提供过程进展的外部报告。合同的规定向需方提供过程进展的外部报告。 调调查查、分分析析和和解解决决在在过过程程执执行行期期间间发发现现的的问问题题。问问题题的的解解决决可可能能导导致致对对计计划划的的变变更更。对对变变更更的的影影响响进进行行确确定定、控控制和监督。问题及其解决方案应形成文档。制和监督。问题及其解决方案应形成文档。 按按协协商商确确定定的的时时间间，报报告告过过程程进进展展情情况况，声声明明按按计计划划进进行行，并并解解决决进进展展中中的的疏疏漏漏情情况况。按按照照组组织织规规程程和和合合同同的的要要求，这种报告包括内部报告和外部报告。求，这种报告包括内部报告和外部报告。 其中的活动其中的活动: :评审与评估评审与评估 主要任务主要任务：对软件产品和计划进行评价，以确定是否满足需求。对软件产品和计划进行评价，以确定是否满足需求。 对对在在过过程程执执行行期期间间完完成成的的软软件件产产品品、活活动动和和任任务务的的评评价价结果进行评估，以确定是否达到目标和完成计划。结果进行评估，以确定是否达到目标和完成计划。 其中的活动其中的活动: :测量测量 主要任务主要任务：建建立立并并维维护护测测量量承承诺诺。确确保保满满足足所所有有的的测测量量过过程程的的资资源源、人人员员和和承承诺诺的的先先决决条条件件。该该任任务务的的结结果果是是:给给出出了了从从管管理理到到支支持持测测量量过过程程的的承承诺诺，提提供供了了在在该该标标准准已已为为测测量量过过程程标标识识并并分分配配职职责责方方面面的的人人员员能能力力，提提供供了了可可用用于于策策划划和和实施测量过程的资源。实施测量过程的资源。规规划划测测量量过过程程。制制定定一一个个详详细细的的计计划划以以启启动动、指指导导、监监督督并并评评价价数数据据收收集集、分分析析、解解释释和和存存储储活活动动。该该任任务务执执行行的的结结果果是是:提提供供了了一一些些规规划划信信息息，包包括括已已定定义义的的那那些些组组织织单单元元所所需需要要的的信信息息以以及及已已获获取取并并利利用用的的所所要要求求的的支支持持技技术。术。 按计划进行测量。根据测量计划任务的输出生成信息产按计划进行测量。根据测量计划任务的输出生成信息产品和性能测量（值）。该任务执行的结果能保证：收集到品和性能测量（值）。该任务执行的结果能保证：收集到数据、以适合于后续检索和分析的方式存储数据、生成信数据、以适合于后续检索和分析的方式存储数据、生成信息产品并通告组织单元、收集到性能测量（值）。息产品并通告组织单元、收集到性能测量（值）。评评价价测测量量。评评价价度度量量和和测测量量活活动动，并并此此次次评评价价中中所所学学到到的的经经验验存存储储在在“测测量量经经验验库库”中中。根根据据“测测量量经经验验库库”存存储储的的、来来自自于于本本次次评评价价的的经经验验和和特特定定准准则则来来评评价价测测量量活活动动和测量中的任务结果。和测量中的任务结果。其中的活动：表决其中的活动：表决主要任务主要任务：当所有软件产品、当所有软件产品、 活动和任务均完成时，应按照活动和任务均完成时，应按照合合同中或组织规程中规定的准则同中或组织规程中规定的准则,确定确定该过程是否完成该过程是否完成检查所软件产品、开展的活动和任务的结果和记录是检查所软件产品、开展的活动和任务的结果和记录是 否完整这些结果和记录均应按合同中的规定在适当否完整这些结果和记录均应按合同中的规定在适当 的环境中予以归档的环境中予以归档例如：例如：基础设施基础设施过程过程基础设施过程是为其他过程建立和维护所需基础设施的基础设施过程是为其他过程建立和维护所需基础设施的过程。基础设施可以包括用于开发、运行或维护的硬件、软过程。基础设施可以包括用于开发、运行或维护的硬件、软件、工具、技术、标准和设施。件、工具、技术、标准和设施。包括下述活动：包括下述活动： a) a) 过程实施的准备；过程实施的准备； b) b) 建立基础设施；建立基础设施； c) c) 维护基础设施。维护基础设施。 基础设施过程基础设施过程中的活动中的活动: :过程实施的准备过程实施的准备主要任务主要任务: : 为满足使用这一过程的那些过程的需求为满足使用这一过程的那些过程的需求, ,考虑适用的规考虑适用的规 程、标准、工具和技术，定义基础设施并建立相应的程、标准、工具和技术，定义基础设施并建立相应的 文档。文档。 制定制定基础设施计划并形成文档。基础设施计划并形成文档。 基础设施过程基础设施过程中的活动中的活动: : 建立基础设施建立基础设施主要任务主要任务： 制定制定基础设施配置计划并形成文档基础设施配置计划并形成文档, ,其中应考虑功能、性其中应考虑功能、性 能、安全、安全保密、可用性、空间要求、设备、费用能、安全、安全保密、可用性、空间要求、设备、费用 和时间约束。和时间约束。 为了实施有关过程，及时安装基础设施。为了实施有关过程，及时安装基础设施。基础设施过程基础设施过程中的活动中的活动: : 基础设施维护基础设施维护主要任务主要任务: : 维护、监督和改进基础设施，以确保基础设施持续地满足维护、监督和改进基础设施，以确保基础设施持续地满足 应用本过程的过程要求。其中应确定将基础设施置于配置应用本过程的过程要求。其中应确定将基础设施置于配置 管理之下的程度。管理之下的程度。例如例如5 5：改进过程改进过程是一个建立、评估、测量、控制和改进软件生存周期过程是一个建立、评估、测量、控制和改进软件生存周期过程的过程。的过程。 主要活动主要活动： 过程建立过程建立 过程评估过程改进过程评估过程改进 其中的活动其中的活动: :过程建立过程建立主要任务：主要任务： 建建立立一一组组适适合合于于所所有有软软件件生生存存周周期期过过程程的的组组织织过过程程，以以应应用用到到其其业业务务活活动动中中。这这些些过过程程及及其其在在特特定定情情况况下下的的应应用用应应在在组组织织的的出出版版物物中中形形成成文文档档。合合适适时时，应应建建立立过过程程控控制制机制，以便开发、监督、控制和改进这些过程。机制，以便开发、监督、控制和改进这些过程。其中的活动其中的活动: : 过程评估过程评估主要任务主要任务： 制定过程评估规程，将其形成文档并加以应用。应保存制定过程评估规程，将其形成文档并加以应用。应保存 并维护评估记录。并维护评估记录。 规划过程评审并按适当的间隔进行之，以确保评估结果规划过程评审并按适当的间隔进行之，以确保评估结果 具有明显的、持续的合适性和有效性。具有明显的、持续的合适性和有效性。其中的活动其中的活动:过程改进过程改进主要任务主要任务： 当当过过程程评评估估和和评评审审的的结结果果表表明明必必要要时时，对对其其过过程程实实施施改改进。其中过程文档应及时更新，以反映组织过程的改进。进。其中过程文档应及时更新，以反映组织过程的改进。 收收集集并并分分析析历历史史的的、技技术术的的和和评评价价的的数数据据，以以增增进进对对已已应应用用过过程程的的强强项项和和弱弱项项的的了了解解。这这些些分分析析应应作作为为反反馈馈信信息息，以以便便改改进进过过程程，建建议议改改变变项项目目（或或后后续续项项目目）的的方方向向和和确确定定技技术改进的需要。术改进的需要。 收收集集、维维护护和和使使用用质质量量成成本本数数据据，以以改改进进组组织织的的过过程程。这这些些数数据据应应用用于于建建立立预预防防和和解解决决在在软软件件产产品品和和服服务务中中的的问问题题和和不符合项的成本。不符合项的成本。3) 3) 软件过程之间的关系软件过程之间的关系获取过程获取过程获取过程供应过程供应过程管理过程管理过程运行过程运行过程开发过程开发过程维护过程维护过程获取者获取者供应者供应者管理者管理者运行者运行者用用户户开发者开发者维护者维护者开发者开发者维护者维护者组织过程：管理、改进组织过程：管理、改进.支持过程：文档、质量保证、支持过程：文档、质量保证、配置管理配置管理.合合同同使使用用合同观点合同观点管理观点管理观点运行观点运行观点开发观点开发观点支持观点支持观点(4)剪裁过程：剪裁过程：剪裁过程是针对某一软件产品对本标准进行基本剪裁的剪裁过程是针对某一软件产品对本标准进行基本剪裁的一个过程。一个过程。主要活动包括主要活动包括:a)标识项目环境；标识项目环境；b)请求输入；请求输入；c)选择过程、活动和任务；选择过程、活动和任务；d)将剪裁决定和理由形成文档。将剪裁决定和理由形成文档。(1)标识项目环境标识项目环境主要任务主要任务:标识影响剪裁的项目环境特性。环境特性可能是：标识影响剪裁的项目环境特性。环境特性可能是：生存周期模型；当前的系统生存周期活动；系统和软件生存周期模型；当前的系统生存周期活动；系统和软件需求；组织的方针、规程和策略；系统、软件产品或服需求；组织的方针、规程和策略；系统、软件产品或服务的规模、关键性和类型；以及涉及的人员数量和参与务的规模、关键性和类型；以及涉及的人员数量和参与方。方。(2)请求输入请求输入主要任务：主要任务：从受剪裁决策所影响的那些组织中请求输入。用户、支持从受剪裁决策所影响的那些组织中请求输入。用户、支持 人员、签订合同的官员、潜在的投标者均应参与剪裁。人员、签订合同的官员、潜在的投标者均应参与剪裁。(3)选择过程、活动和任务选择过程、活动和任务主要任务：主要任务：确确定定要要执执行行的的过过程程、活活动动和和任任务务，其其中中包包括括需需要要编编写写的的文档以及负责这些过程、活动和任务的人员。文档以及负责这些过程、活动和任务的人员。 对对于于那那些些没没有有在在本本标标准准中中规规定定的的过过程程、活活动动和和任任务务, ,应应在在合合同同中中予予以以规规定定。并并对对生生存存周周期期组组织织过过程程进进行行评评价价, ,以以确确定相关组织能否提供这些过程、活动和任务。定相关组织能否提供这些过程、活动和任务。 针针对对给给定定的的项项目目或或业业务务范范围围, ,仔仔细细考考虑虑1220712207中中给给出出的的这这些些任任务务，确确定定它它们们是是否否应应当当保保留留或或删删除除。其其中中需需要要考考虑虑的的因因素素包包括括风风险险、费费用用、日日程程、性性能能、规规模模、关关键键性性以以及及人人机机界面等。界面等。(4)将剪裁决定和理由形成文档将剪裁决定和理由形成文档主要任务：主要任务：将所有剪裁决定和作出决定的理由形成文档。将所有剪裁决定和作出决定的理由形成文档。2开发活动的组织开发活动的组织 -软件生存周期模型软件生存周期模型) )基本概念基本概念 软件生存周期模型软件生存周期模型IEEEStandard12207.0-1996把一个软件生存周期模型描述为：一个包括软件产品开把一个软件生存周期模型描述为：一个包括软件产品开发、运行和维护中有关过程、活动和任务的框架，覆盖了从该发、运行和维护中有关过程、活动和任务的框架，覆盖了从该系统的需求定义到系统的使用终止。系统的需求定义到系统的使用终止。中国计算机科学与技术百科全书中国计算机科学与技术百科全书称软件生存周期模型为称软件生存周期模型为“软件开发模型软件开发模型”，并把它定义为：，并把它定义为：软件过程、活动、任务的结构框架。软件过程、活动、任务的结构框架。系统需求系统需求软件需求软件需求需求分析需求分析设设计计编编码码测测试试运运行行归纳逻辑：归纳逻辑： P P Q Q P P Q Q )瀑布模型瀑布模型1970年，年，W.RoyceThe basis for mostcurrent practice and hasmany variations. Its namecome from the progressionof activities based on theoutputofonephase“falling” as input to thefollowingphase.Itisdrivenby the needs to scheduleprojectmilestoneswhichareprovidedbythecompletionofdocumentsateachlevelorphase.（）（）项目的开发依次经过：需求、设计、编码和单元测试、项目的开发依次经过：需求、设计、编码和单元测试、 集成以及维护集成以及维护 这一基本路径。这一基本路径。 （）在每一阶段提交以下产品：软件需求规约、设计文档、（）在每一阶段提交以下产品：软件需求规约、设计文档、 实际代码、测试用例、最终产品等。工作产品（又称可实际代码、测试用例、最终产品等。工作产品（又称可提提交交的的产产品品，DeliverablesDeliverables） 流流经经“正正向向”开开发发的的基基本本步步骤路径。骤路径。 （）“反反向向”步步骤骤流流表表示示对对前前一一个个可可提提交交产产品品的的重重复复变变更更（又（又称为称为“返工返工”(Rework)(Rework)） 。 由于所有开发活动的非确定性，因此是否需要重复变由于所有开发活动的非确定性，因此是否需要重复变更，这仅在下一个阶段或更后的阶段才能认识到。更，这仅在下一个阶段或更后的阶段才能认识到。 返工不仅在以前阶段的某一地方需要，而且对当前正返工不仅在以前阶段的某一地方需要，而且对当前正在进行的工作也是需要的。在进行的工作也是需要的。关于瀑布模型的几点说明关于瀑布模型的几点说明( (）瀑布模型的优点）瀑布模型的优点 虽然瀑布模型是一个比较虽然瀑布模型是一个比较“老老”的、甚至过时的开发模型，的、甚至过时的开发模型，但其优点为：但其优点为： 在决定系统怎样做之前，存在一个需求阶段，鼓励对系在决定系统怎样做之前，存在一个需求阶段，鼓励对系 统统“做什么做什么”进行规约（即设计之前的规约）。进行规约（即设计之前的规约）。 在建造构件之前，存在一个设计阶段，鼓励规划系统结在建造构件之前，存在一个设计阶段，鼓励规划系统结 构（即编码之前的设计）。构（即编码之前的设计）。 在每一阶段结束时进行复审，允许获取方和用户的参与。在每一阶段结束时进行复审，允许获取方和用户的参与。 允许基线和配置早期接受控制。允许基线和配置早期接受控制。 前一步工作产品可作为下一步被认可的、文档化的基线。前一步工作产品可作为下一步被认可的、文档化的基线。（）（）瀑布模型存在的不足瀑布模型存在的不足 客户必须能够完整、正确和清晰地表达他们的需求；开发客户必须能够完整、正确和清晰地表达他们的需求；开发 人员一开始就必须理解其应用。人员一开始就必须理解其应用。 在开始的两个或三个阶段中，很难评估真正的进度状态在开始的两个或三个阶段中，很难评估真正的进度状态; ; 设计、编码和测试阶段都可能发生延期。设计、编码和测试阶段都可能发生延期。 在一个项目的早期阶段，过分地强调了基线和里程碑处在一个项目的早期阶段，过分地强调了基线和里程碑处 的文档的文档; ;可能要花费更多的时间，用于建立一些用处不可能要花费更多的时间，用于建立一些用处不 大的文档。大的文档。 当接近项目结束时，出现了大量的集成和测试工作。当接近项目结束时，出现了大量的集成和测试工作。 直到项目结束之前，都不能演示系统的能力。直到项目结束之前，都不能演示系统的能力。（3）瀑布模型适用的情况瀑布模型适用的情况在开发中，向下、渐进的路径占支配地位。也就是说，在开发中，向下、渐进的路径占支配地位。也就是说， 需求已被很好地理解；并且需求已被很好地理解；并且 过程设计人员也很清楚：开发组织非常熟悉为实现这一模过程设计人员也很清楚：开发组织非常熟悉为实现这一模 型所需要的过程（或经过培训后，熟悉什么时候来支持这型所需要的过程（或经过培训后，熟悉什么时候来支持这 一项目，以实现这一模型所需要的过程）。一项目，以实现这一模型所需要的过程）。因此为了避免产生过多因此为了避免产生过多的反复迭代工作，增加开发成本，的反复迭代工作，增加开发成本，一般在准备采用瀑布模型一般在准备采用瀑布模型(也包括其他模型也包括其他模型)时，需要考虑以下时，需要考虑以下2个问题：第一个问题是，过程设计人员必须对初始产品个问题：第一个问题是，过程设计人员必须对初始产品(通常通常是软件需求规约，是软件需求规约，SRS)的不确定性进行评估。的不确定性进行评估。另一个问题是，组织是否具有熟练实施每个活动和另一个问题是，组织是否具有熟练实施每个活动和任务的历史经验。任务的历史经验。13259101167121384增量增量1 1 1,2,5,9 1,2,5,9 增量增量2 2 3 3,6,7,4,10,11 ,6,7,4,10,11 增量增量3 3 8 8,12,13 ,12,13 管理管理增量规约增量规约增量设计增量设计纠错性分析纠错性分析增量实现增量实现增量1增量2增量33)增量模型增量模型该模型有一个假设，即需求可以分段，成为一系列增该模型有一个假设，即需求可以分段，成为一系列增量产品，每一增量可以分别地开发。量产品，每一增量可以分别地开发。关于增量模型的几点说明：关于增量模型的几点说明：(1(1）增量模型的优点）增量模型的优点 作为瀑布模型的第一个变体，具有瀑布模型的所有优点。作为瀑布模型的第一个变体，具有瀑布模型的所有优点。 此外，它还有以下优点：此外，它还有以下优点： 第一个可交付版本所需要的成本和时间是很少的；第一个可交付版本所需要的成本和时间是很少的； 开发由增量表示的小系统所承担的风险是不大的；开发由增量表示的小系统所承担的风险是不大的； 由于很快发布了第一个版本，因此可以减少用户需求由于很快发布了第一个版本，因此可以减少用户需求 的变更；的变更； 允许增量投资，即在项目开始时，可以仅对一个或两允许增量投资，即在项目开始时，可以仅对一个或两 个增量投资。个增量投资。 ( (）缺点：）缺点： 如果增量模型不适于某些项目，或使用有误，则有如果增量模型不适于某些项目，或使用有误，则有以下缺点：以下缺点： 如果没有对用户的变更要求进行规划，那么产生的初始如果没有对用户的变更要求进行规划，那么产生的初始 增量可能会造成后来增量的不稳定；增量可能会造成后来增量的不稳定； 如果需求不像早期思考的那样稳定和完整，那么一些增如果需求不像早期思考的那样稳定和完整，那么一些增 量就可能需要重新开发，重新发布；量就可能需要重新开发，重新发布； 管理发生的成本、进度和配置的复杂性，可能会超出组管理发生的成本、进度和配置的复杂性，可能会超出组 织的能力。织的能力。 注：如果采用增量投资方式，那么客户就可以对一些增量进注：如果采用增量投资方式，那么客户就可以对一些增量进行招标。然后，开发人员按提出的截止期限进行增量开发，这行招标。然后，开发人员按提出的截止期限进行增量开发，这样客户就可以用多个契约来管理组织的资源和成本。样客户就可以用多个契约来管理组织的资源和成本。( (）该模型的适用情况）该模型的适用情况 在在开开始始开开发发时时，需需求求很很明明确确，且且产产品品还还可可被被适适当当地地分分解解为为一一些些独独立立的的、可可交交付付的的软软件件（构构造造增增量量：Build Build incrementsincrements如如果果一一个个增增量量并并不不需需要要交交付付给给客客户户的的话话，那那么么这这样样的的增增量量通通常常称称为为一一个个“构构造造”(Build)。如如果果增增量量被被交交付付，那那么么它它们们就就被被认认为为是发布版本是发布版本(Releasedversion)。 ）；）； 在开发中，期望尽快提交其中的一些增量产品。在开发中，期望尽快提交其中的一些增量产品。 例如：例如：一个数据库系统，它必须通过不同的用户界面，为不同类型的一个数据库系统，它必须通过不同的用户界面，为不同类型的用户提供不同的功能。在这一情况下，首先实现完整的数据库用户提供不同的功能。在这一情况下，首先实现完整的数据库设计，并把一组具有高优先级的用户功能和界面作为一个增量；设计，并把一组具有高优先级的用户功能和界面作为一个增量；以后，陆续构造其它类型用户所需求的增量。以后，陆续构造其它类型用户所需求的增量。附：微软附：微软“同步同步- -稳定的产品开发模型稳定的产品开发模型” 将项目分为若干个里程碑阶段将项目分为若干个里程碑阶段 定义稳定、灵活的体系结构，并为构件定义稳定、灵活的体系结构，并为构件 和子系统的开发提供统一的接口和子系统的开发提供统一的接口 开发构件，维持一个可发布的系统版本开发构件，维持一个可发布的系统版本 可以准确把握项目进展情况可以准确把握项目进展情况 增强开发人员的信心和成就感增强开发人员的信心和成就感 可以随时根据市场情况及时作出调整可以随时根据市场情况及时作出调整需求需求设计设计编码编码测试测试集成集成需求需求设计设计编码编码测试测试集成集成开开发发反反馈馈开开发发反反馈馈.核核心心系系统统开开发发第第二二次次迭迭代代)演化模型（演化模型（Evolutionary modelEvolutionary model）是一种有弹性的过程模式，由一些小的开发步组成，每一是一种有弹性的过程模式，由一些小的开发步组成，每一步历经需求分析、设计、实现和验证，产生软件产品的一个增步历经需求分析、设计、实现和验证，产生软件产品的一个增量。通过这些迭代，完成最终软件产品的开发。量。通过这些迭代，完成最终软件产品的开发。 针对事先不能完整地定义需求针对事先不能完整地定义需求 针对用户的核心需求针对用户的核心需求, ,开发核心系统开发核心系统 根据用户的反馈根据用户的反馈, ,实施活动的迭代实施活动的迭代关于演化模型的几点说明关于演化模型的几点说明(1(1）主要特征）主要特征 该模型显式地把增量模型扩展到需求阶段。由图可以看出，该模型显式地把增量模型扩展到需求阶段。由图可以看出，为了第二个构造增量，使用了第一个构造增量来精化需求。为了第二个构造增量，使用了第一个构造增量来精化需求。这一精化可以有多个来源和路径。这一精化可以有多个来源和路径。 首先，如果一个早期的增量已向用户发布，那么用户会以变首先，如果一个早期的增量已向用户发布，那么用户会以变更要求的方式提出反馈，以支持以后增量的需求开发。更要求的方式提出反馈，以支持以后增量的需求开发。 第二，通过实实在在地开发一个构造增量，为以前还没有认第二，通过实实在在地开发一个构造增量，为以前还没有认识到的问题提供了可见性，以便实际地开始这一增量的工作。识到的问题提供了可见性，以便实际地开始这一增量的工作。(2(2）与瀑布模型的关系）与瀑布模型的关系 在在演演化化模模型型中中，仍仍然然可可以以使使用用瀑瀑布布模模型型来来管管理理每每一一个个演演化化的的增增量量。一一旦旦理理解解了了需需求求，就就可可以以像像实实现现瀑瀑布布模模型型那那样样开开始始设设计计阶阶段和编码阶段。段和编码阶段。(3(3）使用演化模型应注意的问题）使用演化模型应注意的问题 不不能能弱弱化化需需求求分分析析阶阶段段的的工工作作。其其原原因因是是：在在项项目目开开始始时时，考考虑虑所所有有需需求求来来源源的的重重要要性性和和风风险险，对对这这些些来来源源的的可可用用性性进进行行评评估估。只只有有采采用用这这一一方方法法，才才能能识识别别和和界界定定不不确确定定的的需需求求，并并识识别别第一个增量中所包含的需求。第一个增量中所包含的需求。(4(4）演化模型的长处和不足）演化模型的长处和不足 演化模型还具有以下优点：与增量模型是类似的。特别地，演化模型还具有以下优点：与增量模型是类似的。特别地， 在需求不能予以规约时，可以使用这一演化模型。在需求不能予以规约时，可以使用这一演化模型。 用户可以通过运行系统的实践，对需求进行改进。用户可以通过运行系统的实践，对需求进行改进。 与瀑布模型相比，需要更多用户与瀑布模型相比，需要更多用户/ /获取方的参与。获取方的参与。 缺点有：缺点有： 演化模型的使用仍然处于探索阶段，因此具有较大演化模型的使用仍然处于探索阶段，因此具有较大 的风险，需要有力的管理。的风险，需要有力的管理。 演化模型的使用很容易成为不编写需求或设计文档的借口，演化模型的使用很容易成为不编写需求或设计文档的借口， 即使很好地理解了需求或设计。即使很好地理解了需求或设计。 用户用户/ /获取方不易理解演化模型的自然属性，因此当结果不获取方不易理解演化模型的自然属性，因此当结果不 够理想时，可能产生抱怨。够理想时，可能产生抱怨。演化演化维护维护确认确认实现实现设计设计分析分析)喷泉模型喷泉模型 特征：迭代特征：迭代无缝无缝 与面向对象技术与面向对象技术的关系的关系)螺旋模型螺旋模型 该模型是由该模型是由Dr. Barry Boehm Boehm 1988Dr. Barry Boehm Boehm 1988开发的。开发的。该模型将软件生存周期的活动分为四个可重复的阶段：该模型将软件生存周期的活动分为四个可重复的阶段：规划、风险分析、开发和评估：规划、风险分析、开发和评估：项目的进度是项目的进度是“螺旋螺旋”式的。式的。riskanalysisstageDevelopmentstagePlanningstageEvaluationstagestartResourceuse其中：其中：评估和风险分析阶段都可作出一个决策：项目是否继续。评估和风险分析阶段都可作出一个决策：项目是否继续。螺旋循环的次数指示了已消耗的资源；螺旋循环的次数指示了已消耗的资源； 在规划阶段、风险分析阶段和开发阶段均进行需求规约活在规划阶段、风险分析阶段和开发阶段均进行需求规约活动；动；在早期螺旋循环中，为了为最终的实现给出一些指导性决在早期螺旋循环中，为了为最终的实现给出一些指导性决策，经常使用原型构造；策，经常使用原型构造； 设计和实现活动一般是在开发阶段进行；设计和实现活动一般是在开发阶段进行；V&V活动在开发阶段和评估阶段进行；活动在开发阶段和评估阶段进行；关于螺旋模型的几点说明：关于螺旋模型的几点说明：(1(1）该模型关注解决问题的基本步骤）该模型关注解决问题的基本步骤: :标识问题标识问题; ;标识一些标识一些 可选方案，选择一个最佳方案可选方案，选择一个最佳方案; ;遵循动作步骤，并实施遵循动作步骤，并实施 后续工作。其中只要完成了开发的一个迭代，开发的另后续工作。其中只要完成了开发的一个迭代，开发的另 一个迭代就开始。一个迭代就开始。(2(2）螺旋模型的一个特征是，实际上只有一个迭代过程真正）螺旋模型的一个特征是，实际上只有一个迭代过程真正 开发可交付的软件。因此开发可交付的软件。因此, ,如果如果 项目的开发风险很大，或项目的开发风险很大，或 客户不能确定系统需求，在更广泛的意义上来讲，还客户不能确定系统需求，在更广泛的意义上来讲，还 包括系统或系统类型的要求，包括系统或系统类型的要求， 这时螺旋模型就是一个好的生存周期模型。这时螺旋模型就是一个好的生存周期模型。(3) (3) 与其它模型的关系与其它模型的关系 与与演演化化模模型型一一样样，螺螺旋旋模模型型也也使使用用瀑瀑布布模模型型作作为为一一个个嵌嵌入入的的过过程程- -即即分分析析、设设计计、编编码码、实实现现和和维维护护的的瀑瀑布布过过程程，是是螺螺旋一周的组成部分。旋一周的组成部分。 尽尽管管螺螺旋旋模模型型和和一一些些迭迭代代模模型型在在框框架架和和全全局局体体系系结结构构方方面面是等同的，但所关注的是等同的，但所关注的阶段阶段以及它们的以及它们的活动活动是不同的。是不同的。 具具体体地地说说：标标识识客客户户想想要要的的是是一一个个什什么么样样的的系系统统；确确定定风风险险和和效效益益的的可可选选路路线线； 选选择择最最优优方方案案；开开发发系系统统；评评估完成情况等；估完成情况等；重新开始。重新开始。 即即 螺螺旋旋模模型型扩扩展展了了增增量量模模型型的的管管理理任任务务范范围围。而而增增量量模模型型是是基基于于以以下下假假定定：需需求求是是最最基基本本的的、并并且且是是唯唯一一的的风风险险源源。而而在螺旋模型中，决策和降低风险的空间是相当广泛的。在螺旋模型中，决策和降低风险的空间是相当广泛的。7)模型中的三个重要修饰模型中的三个重要修饰原型、并发、商业构件的复用。原型、并发、商业构件的复用。（1 1）原型与）原型与原型原型构造构造 何谓原型何谓原型 显式地规划如何使用一个或多个演化的增量，这作为一个显式地规划如何使用一个或多个演化的增量，这作为一个明确的需求揭示工具明确的需求揭示工具, , 是生存周期模型的发展的必然。是生存周期模型的发展的必然。 遵循其它工程领域所使用的术语，我们把这样的一个增量遵循其它工程领域所使用的术语，我们把这样的一个增量称为一个原型。称为一个原型。 注：尽管原型可以由用户以某一受限的方式使用，但注：尽管原型可以由用户以某一受限的方式使用，但不能把原型看作是一个具有完备功能的增量。不能把原型看作是一个具有完备功能的增量。 原型的作用原型的作用 揭示那些以后将在具有完备功能的、可交付的、可支持的揭示那些以后将在具有完备功能的、可交付的、可支持的增量中予以实现的需求。增量中予以实现的需求。 可以用于为一个项目或一个项目的某些部分，确定技术、可以用于为一个项目或一个项目的某些部分，确定技术、成本和进度的可能性。例如，原型有助于回答以下问题：成本和进度的可能性。例如，原型有助于回答以下问题：一个新的开发环境或工具，是否能够满足客户成本和进一个新的开发环境或工具，是否能够满足客户成本和进 度约束？度约束？一个被安装的、可用的软一个被安装的、可用的软/ /硬件基础设施，是否可以支持硬件基础设施，是否可以支持 客户新的性能和能力需求？客户新的性能和能力需求？ 是否能够创建这一产品，即这是可行的吗？是否能够创建这一产品，即这是可行的吗？ 原型构造原型构造 原型构造，有时它也被称为快速应用开发（原型构造，有时它也被称为快速应用开发（Rapid Rapid ApplicationApplicationDevelopment, RADDevelopment, RAD）。）。适用范围：适用范围：对那些具有较多用户界面和数据库的系统开发中，可使对那些具有较多用户界面和数据库的系统开发中，可使用之用之 使用条件使用条件： 需要相应需要相应RADRAD方法和工具的支持。方法和工具的支持。注：近年来，由于注：近年来，由于VBVB（Visual BasicVisual Basic）、）、DelphiDelphi、。、。NETNET等开发环境的出现，这一术语得到了广泛的应用，使用这些等开发环境的出现，这一术语得到了广泛的应用，使用这些工具几乎可以无缝地建造原型和最终系统。工具几乎可以无缝地建造原型和最终系统。如何使用如何使用： 首先给出首先给出一个原型的目标陈述，其中包括为实现这一个原型的目标陈述，其中包括为实现这一目标所需要的特定需求。一目标所需要的特定需求。 随后进行设计。其中应选择一组可用的工具，用于实现随后进行设计。其中应选择一组可用的工具，用于实现该系统的原型，而后当设计完成之后，开发人员就建造该系统的原型，而后当设计完成之后，开发人员就建造这一原型，即实现对客户可见的或强调一个关键技术风这一原型，即实现对客户可见的或强调一个关键技术风险的那些方面。险的那些方面。 最后最后，通过某种形式，对原型进行评估。，通过某种形式，对原型进行评估。 评估方法：通常是把原型交给客户，进行试用。评估方法：通常是把原型交给客户，进行试用。 原型试用的目标是：原型试用的目标是：揭示客户界面的需求。揭示客户界面的需求。 通过通过客户与一个原型系统的交互，提出反馈，明确或揭客户与一个原型系统的交互，提出反馈，明确或揭示客户的功能和性能需求。示客户的功能和性能需求。随后，开发人员可依据这一反馈，基于所使用的生随后，开发人员可依据这一反馈，基于所使用的生存周期模型，再将这些需求精化并实现之。存周期模型，再将这些需求精化并实现之。原型构造在应用中的风险原型构造在应用中的风险 用户和开发人员不能很好地判断将一个原型变成一个具有用户和开发人员不能很好地判断将一个原型变成一个具有完整功能的系统需要多少工作。完整功能的系统需要多少工作。 由于客户看到的是一个精化、复杂的用户界面，于是他们由于客户看到的是一个精化、复杂的用户界面，于是他们 就可能认为系统开发的大部分工作已经完成。就可能认为系统开发的大部分工作已经完成。 一旦由于感觉构造的原型看起来是乎是相当成功的，这一旦由于感觉构造的原型看起来是乎是相当成功的，这 样样，原原型型就就有有可可能能以以一一种种无无规规划划的的方方式式“成成长长”，以以至至于于超超出了系统的期望或要求，为了最终版本，耗尽进度、资金出了系统的期望或要求，为了最终版本，耗尽进度、资金和人力，付出了很高的代价。换言之，它违背了所指出的和人力，付出了很高的代价。换言之，它违背了所指出的计划，即它是第一个增量的交付。计划，即它是第一个增量的交付。可能发生原型开发组与最终产品开发组之间的交流和学习可能发生原型开发组与最终产品开发组之间的交流和学习不能是充分的，例如原型构造组是一个独立组织功能的一不能是充分的，例如原型构造组是一个独立组织功能的一部分，如市场策划。另外，原型开发所使用的工具与整个部分，如市场策划。另外，原型开发所使用的工具与整个开发工作所使用的工具可能无法实现互操作。开发工作所使用的工具可能无法实现互操作。不论在性能方面还是在能力方面，都无法对原型进行度不论在性能方面还是在能力方面，都无法对原型进行度量，以确定实现的程度。量，以确定实现的程度。 有时，由于有时，由于原型并没有必要支持系统所有功能，因此原型原型并没有必要支持系统所有功能，因此原型实际执行的功能（它所实现的）可能甚至好于一个可交付实际执行的功能（它所实现的）可能甚至好于一个可交付的功能。在这种情况下，从原型到整个系统的进行中，客的功能。在这种情况下，从原型到整个系统的进行中，客户就有可能会遗漏一些事情，而说明这种情况又可能是非户就有可能会遗漏一些事情，而说明这种情况又可能是非常困难的。常困难的。如何解决这些风险如何解决这些风险： 在项目早期，原型开发组标识并监控以上这些风险在项目早期，原型开发组标识并监控以上这些风险进一步说，即使对它们实施了管理，所有这些风险也进一步说，即使对它们实施了管理，所有这些风险也可能发生到一定程度，但关键的问题是它们必须被识可能发生到一定程度，但关键的问题是它们必须被识别并被管理。别并被管理。（）生存周期模型中的并发（）生存周期模型中的并发 问题的提出：问题的提出： 当一个工作当一个工作程序程序经过其所选择的生存周期时，一些过程之经过其所选择的生存周期时，一些过程之间的重叠几乎是不可避免的，不论这一重叠是规划的还是没间的重叠几乎是不可避免的，不论这一重叠是规划的还是没有规划的。有规划的。 例例如如，即即使使在在需需求求是是非非常常清清楚楚的的，出出于于对对成成本本和和进进度度的的考考虑虑，可可能能就就选选择择通通常常的的瀑瀑布布模模型型的的情情况况下下，表表面面上上看看，这这排排除除了了并并发发的的可可能能性性事事实实上上这这是是非非常常困困难难的的。例例如如，如如果果一一个个子子系系统统的的详详细细设设计计在在另另一一个个子子系系统统之之前前完完成成，并并且且这这两两个个子子系系统统之之间间的的接接口口是是稳稳定定的的，那那么么就就可可以以提提前前对对已已完完成成详详细细设设计计的的那那个个子子系系统统进进行行编编码码，从从而而导导致致一一个个系系统统的的详详细细设设计计阶段和编码阶段的并发。阶段和编码阶段的并发。还要注意，在所有生存周期模型的反向流（即对已经完成的还要注意，在所有生存周期模型的反向流（即对已经完成的一个文档或其它产品必须要做的改变）中，也可能隐含地存在一个文档或其它产品必须要做的改变）中，也可能隐含地存在 一些并发。一些并发。使用并发的基本要求使用并发的基本要求 -要求要求组织的管理必须有能力支持并发，包括进度安排、组织的管理必须有能力支持并发，包括进度安排、成本控制、状态跟踪和配置管理系统，包括技术复审机制成本控制、状态跟踪和配置管理系统，包括技术复审机制和任何设计工具。和任何设计工具。 -如果两个子系统同时处在同样的开发阶段，那么就要求如果两个子系统同时处在同样的开发阶段，那么就要求严格监控这两个子系统之间的界面。严格监控这两个子系统之间的界面。 使用中的问题使用中的问题围绕并发的使用，存在以下两个重要的问题：围绕并发的使用，存在以下两个重要的问题： 并发程度。并发程度。并发的程度可以并发的程度可以从偶然的，只有少量反向改变的要求；从偶然的，只有少量反向改变的要求； 到过分的，存在一个增量正在设计，而前面那个增量到过分的，存在一个增量正在设计，而前面那个增量正在集成。正在集成。 注意：以上两种情况，对技术系统和管理系统的需求是非注意：以上两种情况，对技术系统和管理系统的需求是非 常不同的。常不同的。 并发的管理。并发的管理。一旦出现并发，就要很好地进行规划。其中应重视由于使一旦出现并发，就要很好地进行规划。其中应重视由于使用并发所出现的这些问题。用并发所出现的这些问题。（3 3）商业构件的复用）商业构件的复用 问题的提出问题的提出 现代软件系统的创建趋势是，使用商业应用框架和商业构现代软件系统的创建趋势是，使用商业应用框架和商业构件，或复用组织内部已开发的构件和框架，当然，也复用组件，或复用组织内部已开发的构件和框架，当然，也复用组织的实践和规程。这一趋势的出现，有以下三个原因：织的实践和规程。这一趋势的出现，有以下三个原因： （1 1）. .市场和成本的竞争压力；市场和成本的竞争压力； （2 2）. .交付环境的日趋复杂和标准化，例如交付环境的日趋复杂和标准化，例如InternetInternet； （3 3）. .产品线工程的出现，其中系统地规划和实施：产品线工程的出现，其中系统地规划和实施： 多多个个相相关关软软件件产产品品的的开开发发和和演演化化； 那那些些可可复复用用的的设设计计和和 实现；实现； 用于产品线的所有产品。用于产品线的所有产品。这趋势意味着：这趋势意味着： 一个项目生存周期过程的意义，可能从毫无意义，一直一个项目生存周期过程的意义，可能从毫无意义，一直到意义深远。例如，到意义深远。例如， 如果开发组织使用一个新的商业应用框架来建造一个产如果开发组织使用一个新的商业应用框架来建造一个产品，那么就需要开发一个原型，以获得框架使用的经验，并品，那么就需要开发一个原型，以获得框架使用的经验，并检验该框架对这一应用的适应性。检验该框架对这一应用的适应性。 如果使用的框架是组织内部开发的，那么也需要开发一个如果使用的框架是组织内部开发的，那么也需要开发一个原型，以评估该框架对应用开发的的适应性。原型，以评估该框架对应用开发的的适应性。 框架的选择就是这样一个基本的设计决策，以至于必须在框架的选择就是这样一个基本的设计决策，以至于必须在项目生存周期的早期实施原型构造。如果可能的话，原型构项目生存周期的早期实施原型构造。如果可能的话，原型构造应在承约项目的成本和进度之前实施。造应在承约项目的成本和进度之前实施。 商业构件的使用商业构件的使用 如果使用内部开发的构件或市场购买的构件，作为新系如果使用内部开发的构件或市场购买的构件，作为新系统的组成部分，那么就必须在项目早期评估这些构件的适应统的组成部分，那么就必须在项目早期评估这些构件的适应性。确切地说，怎样使用这些构件，什么时候评估这些构件。性。确切地说，怎样使用这些构件，什么时候评估这些构件。例如，如果产品的的很大部分都涉及与用户的交互，那么就应例如，如果产品的的很大部分都涉及与用户的交互，那么就应该仔细地评估实现图形用户界面的构件，以确保它们支持所要该仔细地评估实现图形用户界面的构件，以确保它们支持所要求的功能。在操作文档开发之后，就应立即进行这一评估。求的功能。在操作文档开发之后，就应立即进行这一评估。如果一个商业构件为产品提供较少的但是很关键的部分，如果一个商业构件为产品提供较少的但是很关键的部分，那么就应该在设计阶段之前或期间对其进行评估，一旦发现构那么就应该在设计阶段之前或期间对其进行评估，一旦发现构件不适合该产品，就要建造一个构件或在一些可选的构件中获件不适合该产品，就要建造一个构件或在一些可选的构件中获得一个构件。得一个构件。按着一般的原则，如果存在一些构件或框架，即使这些资源按着一般的原则，如果存在一些构件或框架，即使这些资源正在用于一个产品的开发，那么也应该对它们进行评估。评估正在用于一个产品的开发，那么也应该对它们进行评估。评估过程应在生存周期模型中予以明确地表达。例如，在某些情况过程应在生存周期模型中予以明确地表达。例如，在某些情况下，评估过程可能在很大程度上影响生存周期模型的选择或生下，评估过程可能在很大程度上影响生存周期模型的选择或生成，如选择螺旋模型，而不选择增量模型。成，如选择螺旋模型，而不选择增量模型。使用已存在的构件，除了会引起一个项目生存周期结构上的使用已存在的构件，除了会引起一个项目生存周期结构上的改变，还可能极大地影响个体的技术过程。例如，如果复用的改变，还可能极大地影响个体的技术过程。例如，如果复用的构件表示了该产品的重要部分，那么单元测试工作量的百分比构件表示了该产品的重要部分，那么单元测试工作量的百分比就会相对地减少，但集成该部分的工作量就会增大。同样，由就会相对地减少，但集成该部分的工作量就会增大。同样，由于必须建立或修改子过程，以确保设计与任何可复用的框架或于必须建立或修改子过程，以确保设计与任何可复用的框架或构件是一致的，因此设计过程将是有效的。构件是一致的，因此设计过程将是有效的。 软件开发本质软件开发本质软软件件生生存存周周期期过过程程定义定义软软件件生生存存周周期期模模型型软软件件工工程程生生存存周周期期过过程程支支持持过过程程方方向向(活活动动与与定定序序)的的建建立立形形成成软件开发方法学软件开发方法学结构化方法结构化方法面向对象方法面向对象方法面向数据结构面向数据结构方方法法维也纳开发方维也纳开发方法（法（VDM）给给出出实实现现开开发发过过程程的的途途径径支持支持/管理技术与方法管理技术与方法作用于作用于回答回答: :如何建立一项软件工程的生存周期过程并管理之如何建立一项软件工程的生存周期过程并管理之. .3 3、软件工程生存周期过程管理、软件工程生存周期过程管理 1)1)引言引言 一个项目的一个项目的软件生存周期过程管理软件生存周期过程管理,是该软件工程项目管是该软件工程项目管理的一个子集理的一个子集. 何谓何谓一个项目的软件生存周期过程一个项目的软件生存周期过程? 无无论论是是软软件件项项还还是是硬硬件件项项，在在其其开开发发上上的的演演化化一一般般被被称称 为该项的生存周期。为该项的生存周期。通常，一个项的开发往往始于一个通常，一个项的开发往往始于一个 想法，依其服务情况，不断地进行改进想法，依其服务情况，不断地进行改进。因此。因此, ,项目的项目的 生存周期可概括为生存周期可概括为: :RecognitionofneedAcq.Decision&StrategySpecificationDesignAcceptanceRequirementsMaintenanceReleasetofieldImplementation在一个项目生存周期中，每一个任务在一个项目生存周期中，每一个任务(例如例如Design)都通过都通过一个或多个过程的方式来完成。在生存周期中所有这些相关一个或多个过程的方式来完成。在生存周期中所有这些相关过程的组合，称为项目的软件生存周期过程。过程的组合，称为项目的软件生存周期过程。注注:在这一定义中在这一定义中,关注开发产品所需要的工程技术和管理技关注开发产品所需要的工程技术和管理技术活动术活动,从规约从规约(Specification)一直到验收一直到验收(Acceptance).软件生存周期过程的管理软件生存周期过程的管理管理的一般模型管理的一般模型:所谓软件生存周期过程的管理所谓软件生存周期过程的管理,即从需求规约到验收，对即从需求规约到验收，对 过程、过程、过程之间的关系以及过程之间的关系以及 过程产品流进行定义和过程产品流进行定义和 控制控制. . PADC具体地说，可分为具体地说，可分为4 4个主要阶段：个主要阶段：选选择择合合适适的的软软件件生生存存周周期期模模型型（the the Software Software Life Life Cycle Cycle Model, Model, SLCMSLCM）, ,作作为为发发布布、支支持持产产品品所所需需要要的的一一个个全局过程网，作为完成其中活动所需要的活动网。全局过程网，作为完成其中活动所需要的活动网。通通过过标标识识和和定定义义那那些些单单个个的的任任务务（例例如如需需求求），创创建建软软件生存周期（件生存周期（the Software Life Cycle, SLCthe Software Life Cycle, SLC）。）。 建建 立立 组组 织织 上上 和和 技技 术术 上上 的的 软软 件件 生生 存存 周周 期期 过过 程程 （ the the Software Life Cycle ProcessSoftware Life Cycle Process，SLCPSLCP）。）。 在整个产品的生存周期中，管理该在整个产品的生存周期中，管理该SLCPSLCP。 其中，规划并记录这些活动的关键手段是其中，规划并记录这些活动的关键手段是SLCMSLCM计划计划（或（或SLCMPSLCMP）。）。 创建这一计划的主要指南：创建这一计划的主要指南： IEEE/EIA Standard 12207.0-1996IEEE/EIA Standard 12207.0-1996软件生存周期过程软件生存周期过程IEEE Standard 1074-1997IEEE Standard 1074-1997软件生存周期过程的开发软件生存周期过程的开发 IEEE/EIZ 12207.2-1997IEEE/EIZ 12207.2-1997软件生存周期过程软件生存周期过程- -实现考虑实现考虑。2)软件生存周期模型的选择软件生存周期模型的选择在实际工程中在实际工程中,可供选择的四个主要软件生存周期模型为可供选择的四个主要软件生存周期模型为:（1）瀑布模型，（）瀑布模型，（2）增量模型，）增量模型，（3）演化模型，（）演化模型，（4）螺旋模型。）螺旋模型。(1) 选择步骤选择步骤 在每一模型的优缺点评估完成之后，过程设计师必须为在每一模型的优缺点评估完成之后，过程设计师必须为指定的项目选择最合适的生存周期模型。指定的项目选择最合适的生存周期模型。 ( (注：这是一项重要而复杂的任务注：这是一项重要而复杂的任务.).) IEEE Standard 1074-1997 IEEE Standard 1074-1997列出了选择项目生存周期模型列出了选择项目生存周期模型的步骤的步骤(5(5步步). ). 标识开发项目可用的标识开发项目可用的SLCMsSLCMs。 其中应考虑组织中可用的支持其中应考虑组织中可用的支持SLCMsSLCMs的的管理系统和工具。管理系统和工具。 在所期望的最终系统和开发环境中，标识那些会影响在所期望的最终系统和开发环境中，标识那些会影响SLCMSLCM选选 择的属性。例如，需求是否容易变化和受影响的？工具能够支择的属性。例如，需求是否容易变化和受影响的？工具能够支 持项目需要？是否存在特定的技术风险？该系统是一个被充分持项目需要？是否存在特定的技术风险？该系统是一个被充分 理解的系统，还是一个不可预测的系统？理解的系统，还是一个不可预测的系统？ 标识为选择生存周期模型所需要的任何约束标识为选择生存周期模型所需要的任何约束, ,包括外部的包括外部的 或是内部的。例如，来自客户合同上的需求，或关键开发技能或是内部的。例如，来自客户合同上的需求，或关键开发技能 的缺乏，特别是客户强制的、具有里程碑的程序进度，以及使的缺乏，特别是客户强制的、具有里程碑的程序进度，以及使 一个特定的应用框架或关键构件成为有用的一个策略决策。一个特定的应用框架或关键构件成为有用的一个策略决策。基于以往的经验和组织能力，评估第一步所选择的那几个基于以往的经验和组织能力，评估第一步所选择的那几个 SLCMSLCM。 这一评估开始应基于以上列出的三步的结果，然后检验使用这一评估开始应基于以上列出的三步的结果，然后检验使用 该组织的经验和能力的实际情况。其中，一个组织项目数据该组织的经验和能力的实际情况。其中，一个组织项目数据 库的创建和维护以及规范的政策和规程，对这一评估将发挥库的创建和维护以及规范的政策和规程，对这一评估将发挥 很大的辅助作用。很大的辅助作用。最后，选择最能满足项目属性和约束的最后，选择最能满足项目属性和约束的SLCMSLCM。 注意：每当作出任何一个重要决策时，就应建立相应的文注意：每当作出任何一个重要决策时，就应建立相应的文档，并进行复审。档，并进行复审。(2)(2)评估评估生存周期模型的生存周期模型的准则准则 下面给出评估生存周期模型的一些准则：下面给出评估生存周期模型的一些准则： （1212） 对可能遇到的风险，模型的承受能力；对可能遇到的风险，模型的承受能力； 开发组织访问最终用户的范围；开发组织访问最终用户的范围； 是否很好地定义了已知需求，有多少没有认识的需求；是否很好地定义了已知需求，有多少没有认识的需求； 早期（部分）功能的重要性；早期（部分）功能的重要性； 问题内在的复杂性以及可能作为其候选解的内在复杂性；问题内在的复杂性以及可能作为其候选解的内在复杂性； 预测的需求改变频率和粒度，以及提出需求改变可能的时预测的需求改变频率和粒度，以及提出需求改变可能的时 间；当然，评估这一问题是非常困难的；间；当然，评估这一问题是非常困难的； 应用的成熟程度，涉及需求以及通过讨论，了解该系统的应用的成熟程度，涉及需求以及通过讨论，了解该系统的时间，还有目前市场上正在开发的类似系统的成熟程度，包括时间，还有目前市场上正在开发的类似系统的成熟程度，包括那些与该系统相关的基本系统或与之交互的系统。那些与该系统相关的基本系统或与之交互的系统。 筹集资金的筹集资金的可能性可能性以及优先考虑的投资；以及优先考虑的投资； 进度和预算的灵活性（即在一个给定的周期，是否必须保进度和预算的灵活性（即在一个给定的周期，是否必须保证资金的入证资金的入/ /出？增量的递交时间是否可以修改，以到达最优出？增量的递交时间是否可以修改，以到达最优成本和最小风险？）成本和最小风险？） 在短期和长期内，满足进度和预算的紧迫程度；在短期和长期内，满足进度和预算的紧迫程度；（1111）开发组织规范的软件过程和工具，以及它们适应该模型）开发组织规范的软件过程和工具，以及它们适应该模型要求的程度；要求的程度；（1212）组织的管理能力、系统和模型要求之间的匹配。）组织的管理能力、系统和模型要求之间的匹配。注注:在应用中在应用中,过程设计师应依据项目需求过程设计师应依据项目需求,建立特定的准则，建立特定的准则，而且还应得到工程而且还应得到工程项目项目经理认同。这应作为一个开始经理认同。这应作为一个开始点点. ( (3)3)评估中注意的问题评估中注意的问题 当实施这一评估时，过程设计师必须清楚：当实施这一评估时，过程设计师必须清楚： 其中的任何一个主观的决定，都有可能是错误的。其中的任何一个主观的决定，都有可能是错误的。 这些错误的潜在结果这些错误的潜在结果- -包括立即可呈现的和以后体现的，包括立即可呈现的和以后体现的， 必须被看作是该评估过程的一部分。必须被看作是该评估过程的一部分。 在一些情况下，这些考虑可以改变最终的选择；在其它情在一些情况下，这些考虑可以改变最终的选择；在其它情 况下，这类风险应在风险管理计划中列出。况下，这类风险应在风险管理计划中列出。 选择一个不合适的软件生存周期，可能会造成灾难性的后选择一个不合适的软件生存周期，可能会造成灾难性的后 果。果。 (4) (4)实施参考实施参考 AlexanderAlexander和和Davis Alexander & DavisDavis Alexander & Davis在在19911991年发表了年发表了“软软件过程模型选择的准则件过程模型选择的准则”。文章：。文章： 给出了一个详细的方法，该方法执行给出了一个详细的方法，该方法执行IEEEIEEE过程的五个步骤。过程的五个步骤。 针对项目或应用，他们提出了针对项目或应用，他们提出了2323个特定的准则，描述了适宜个特定的准则，描述了适宜 每一个生存周期模型的项目的轮廓。每一个生存周期模型的项目的轮廓。 在进行生存周期模型选择时，为当前的项目建立一个轮廓，在进行生存周期模型选择时，为当前的项目建立一个轮廓， 然后用该项目的轮廓与准则中给出的项目轮廓相对照，寻然后用该项目的轮廓与准则中给出的项目轮廓相对照，寻 找最匹配的一个轮廓。找最匹配的一个轮廓。 使用中需要注意的问题使用中需要注意的问题 过程设计师对当前的项目必须有清晰的理解，才能建立该项过程设计师对当前的项目必须有清晰的理解，才能建立该项 目的一个轮廓，然后与那些预定义的轮廓相匹配。这一方目的一个轮廓，然后与那些预定义的轮廓相匹配。这一方 法不能机械地产生一个正确的决策，但建立了检验和评估法不能机械地产生一个正确的决策，但建立了检验和评估 软件过程生存周期的一个结构。软件过程生存周期的一个结构。 该方法的一个弱点是，不适于那些还没有建立可用轮廓该方法的一个弱点是，不适于那些还没有建立可用轮廓 文档库的组织。关于建立项目轮廓文档库，那些具有规范文档库的组织。关于建立项目轮廓文档库，那些具有规范 化的政策和规程，并具有大量项目历史的组织，较之其他化的政策和规程，并具有大量项目历史的组织，较之其他 组织就要更加容易一些。组织就要更加容易一些。 3)3)生存周期过程的精化生存周期过程的精化 选择了一个软件生存周期模型之后，下一个任务就是将选择了一个软件生存周期模型之后，下一个任务就是将 相关的生存周期活动映射到该软件生存周期模型。相关的生存周期活动映射到该软件生存周期模型。 -精化精化 IEEE Standard 1074-1997IEEE Standard 1074-1997和和IEEE/EIA Standard 12207IEEE/EIA Standard 12207将活将活 动定义为组成一个过程的元素；把任务定义为一个活动中的动定义为组成一个过程的元素；把任务定义为一个活动中的 最小的工作单元。最小的工作单元。 至于如何确定每一个任务，这是管理的责任，这涉及到成本至于如何确定每一个任务，这是管理的责任，这涉及到成本 和进度评估和管理，即必须考虑项目的完成时间和监控它们和进度评估和管理，即必须考虑项目的完成时间和监控它们 的状态。的状态。 在确定任务的工作中，应注意：在确定任务的工作中，应注意： 一般来说，任务是可分配给项目组成员的、定义良好的工一般来说，任务是可分配给项目组成员的、定义良好的工 作。作。 一些相关的工作通常组合在一起形成活动，通常称之为一些相关的工作通常组合在一起形成活动，通常称之为“工工 作包作包”。 由此可见，创建生存周期过程的任务是，选择一些要实施的由此可见，创建生存周期过程的任务是，选择一些要实施的 任务及其所需要的方法、工具和能力。任务及其所需要的方法、工具和能力。 将活动映射到生存周期模型将活动映射到生存周期模型 步骤：步骤： 把活动与把活动与SLCM需求相比较，并依据所选择的需求相比较，并依据所选择的SLCM 和项目需求，标识不需要的活动；为此和项目需求，标识不需要的活动；为此,可可利用利用 IEEEStandard1074-1997和和IEEE/EIAStandard12207，过程设计师列出所有那些必要的活动。，过程设计师列出所有那些必要的活动。这一步主要是确保已考虑了所有活动，并将合适的活这一步主要是确保已考虑了所有活动，并将合适的活动分配给动分配给SLCSLC中的合适过程。中的合适过程。为每一个活动，标识合适的实例数目为每一个活动，标识合适的实例数目为了合理地规划并实现生存周期模型中所需要的过程，必为了合理地规划并实现生存周期模型中所需要的过程，必要标识其中活动的实施次数，以及它们在整个生存周期产品要标识其中活动的实施次数，以及它们在整个生存周期产品流中所起到的作用。流中所起到的作用。 如果一个活动被许多人多次执行，那么就应该在相关工具如果一个活动被许多人多次执行，那么就应该在相关工具 和培训资料方面给予合适的投资。同样，如果一个被多个其和培训资料方面给予合适的投资。同样，如果一个被多个其 它活动使用或引用，那么就需要把这些活动之间的接口设计它活动使用或引用，那么就需要把这些活动之间的接口设计 为能够支持多重使用。以这一方式，可以把活动分为被引用为能够支持多重使用。以这一方式，可以把活动分为被引用 的活动、单实例活动或多实例活动。的活动、单实例活动或多实例活动。 其中：其中： 一个被引用的实例是由其它多个不同的活动所调用或一个被引用的实例是由其它多个不同的活动所调用或 使用的活动，这些调用可以是并发的。当被引用的活动完成使用的活动，这些调用可以是并发的。当被引用的活动完成 之后，结果返回引用方。被引用的活动类似于规程或例程。之后，结果返回引用方。被引用的活动类似于规程或例程。 例例如如，“开开始始复复审审”、“实实施施配配置置控控制制”以以及及“实实现现模模块块代代码码” 等，都是被引用的活动。等，都是被引用的活动。 多实例被引用的活动多实例被引用的活动 可以被其它多个活动所使用，可以被其它多个活动所使用，例如例如“管理项目管理项目”和和“实现子系统代码实现子系统代码”等。等。 一个单实例活动一个单实例活动 仅在仅在SLCSLC中出现一次，而且只有在它接收到中出现一次，而且只有在它接收到 所有的输入之后，才产生所有必要的输出。例如瀑布模型中所有的输入之后，才产生所有必要的输出。例如瀑布模型中 的的“实施系统测试实施系统测试”。 当然，就系统测试本身来说，可能存在一些子活动，它们可当然，就系统测试本身来说，可能存在一些子活动，它们可 以是多实例的。在一个迭代的生存周期模型中，以是多实例的。在一个迭代的生存周期模型中，“实施测试系实施测试系 统统”本身应是一个被引用的、多实例的活动。本身应是一个被引用的、多实例的活动。 在迭代模型中，必须规定为每一个版本的系统测试结果都要在迭代模型中，必须规定为每一个版本的系统测试结果都要分别地存储在分别地存储在SCMSCM库中不同的地方；而在瀑布模型中，仅存在最库中不同的地方；而在瀑布模型中，仅存在最终系统测试结果的一个版本。了解它们之间的差别是很意义终系统测试结果的一个版本。了解它们之间的差别是很意义的，对的，对SCMSCM库，甚至对库，甚至对SCMSCM工具集的选择都具有重要的含义。工具集的选择都具有重要的含义。 确定活动的时序关系，并检查信息流。确定活动的时序关系，并检查信息流。 在在这这一一步步中中，确确定定所所有有活活动动在在一一个个时时间间线线上上的的“位位置置”，但但它它们们并并不不需需要要实实际际的的日日期期。这这样样，既既确确定定了了活活动动之之间间的的次次序，同时又标识了它们之间的任一依赖。序，同时又标识了它们之间的任一依赖。 例如例如: : 过程初启过程初启 A A 标识候选的软件生存周期模型标识候选的软件生存周期模型 B B 选择项目使用的选择项目使用的软件生存周期软件生存周期模型模型 C C 将活动映射到所选择的将活动映射到所选择的软件生存周期软件生存周期模型模型 概念开发概念开发 A A 分配项目资源分配项目资源 B B 建立项目环境建立项目环境 C C 规划项目管理规划项目管理 D D 软件需求的主次分析和集成软件需求的主次分析和集成 E E 选择或开发算法选择或开发算法 编制软件生存周期管理计划编制软件生存周期管理计划 软件生存周期管理计划（软件生存周期管理计划（the software life cycle the software life cycle management plan, SLCMPmanagement plan, SLCMP）是用于定义和管理软件开发过程）是用于定义和管理软件开发过程的基本机制，其中这些软件开发过程用于实施一个项目所需的基本机制，其中这些软件开发过程用于实施一个项目所需要的开发任务。要的开发任务。IEEE标准没有明确标准没有明确SLCMP的格式，但是，以其它计划作的格式，但是，以其它计划作为模型，可以得到包含以下内容的模板：为模型，可以得到包含以下内容的模板： 软件生存周期管理计划软件生存周期管理计划1.概述概述1.1目的、范围和目标。结合项目过程，描述文档的目的目的、范围和目标。结合项目过程，描述文档的目的和目标。和目标。1.2假设和约束条件。描述任何影响和限制项目过程的假假设和约束条件。描述任何影响和限制项目过程的假设和约束；例如，合同的过程需求。设和约束；例如，合同的过程需求。1.3可交付的类。描述项目正在开发的任何可交付的类和可交付的类。描述项目正在开发的任何可交付的类和类型。目的是促进开发不同类所需的明确的过程或子过程。类型。目的是促进开发不同类所需的明确的过程或子过程。1.4可交付产品之间的进度依赖。描述可交付产品进度之可交付产品之间的进度依赖。描述可交付产品进度之间的逻辑关系，这一关系将影响开发过程（不同可交付的产间的逻辑关系，这一关系将影响开发过程（不同可交付的产品）之间的关系。品）之间的关系。2.参考资料。参考资料。给出为了理解所需要的资料，或那些影响计划内容的资给出为了理解所需要的资料，或那些影响计划内容的资料。料。3.定义。定义。定义文档中使用的特定术语。定义文档中使用的特定术语。4.与其它计划的关系。与其它计划的关系。描述描述SLCMP和其它计划之间的关系，并界定计划之间的和其它计划之间的关系，并界定计划之间的接口，以及通过判断这些计划之间不符的内容，确定使用的接口，以及通过判断这些计划之间不符的内容，确定使用的先后模式。先后模式。5.过程的全局描述。描述整个项目软件开发的途径，包过程的全局描述。描述整个项目软件开发的途径，包括：括：a)项目可交付的产品，包括相关的各个类；项目可交付的产品，包括相关的各个类；b)影响或启动项目软件开发过程的外部数据或过程；影响或启动项目软件开发过程的外部数据或过程；c)识别并描述对任何可以集成到项目中或成为项目一部识别并描述对任何可以集成到项目中或成为项目一部分的内部或外部所开发的软件项；分的内部或外部所开发的软件项；d)标识为限定发布这些软件项所使用的软件过程；标识为限定发布这些软件项所使用的软件过程；e)一个过程流网络，表示单个过程是如何与项目可交付一个过程流网络，表示单个过程是如何与项目可交付产品的开发相互影响和作用的；产品的开发相互影响和作用的；f)描述每一个过程的输入和输出，充分描述开发过程之描述每一个过程的输入和输出，充分描述开发过程之间的关系；间的关系；g)每一个过程的简要描述，有助于充分理解项目整体的每一个过程的简要描述，有助于充分理解项目整体的软件开发过程。软件开发过程。6.过程描述。详细描述每一个过程，包括过程或过程的输过程描述。详细描述每一个过程，包括过程或过程的输入、输出或其它数据项所遵循的标准。这一描述应包括：入、输出或其它数据项所遵循的标准。这一描述应包括：a)过程的输入；过程的输入；b)过程的输出；过程的输出；c)过程的目标，以及过程的详细描述，包括任意中间产品过程的目标，以及过程的详细描述，包括任意中间产品和子过程；和子过程；d)过程和子过程所需要的度量；过程和子过程所需要的度量；e)实现和维护过程所需的培训和工具；实现和维护过程所需的培训和工具；f)实现和维护过程所需的任意关键的组织资产；实现和维护过程所需的任意关键的组织资产；g)过程面临的风险。过程面临的风险。7.过程管理。描述管理过程所使用的途径，包括：过程管理。描述管理过程所使用的途径，包括：a)如何获得和维护实施过程所需要的、关键的组织资产、工如何获得和维护实施过程所需要的、关键的组织资产、工具和其它设施；具和其它设施；b)实现过程所需要的培训；实现过程所需要的培训；c)如何使用过程度量来管理过程；如何使用过程度量来管理过程；d)监控和响应过程风险的途径；监控和响应过程风险的途径；e)管理单一过程和一组相关过程所使用的特定方法；管理单一过程和一组相关过程所使用的特定方法；f)影响过程流网络的分析，重点关注过程计划的一次失败所影响过程流网络的分析，重点关注过程计划的一次失败所产生的负面影响。产生的负面影响。8.计划维护和管理。描述维护和管理计划所使用的途径，包计划维护和管理。描述维护和管理计划所使用的途径，包括对计划的改变所需要的复审和认可，包括用户的认可。括对计划的改变所需要的复审和认可，包括用户的认可。还应给出标识修订计划要求所使用的准则。还应给出标识修订计划要求所使用的准则。 注意注意: :对于一个项目而言对于一个项目而言, ,一般还存在一些对支持生存周期过程一般还存在一些对支持生存周期过程 具有重要作用的其它计划，例如具有重要作用的其它计划，例如: : 软件工程管理计划软件工程管理计划 （the software engineering management plan, SEMPthe software engineering management plan, SEMP） 软件配置管理计划软件配置管理计划 （the software configuration management plan, SCMPthe software configuration management plan, SCMP） 软件质量保证计划软件质量保证计划 （the software quality assurance plan, SQAPthe software quality assurance plan, SQAP） 软件验证和确认计划软件验证和确认计划 （the software verification and validation plan, the software verification and validation plan, SVVP SVVP） 软件度量计划（软件度量计划（the software metrics plan, SMPthe software metrics plan, SMP） 其中其中, ,一些计划的实质内容可能也包含在另一些计划中，因一些计划的实质内容可能也包含在另一些计划中，因 此，在项目的最早期，所面临的重要决策是：此，在项目的最早期，所面临的重要决策是： 如何分离这些计划所涵盖的主题；如何分离这些计划所涵盖的主题； 如何标识和和管理计划之间接口；如何标识和和管理计划之间接口； 如何如何实现相互重叠最少的目标；实现相互重叠最少的目标； 如何如何保证整体的一致性和内聚。保证整体的一致性和内聚。 例例如如，在在SEMPSEMP中中应应给给出出生生存存周周期期过过程程的的概概述述，并并详详细细说说明明项项目目生生存存周周期期过过程程与与项项目目进进度度的的关关系系。同同样样，SLCMPSLCMP必必须须清清晰晰地地描描述述如如何何使使用用配配置置管管理理系系统统，如如何何支支持持特特定定处处的的开开发发过过程程，但但没没有有重重复复SCMPSCMP的的内内容容。相相反反，使使用用SLCMPSLCMP所所描描述述的的过过程程，SCMPSCMP必必须须标标识识配置控制面板，而没有重复那个文档中的有关信息。配置控制面板，而没有重复那个文档中的有关信息。 在在项项目目工工作作程程序序的的早早期期阶阶段段，分分配配这这些些计计划划所所包包含含的的范范围围是是一一个个重重要要的的决决策策。要要基基于于项项目目目目标标的的要要求求和和合合同同上上的的需需求求，谨谨慎慎地地做出这一决策。做出这一决策。 4)项目软件生存周期过程的实现项目软件生存周期过程的实现 将将合合适适的的活活动映映射射带所所选择的的软件件生生存存周周期期模模型型之之后后，就就完完成成了了一一个个完完整整生生存存周周期期的的精精化化. .下下一一个个任任务是是将将组织的的过程程资产应用用到到将将精精化化的的生生存存周周期期中中,其其结果果就就是是项目目的的软件件生生存存周期周期过程的程的实现. .组织的的过程资产一般包括：过程资产一般包括： 政策；政策； 标准；标准； 规程；规程； 已有的已有的SCLPs； 度量；度量； 工具；工具； 方法学方法学 在建立满足项目特定需求的最终过程中，可以恰当地使用在建立满足项目特定需求的最终过程中，可以恰当地使用之之, ,把它们作为生存周期过程中的成分。把它们作为生存周期过程中的成分。 同同时时，也也应应该该看看到到，如如果果把把一一些些不不适适合合的的能能力力和和资资产产引引入入到一个项目中，可能会为项目带来一系列的问题。到一个项目中，可能会为项目带来一系列的问题。如何认识过程资产如何认识过程资产?-在组织和过程的成熟度模型框架中，例如在组织和过程的成熟度模型框架中，例如CMM，它们，它们通常被称为已制度化的过程。通常被称为已制度化的过程。 -这些已制度化的组织资产，提供了该组织客观拥有的这些已制度化的组织资产，提供了该组织客观拥有的 能力，能力，直接关系到项目生存周期过程的建立和执行直接关系到项目生存周期过程的建立和执行,从而从而可以极大地减少实现生存周期和过程的风险。可以极大地减少实现生存周期和过程的风险。5) 5) 软件生存周期过程的监控软件生存周期过程的监控 (1)(1)软件生存周期过程的软件生存周期过程的监查监查 在项目实施中在项目实施中, ,必须必须监查监查软件生存周期过程软件生存周期过程的执行情况，以的执行情况，以 确保软件开发是按规划、高效进行的。确保软件开发是按规划、高效进行的。 以下各任务中形成的数据，有助于过程的以下各任务中形成的数据，有助于过程的监查监查： 进展与进度的跟踪。进展与进度的跟踪。这一跟踪可以揭示过程的偏离、不期望这一跟踪可以揭示过程的偏离、不期望 的过程范围增大、工具或资源等问题。的过程范围增大、工具或资源等问题。 质量数据趋势的检查。质量数据趋势的检查。这一检查可以用于确定软件实现组是这一检查可以用于确定软件实现组是 否遵循期望的生存周期过程。否遵循期望的生存周期过程。 设计、编码和测试计划复审记录和动作的检查。设计、编码和测试计划复审记录和动作的检查。这一检查这一检查 可以用于确定过程是否产生预期结果。即给出正在实施的过可以用于确定过程是否产生预期结果。即给出正在实施的过 程是否有效？程是否有效？ 变更要求和测试异常报告趋势的检查。变更要求和测试异常报告趋势的检查。这些检查提供了过这些检查提供了过 程有效程度的深入了解，也能确定配置管理系统的负载是否程有效程度的深入了解，也能确定配置管理系统的负载是否 在可支持的范围内。在可支持的范围内。 关键资源的有效使用。关键资源的有效使用。有时，这可以检测出计划中存在的有时，这可以检测出计划中存在的 隐性偏离。隐性偏离。 与项目组成员的交谈。与项目组成员的交谈。与项目组成员进行正式或者非正式与项目组成员进行正式或者非正式 的对话，了解过程的运作情况。他们的观点，一旦由描述的的对话，了解过程的运作情况。他们的观点，一旦由描述的 客观数据所支持，那么对发现过程问题、寻找过程改善的机客观数据所支持，那么对发现过程问题、寻找过程改善的机 会是非常有价值的。会是非常有价值的。 而而且且, ,还还必必须须定定期期监监控控以以上上信信息息源源. .由由于于生生存存周周期期的的监监控控必必然然带来额外的进度评估，因此应按基本的周期对进度进行修正。带来额外的进度评估，因此应按基本的周期对进度进行修正。 一一个个一一般般的的原原则则是是，在在一一个个特特定定的的生生存存周周期期过过程程中中，每每当当进进展展到到其其进进度度的的10%10%或或者者2020，就就应应该该进进行行一一次次检检查查。例例如如，对对一一个个中中等等规规模模的的产产品品来来说说，设设计计过过程程进进行行到到2020、4040和和6060时时，都都要要对对已已完完成成的的工工作作进进行行检检查查。原原因因是是如如果果完完成成的的工工作作少少于于2020，不不可可能能产产生生足足够够的的有有效效数数据据，但但是是如如果果超超过过了了6060，一一旦旦发发现现问问题题，改改变变设设计计过过程程已已经经太太晚晚了了，以以至至于于会会产产生生灾灾难难性错误。性错误。 利利用用以以上上信信息息，软软件件程程序序管管理理者者和和过过程程设设计计师师应应能能确确定定是是否需要改变生存周期和所要求的过程。否需要改变生存周期和所要求的过程。 作作出出这这一一决决定定必必须须非非常常谨谨慎慎，因因为为对对生生命命周周期期过过程程的的一一个个不不合合适适的的改改变变，可可能能会会打打乱乱整整个个工工作作程程序序，影影响响技技术术工工作作和和人员情绪。人员情绪。 另另一一方方面面，实实现现一一个个合合理理的的改改变变，只只有有当当项项目目组组成成员员都都认认识到这一需要，才能最终有助于开发工作。识到这一需要，才能最终有助于开发工作。 (2) (2) 生存周期生存周期过程改程改变所所产生影响的生影响的评估估 一一旦旦监控控活活动的的过程程发现一一个个生生存存周周期期过程程并并没没有有按按预期期实施施，那那么么软件件程程序序管管理理人人员和和过程程设计师就就要要对可可能能采采取取的的措措施施进行行评估，估，这些措施包括：些措施包括： 什么也不做。什么也不做。 当改当改变的的负面影响可能超面影响可能超过带来的好来的好处时。 强化过程。强化过程。 如果只因初始培训不充分或组织制度不够严格，导致过程没如果只因初始培训不充分或组织制度不够严格，导致过程没 有按预期实施，那么这是一个正确的举措。有按预期实施，那么这是一个正确的举措。 调整过程。调整过程。 如果过程需要进行少量调整（如，核对表的修订或同级复如果过程需要进行少量调整（如，核对表的修订或同级复 审过程的调整），就可以修改过程，并调整员工的培训。审过程的调整），就可以修改过程，并调整员工的培训。 过程替换。过程替换。 如果一个过程根本就存在缺陷（如，只集成了系统的如果一个过程根本就存在缺陷（如，只集成了系统的10 10 ， 但用于监控性能的工具集却消耗了但用于监控性能的工具集却消耗了9090的处理资源），那么的处理资源），那么 必须替换这一过程。必须替换这一过程。 以上措施的某一组合。以上措施的某一组合。 按以下几方面，评估以上进行的过程改变所造成的影响。按以下几方面，评估以上进行的过程改变所造成的影响。 所要求的所要求的“返工返工” 在在有有的的情情况况下下，一一个个改改变变只只影影响响当当前前进进行行的的过过程程步步。而而很很多多时时候候，可可能能需需要要重重新新实实施施该该过过程程前前面面一一些些阶阶段段的的工工作作。无无论论是是哪一种情况，都要考虑一个过程改变对进度和成本的影响。哪一种情况，都要考虑一个过程改变对进度和成本的影响。 资源需求资源需求 进进行行过过程程改改变变可可能能会会增增加加或或者者减减少少资资源源的的需需求求，包包括括人人员员、硬硬件件和和工工具具。必必须须考考虑虑由由生生存存周周期期过过程程的的改改变变所所产产生生的的全全部部成成本，以及为获得这些资源所需要的时间。本，以及为获得这些资源所需要的时间。 实施时间实施时间 如如果果一一个个项项目目采采用用演演化化或或螺螺旋旋生生存存周周期期模模型型，并并在在前前面面一一个个迭迭代代周周期期中中已已标标识识了了过过程程改改变变的的要要求求，那那么么最最好好把把这这一一改改变变推推迟迟到下一个迭代周期。这样就可以用有序的方式进行这一改变。到下一个迭代周期。这样就可以用有序的方式进行这一改变。 对项目和用户的益处。对项目和用户的益处。 建建立立并并实实施施生生存存周周期期过过程程的的理理由由，是是为为了了向向用用户户交交付付一一个个产产品品，这这是是占占主主导导的的一一个个考考虑虑，因因此此对对那那些些与与项项目目和和用用户户益益处处相相关关的的因因素，都要进行评估。素，都要进行评估。 员工情绪员工情绪 进进行行一一个个过过程程改改变变，特特别别是是进进行行一一个个重重要要的的改改变变，可可能能会会对对员员工工的的情情绪绪产产生生负负面面影影响响。当当这这一一改改变变涉涉及及到到组组织织里里那那些些有有威威信信的的人人，包包括括员员工工、管管理理人人员员和和专专家家，其其影影响响尤尤其其严严重重。虽虽然然这这些些顾顾虑虑不不应应该该停停止止项项目目管管理理人人员员和和结结构构设设计计师师进进行行正正确确的的改改变变，但但是是需需要要认认真真地地考考虑虑实实现现这这一一改改变变的的时时间间。如如果果向向项项目目人人员员（他他们们可可能能是是首首先先发发现现问问题题的的员员工工）进进行行了了正正确确、合合适适的的说说明明，那那么么才才能真正地实现这一改变。能真正地实现这一改变。(3)改变的实施改变的实施 对对项项目目进进展展中中的的一一个个过过程程进进行行一一个个改改变变，必必须须十十分分谨谨慎慎。依依据进行改变的时刻，要求实施以下全部或一部分工作：据进行改变的时刻，要求实施以下全部或一部分工作： 围绕一个初期的主要问题，与客户进行讨论；围绕一个初期的主要问题，与客户进行讨论； 向项目有关成员宣布改变的需求。向项目有关成员宣布改变的需求。 这这是是一一件件相相当当关关键键的的事事情情，必必须须是是客客观观的的、理理性性的的。受受到到一一些些抱抱怨怨不不是是什什么么问问题题，关关键键的的是是以以最最低低成成本本建建造造一一个个最最好好的的产产品。品。 规划改变。规划改变。 规规划划改改变变的的工工作作包包括括：确确定定过过程程改改变变的的时时间间、需需要要的的资资源源和和培培训训：可可能能需需要要返返工工的的项项；对对软软件件规规划划文文档档的的任任何何改改变变，（过过程程、进进度度）；涉涉及及到到的的合合同同或或业业务务需需求求（必必须须与与客客户户协协商商）；标标识识并并冻冻结结所所涉涉及及的的配配置置项项；规规划划必必要要返返工工；标标识识不不需需要要改改变变的、可以继续工作的范围。的、可以继续工作的范围。 这这一一改改变变的的进进度度必必须须包包括括获获得得和和实实现现所所需需要要的的资资源源和和培培训训的的时时间间和和活活动动。对对一一个个增增加加的的成成分分或或改改变变的的成成分分，. .必必须须确确定定要要做做哪个（以上描述的）监督活动的过程。哪个（以上描述的）监督活动的过程。 实现改变。实现改变。 执行这一改变计划，继续关注并保持与项目成员的交流。执行这一改变计划，继续关注并保持与项目成员的交流。软件过程小结：软件过程小结： 1 1）软件开发过程中的活动分为三类）软件开发过程中的活动分为三类, ,基本过程基本过程, ,支持过程和组支持过程和组 织过程织过程, ,支持过程和组织过程作用于基本过程支持过程和组织过程作用于基本过程, ,以保障开发以保障开发 活动的有效实施活动的有效实施. . 问题空间问题空间 涉及过程方向和过涉及过程方向和过程途径程途径 是管理的一类对象是管理的一类对象开发的管理开发的管理2 2）所有软件生存周期模型的基本内在特征为）所有软件生存周期模型的基本内在特征为: : 描述了开发的主要阶段；描述了开发的主要阶段； 定义了每一个阶段要完成的主要活动；定义了每一个阶段要完成的主要活动； 规约了每一个活动的输入和输出（产品）；规约了每一个活动的输入和输出（产品）； 因此可以说因此可以说, ,软件生存周期模型软件生存周期模型提供了一个提供了一个求解软件的求解软件的逻辑逻辑 框架，可以把必要的活动映射到该框架中。框架，可以把必要的活动映射到该框架中。 3 3）软件开发诸过程中的活动及其定序，确定了软件工程的基）软件开发诸过程中的活动及其定序，确定了软件工程的基 本过程方向，是本过程方向，是创建软件项目产品的创建软件项目产品的“机制机制”,是是求解软件求解软件的的逻辑逻辑。三、软件需求及系统三、软件需求及系统/ /产品产品( (需求需求) )规约规约 -定义问题的基本要素是什么定义问题的基本要素是什么? ? - -定义问题的基本格式是什么定义问题的基本格式是什么? ? 不论是自顶向上的软件开发不论是自顶向上的软件开发, ,还是自底向上的还是自底向上的软件开发软件开发, ,正确定义问题正确定义问题, ,是解决问题的前提是解决问题的前提. .1定义问题的基本要素定义问题的基本要素定义问题的基本要素是定义问题的基本要素是”需求需求”1)何谓需求何谓需求?一个需求是一个有关一个需求是一个有关“要予构造要予构造”的陈述，用以描述的陈述，用以描述待开发产品（或项）功能上的能力、性能参数或者其它待开发产品（或项）功能上的能力、性能参数或者其它性质。性质。Arequirementisastatementthathasbeenconstructedtodescribeanecessaryfunctionalcapability,performanceparameter,orotherpropertyoftheintendedproduct(oritem). 例如：例如：系统必须有能力支持系统必须有能力支持100个以上的并发用户，每个用户可个以上的并发用户，每个用户可以处理附录以处理附录A中操作任务的任选组合，平均响应时间应该中操作任务的任选组合，平均响应时间应该小于小于1秒，最大响应时间应小于秒，最大响应时间应小于5秒。秒。其中其中:功能功能-可以处理附录可以处理附录A中操作任务的任选组合中操作任务的任选组合性能性能-有能力支持有能力支持100个以上的并发用户个以上的并发用户平均响应时间应小于平均响应时间应小于1秒，最大响应时间应小于秒，最大响应时间应小于5秒。秒。必须在对话窗口的中间显示错误警告，其中使用红色的、必须在对话窗口的中间显示错误警告，其中使用红色的、14点加粗点加粗Arial字体。字体。其中其中:功能功能-能显示错误警告能显示错误警告设计约束设计约束-在对话窗口的中间显示在对话窗口的中间显示,并使用红色的、并使用红色的、14点加点加粗粗Arial字体。字体。 2) 2)什么样的陈述可以作为需求什么样的陈述可以作为需求 -需求的基本性质需求的基本性质 IEEEIEEE标准标准830-1998830-1998要求单一需求必须具有要求单一需求必须具有5 5个基本性质个基本性质: : 必要的必要的(Necessary)。是要求的吗？。是要求的吗？无歧义的无歧义的(Unambiguous)。只能用一种方式解释吗？。只能用一种方式解释吗？ 可测试的可测试的(testable)。可以对它进行测试吗？。可以对它进行测试吗？可跟踪的可跟踪的(Traceable)。可以从一个开发阶段到另一。可以从一个开发阶段到另一个阶段对它进行跟踪吗？个阶段对它进行跟踪吗？ 可测量的可测量的(Measurable)。可以对它进行测量吗？。可以对它进行测量吗？注注:确定一个需求是否满足以上五个性质是复杂耗时的确定一个需求是否满足以上五个性质是复杂耗时的 过程过程. .3)需求分类需求分类功能；功能； 性能；性能； 外部接口；外部接口； 设计约束；设计约束； 质量属性。质量属性。 功能需求功能需求 功能需求规约了系统或系统构件必须执行的功能。功能需求规约了系统或系统构件必须执行的功能。 例如：例如： 系统应对所有已销售的应纳税商品计算销售税。系统应对所有已销售的应纳税商品计算销售税。 系统应提供一种方法，使系统用户可根据本地利率调整销售税比例系统应提供一种方法，使系统用户可根据本地利率调整销售税比例. . 系统应能够产生月销售报表。系统应能够产生月销售报表。 除了对要执行的功能给出一个陈述外，还应规约如下内容：除了对要执行的功能给出一个陈述外，还应规约如下内容： 关于该功能输入的所有假定，或为了验证该功能输入，关于该功能输入的所有假定，或为了验证该功能输入， 有关检测的假定。有关检测的假定。 功能内的任一次序，这一次序是与外部有关的。功能内的任一次序，这一次序是与外部有关的。 对异常条件的响应，包括所有内外部所产生的错误。对异常条件的响应，包括所有内外部所产生的错误。 需求的时序或优先程度。需求的时序或优先程度。 功能之间的互斥规则。功能之间的互斥规则。 系统内部状态的假定。系统内部状态的假定。 为了该功能的执行，所需要的输入和输出次序。为了该功能的执行，所需要的输入和输出次序。 用于转换或内部计算所需要的公式。用于转换或内部计算所需要的公式。关于功能需求应考虑以下问题：关于功能需求应考虑以下问题： （1 1）功能源。）功能源。 （2 2）功能共享的数据。）功能共享的数据。 （3 3）功能与外部界面的交互。）功能与外部界面的交互。 （4 4）功能所使用的计算资源。）功能所使用的计算资源。可见可见, ,功能需求是整个需求的主体，几乎构成了由功能需求是整个需求的主体，几乎构成了由 交谈和小组讨论所得到的所有初始需求。这意味着交谈和小组讨论所得到的所有初始需求。这意味着: : 没有功能需求没有功能需求, ,就谈不上其它需求就谈不上其它需求, ,即即性能需求性能需求、外部接外部接 口需求口需求、设计约束和质量属性。设计约束和质量属性。 性能需求性能需求 性能需求性能需求(Performance requirement)(Performance requirement)规约了一个系统或规约了一个系统或系统构件必须具有的性能特性。例如：系统构件必须具有的性能特性。例如： 系统应该在系统应该在5 5分钟内计算出给定季度的总销售税。分钟内计算出给定季度的总销售税。 系统应该在系统应该在1 1分钟内从分钟内从100000100000条记录中检索出一个销售定单。条记录中检索出一个销售定单。 该应用必须支持该应用必须支持100100个个Windows 95/NTWindows 95/NT工作站的并行访问。工作站的并行访问。 注注1 1：性能需求隐含了一些满足功能需求的设计方案，经常：性能需求隐含了一些满足功能需求的设计方案，经常 对设计产生一些关键的影响。例如：排序，关于花费对设计产生一些关键的影响。例如：排序，关于花费 时间的规约将确定哪种算法是可行的。时间的规约将确定哪种算法是可行的。 注注2: 2: 性能需求对功能需求而言性能需求对功能需求而言, ,可以是一对多的可以是一对多的, ,例如例如: : 性能性能x功能功能功能功能功能功能 外部接口需求外部接口需求 外部接口需求外部接口需求(External interface requirement)(External interface requirement)规约了规约了系统或系统构件必须与之交互的硬件、软件或数据库元素。它系统或系统构件必须与之交互的硬件、软件或数据库元素。它也可能规约其格式、时间或其他因素。也可能规约其格式、时间或其他因素。例如：例如： 账户接收系统必须为月财务状况系统提供更新信息，如在账户接收系统必须为月财务状况系统提供更新信息，如在“财务系统描述财务系统描述”第第4 4修订版中所描述的。修订版中所描述的。 引擎控制系统必须正确处理从飞行控制系统接收来的命令，引擎控制系统必须正确处理从飞行控制系统接收来的命令，符合接口控制文档符合接口控制文档B2-10A4B2-10A4，修订版，修订版C C的的1 1到到8 8段的规定。段的规定。 -用用户户接接口口(User (User interfaces)interfaces)：规规约约了了软软件件产产品品和和用用户户之之间间接接口口的的逻逻辑辑特特性性。即即规规约约 对对给给用用户户所所显显示示的的数数据据，对对用用户户所要求的数据以及用户如何控制该用户接口。所要求的数据以及用户如何控制该用户接口。 -硬硬件件接接口口(Hardware (Hardware interfaces)interfaces)：如如果果软软件件系系统统必必须须与与硬件设备进行交互，那么就应说明所要求的支持和协议类型。硬件设备进行交互，那么就应说明所要求的支持和协议类型。-软件接口软件接口(Softwareinterfaces)：允许与其它软件产品进行：允许与其它软件产品进行交互，如，数据管理系统、操作系统或数学软件包。交互，如，数据管理系统、操作系统或数学软件包。 -通讯接口通讯接口(Communicationsinterfaces)：规约待开发系统与：规约待开发系统与通讯设施通讯设施(如，局域网如，局域网)之间的交互。如果通讯需求包含了系统之间的交互。如果通讯需求包含了系统必须使用的网络类型（必须使用的网络类型（TCP/IP，WindowsNT,Novell），那么），那么有关类型的信息就应包含在有关类型的信息就应包含在SRS中。中。 -内内存存约约束束(Memory (Memory constraints)constraints)：描描述述易易失失性性存存储储和和永永久久性性存存储储的的特特性性和和限限制制，特特别别应应描描述述它它们们是是否否被被用用于于与与一一个个系系统统中其它处理的通讯。中其它处理的通讯。 -操操作作(Operation)(Operation)：规规约约用用户户如如何何使使系系统统进进入入正正常常和和异异常常的的运运行行以以及及在在系系统统正正常常和和异异常常运运行行下下如如何何与与系系统统进进行行交交互互。应应该该描描述述在在用用户户组组织织中中的的操操作作模模式式，包包括括交交互互模模式式和和非非交交互互模模式式；描描述述每每一一模模式式的的数数据据处处理理支支持持功功能能；描描述述有有关关系系统统备备份份、恢恢复复和升级功能方面的需求。和升级功能方面的需求。 -地地点点需需求求(Site (Site adaptation adaptation requirements)requirements)：描描述述系系统统安安装以及如何调整一个地点，以适应新的系统。装以及如何调整一个地点，以适应新的系统。设计约束设计约束 设设计计约约束束限限制制了了系系统统或或系系统统构构件件的的设设计计方方案案。就就约约束束的的本本身身而而言言，对对其其进进行行权权衡衡或或调调整整是是相相当当困困难难的的，甚甚至至是是不不可可能能的的。它它们们必必须须予予以以满满足足。这这一一性性质质，是是与与其其它它需需求求的的最最主主要要差差别别。为为了了满满足足功功能能、性性能能和和其其它它需需求求，许许多多设设计计约约束束将将对对软软件件项项目目规划、所需要的附加成本和工作产生直接影响。例如：规划、所需要的附加成本和工作产生直接影响。例如： 系统必须用系统必须用C+C+或其他面向对象语言编写。或其他面向对象语言编写。 系统用户接口需要菜单。系统用户接口需要菜单。 任取任取1010秒，一个特定应用所消耗的可用计算能力平均不超过秒，一个特定应用所消耗的可用计算能力平均不超过50%50%。必须在对话窗口的中间显示错误警告，其中使用红色的、必须在对话窗口的中间显示错误警告，其中使用红色的、14点加粗点加粗Arial字体。字体。 针对产品开发，为确定其相关的设计约束，一般需要考虑以下针对产品开发，为确定其相关的设计约束，一般需要考虑以下1010个方面：个方面： -法规政策法规政策(Regulatory policies)(Regulatory policies)； -硬件限制硬件限制(Hardware limitations)(Hardware limitations)，例如：处理速度、信号，例如：处理速度、信号定序需求、存储容量、通讯速度以及可用性等；定序需求、存储容量、通讯速度以及可用性等； -与其它应用接口与其它应用接口(Interfaces to other applications)(Interfaces to other applications)，如，如，当外部系统处于一个特定状态时，禁止新系统某些操作当外部系统处于一个特定状态时，禁止新系统某些操作 -并发操作并发操作(Parallel operations)(Parallel operations)，例如，可能要求从，例如，可能要求从/ /自一自一些不同的源，并发地产生或接收数据。对此，必须清晰地给出有些不同的源，并发地产生或接收数据。对此，必须清晰地给出有关时间的描述。关时间的描述。 -审计功能审计功能(Audit functions)(Audit functions)，规约软件系统必须满足的数，规约软件系统必须满足的数据记录准则或事务记录准则。如，如果用户察看或修改数据，据记录准则或事务记录准则。如，如果用户察看或修改数据，那么就可能要求该系统为了以后复审，记录该系统的动作。那么就可能要求该系统为了以后复审，记录该系统的动作。-控制功能控制功能(Control functions)(Control functions)：可以对系统的管理能力进：可以对系统的管理能力进行远程控制、可以对其他外部软件以及内部过程进行控制。行远程控制、可以对其他外部软件以及内部过程进行控制。 -高级语言需求高级语言需求(Higher order language requirements)(Higher order language requirements)： -握手协议握手协议(Signal handshake protocols)(Signal handshake protocols)：通常用于硬件：通常用于硬件和通讯控制软件，特别当给出特定的时间约束时，一般就要把和通讯控制软件，特别当给出特定的时间约束时，一般就要把“握手协议握手协议”作为一项约束。作为一项约束。 -应用的关键程度应用的关键程度(Criticality of the application)(Criticality of the application)，许，许多生物医学、航空、军事或财务软件属于这一类。多生物医学、航空、军事或财务软件属于这一类。 -安全考虑安全考虑(Safety and security considerations)(Safety and security considerations)。 质量属性质量属性 质量属性质量属性(Quality attribute)(Quality attribute)规约了软件产品必须具有规约了软件产品必须具有的一个性质是否达到质量方面一个所期望的水平。例如：的一个性质是否达到质量方面一个所期望的水平。例如： 属性属性 描述描述 可靠性可靠性 软件系统在指定环境中没有失败而正常运行的概率软件系统在指定环境中没有失败而正常运行的概率。 存活性存活性 当系统的某一部分系统不能运行时，该软件继续运行或支当系统的某一部分系统不能运行时，该软件继续运行或支 持关键功能的可能性。持关键功能的可能性。 可维护性可维护性 发现和改正一个软件故障或对特定的范围进行修改发现和改正一个软件故障或对特定的范围进行修改 所要求的平均工作。所要求的平均工作。 用户友好性用户友好性 学习和使用一个软件系统的容易程度。学习和使用一个软件系统的容易程度。 安全性安全性 在一个预定的时间内，使软件系统安全的可能性。在一个预定的时间内，使软件系统安全的可能性。 可移植性可移植性 软件系统运行的平台类型。软件系统运行的平台类型。2定义需求的基本格式定义需求的基本格式-需求规约（）需求规约（）1)概念概念一一个个需需求求规规约约是是一一个个软软件件项项/产产品品/系系统统所所有有需需求求陈陈述述的的正正式文档式文档,是一个软件产品系统的概念模型是一个软件产品系统的概念模型。Arequirementspecificationistheformaldocumentationallrequirementstatementsforanitem/product/system.2)基本性质基本性质IEEE标准还规定标准还规定SRS必须具有以下必须具有以下4个性质：个性质：重要性和稳定性程度重要性和稳定性程度(Ranked for importance and stability)(Ranked for importance and stability)。 可可修修改改的的(Modifiable)(Modifiable)。在在不不过过多多地地影影响响其其它它需需求求的前提下，可以容易地修改一个单一需求的前提下，可以容易地修改一个单一需求. . 完整的完整的(Complete)(Complete)。没有被遗漏的需求。没有被遗漏的需求. . 一致的一致的(Consistent)(Consistent)。不存在互斥的需求。不存在互斥的需求. .注注：大大型型复复杂杂项项目目和和一一些些有有能能力力的的组组织织，在在开开发发需需求求文文档档时时，往往往往使使用用系系统统化化的的需需求求分分析析技技术术和和工工具具。其其中中一一些些方方法法提提供供了了系系统统化化、自自动动化化的的功功能能，逐逐一一验验证证单单一一需需求求所所具具有有的的五五个个性性质质，并并进进一一步步验验证证需需求求规规约约是是否否具具有以上四个性质。有以上四个性质。系统需求规格说明书系统需求规格说明书1引言引言11编写目的编写目的说明编写本需求分析规格说明书的目的。说明编写本需求分析规格说明书的目的。12背景说明背景说明(1)给出待开发的软件产品的名称；给出待开发的软件产品的名称；(2)说明本项目的提出者、开发者及用户；说明本项目的提出者、开发者及用户；(3)说明该软件产品将做什么，如必要，说明不做什么。说明该软件产品将做什么，如必要，说明不做什么。13术语定义术语定义列出本文档中所用的专门术语的定义和外文首字母组词的列出本文档中所用的专门术语的定义和外文首字母组词的原词组。原词组。14参考资料参考资料列出本文档中所引用的全部资料，包括标题、文档编号、列出本文档中所引用的全部资料，包括标题、文档编号、版本号、出版日期及出版单位等，必要时注明资料来源。版本号、出版日期及出版单位等，必要时注明资料来源。3)需求规约格式实例需求规约格式实例2概述概述21功能概述功能概述叙述待开发软件产品将完成的主要功能，并用方框图来叙述待开发软件产品将完成的主要功能，并用方框图来表示各功能及其相互关系。表示各功能及其相互关系。22约束约束叙述对系统设计产生影响的限制条件，并对下一节中所叙述对系统设计产生影响的限制条件，并对下一节中所述的某些特殊需求提供理由，如管理模式、硬件限制、与其述的某些特殊需求提供理由，如管理模式、硬件限制、与其他应用的接口、安全保密的考虑等。他应用的接口、安全保密的考虑等。3数据流图与数据字典数据流图与数据字典31数据流图数据流图311数据流图数据流图l(1)画出该数据流图画出该数据流图(2)加工说明加工说明(a)编号编号(b)加工名加工名(c)输入流输入流(d)输出流输出流(e)加工逻辑加工逻辑(3)数据流说明数据流说明312数据流图数据流图232数据字典数据字典321文件说明文件说明说明文件的成分及组织方式。说明文件的成分及组织方式。322数据项说明数据项说明以表格的形式说明每一数据项，格式如下表所示：以表格的形式说明每一数据项，格式如下表所示：4接口接口41用户接口用户接口说明人机界面的需求，包括：说明人机界面的需求，包括：(1)屏幕格式；屏幕格式；(2)报表或菜单的页面打印格式及内容；报表或菜单的页面打印格式及内容；(3)可用的功能键及鼠标。可用的功能键及鼠标。42硬件接口硬件接口说明该软件产品与硬件之间各接说明该软件产品与硬件之间各接l51的逻辑特点及运行该软的逻辑特点及运行该软件的硬件设备特征。件的硬件设备特征。43软件接口软件接口说明该软件产品与其他软件之间接口，对于每个需要的软说明该软件产品与其他软件之间接口，对于每个需要的软件产品，应提供：件产品，应提供：(1)名称；名称；(2)规格说明；规格说明；(3)版本号。版本号。5性能需求性能需求51精度精度逐项说明对各项输入数据和输出数据达到的精度，包括传逐项说明对各项输入数据和输出数据达到的精度，包括传输中的精度要求。输中的精度要求。52时间特征时间特征定量地说明本软件的时间特征，如响应时间、更新处理时定量地说明本软件的时间特征，如响应时间、更新处理时间、数据传输、转换时间、计算时间等。间、数据传输、转换时间、计算时间等。53灵活性灵活性说明本软件所具有的灵活性，即当用户需求说明本软件所具有的灵活性，即当用户需求(如对操作方式、如对操作方式、运行环境、结果精度、时间特性等的要求运行环境、结果精度、时间特性等的要求)有某些变化时，本软有某些变化时，本软件的适应能力。件的适应能力。6属性属性61可使用性可使用性规定某些需求，如检查点、恢复方法和重启动性，以确保规定某些需求，如检查点、恢复方法和重启动性，以确保软件可使用。软件可使用。6.2保密性保密性规定保护软件的要素。规定保护软件的要素。63可维护性可维护性规定确保软件是可维护的需求，如模块耦合矩阵。规定确保软件是可维护的需求，如模块耦合矩阵。64可移植性可移植性规定用户程序、用户接口的兼容方面的约束。规定用户程序、用户接口的兼容方面的约束。7其他需求其他需求71数据库数据库说明作为产品的一部分来开发的数据库的需求。如：说明作为产品的一部分来开发的数据库的需求。如：(1)使用的频率；使用的频率；(2)访问的能力；访问的能力；(3)数据元素和文件描述；数据元素和文件描述；(4)数据元素、记录和文件关系；数据元素、记录和文件关系；(5)静态和动态组织；静态和动态组织；(6)数据保留要求。数据保留要求。72操作操作列出用户要求的正常及特殊的操作，如：列出用户要求的正常及特殊的操作，如：(1)在用户组织中各种方式的操作；在用户组织中各种方式的操作；(2)后援和恢复操作。后援和恢复操作。73故障及处理故障及处理列出可能发生的软件和硬件故障，并指出这些故障对各项列出可能发生的软件和硬件故障，并指出这些故障对各项性能指标所产生的影响及对故障的处理要求。性能指标所产生的影响及对故障的处理要求。注意注意:以上给出的是一份需求规格说明书的样例，在实际软件工程以上给出的是一份需求规格说明书的样例，在实际软件工程中，每个开发组织可根据相关的标准和从事的开发领域，规定中，每个开发组织可根据相关的标准和从事的开发领域，规定自己组织的软件需求分析规格说明书的格式。自己组织的软件需求分析规格说明书的格式。4)4)表达需求规约表达需求规约( (规格说明书规格说明书) )的三种风格的三种风格 非形式化的规约非形式化的规约 即以一种自然语言来表达需求规约即以一种自然语言来表达需求规约, ,如同使用一种自然语言如同使用一种自然语言 写了一篇文章写了一篇文章. . 其中其中: :可以不局限于那种语言通常所约定的任何符号或特殊可以不局限于那种语言通常所约定的任何符号或特殊 限制限制( (例如文法和词法）例如文法和词法）, ,但要为那些在一个特定语境但要为那些在一个特定语境 中所使用的术语提供语义定义，一般情况下，该语境中所使用的术语提供语义定义，一般情况下，该语境 与通常使用该术语的语境是有区别的。与通常使用该术语的语境是有区别的。 半形式化的规约半形式化的规约 即以半形式化符号体系即以半形式化符号体系( (包括术语表、标准化的表达格包括术语表、标准化的表达格式等式等) )来表达需求规约。因此来表达需求规约。因此, ,半形式化规约的编制应遵循一半形式化规约的编制应遵循一个标准的表示模板个标准的表示模板( (一些约定一些约定)。 其中其中: : - -术语表明确地标识了一些词，可以基于某一种自然语言术语表明确地标识了一些词，可以基于某一种自然语言 -标准化的表达格式标准化的表达格式( (例如例如数据流图、状态转换图、实例如例如数据流图、状态转换图、实 体关系图、数据结构图以及过程结构图等体关系图、数据结构图以及过程结构图等) )标识了一些元标识了一些元 信息信息, ,支持以更清晰的方式系统化地来编制文档支持以更清晰的方式系统化地来编制文档. . - -应用中应用中, ,不论是词还是标准化的表达格式不论是词还是标准化的表达格式, ,在表达上均必在表达上均必 须遵循一些约定须遵循一些约定, ,即应以一种准确和一致方式使用之。即应以一种准确和一致方式使用之。 形式化规约形式化规约 即以一种基于良构数学概念的符号体系来编制需求规约，即以一种基于良构数学概念的符号体系来编制需求规约，一般往往伴有解释性注释的支持。一般往往伴有解释性注释的支持。 其中其中: : - -以数学概念用于定义该符号体系的词法和语义以数学概念用于定义该符号体系的词法和语义; ; - -定义了一组支持逻辑推理的证明规则定义了一组支持逻辑推理的证明规则, ,并支持这一符号体并支持这一符号体 系的定义和引用。系的定义和引用。5)5)需求规约的作用需求规约的作用 其作用可概括为：其作用可概括为： 第一也是最重要的，第一也是最重要的，作为软件开发组织和用户之间一份事实作为软件开发组织和用户之间一份事实上的技术合同书；是上的技术合同书；是产品功能及其环境的体现。产品功能及其环境的体现。 第二，对于项目的其余大多数工作，它是一个管理控制点。第二，对于项目的其余大多数工作，它是一个管理控制点。 第三，对于产品的设计，它是一个正式的、受控的起始点。第三，对于产品的设计，它是一个正式的、受控的起始点。 第四，是创建产品验收测试计划和用户指南的基础第四，是创建产品验收测试计划和用户指南的基础, ,即即基于基于需求分析规规约一般还会产生另外两个文档需求分析规规约一般还会产生另外两个文档初始初始测试计划和用户系统操作描述。测试计划和用户系统操作描述。初始测试计划初始测试计划主要内容主要内容:对未来系统中的哪些功能和性能指标进行测试，以对未来系统中的哪些功能和性能指标进行测试，以及达到何种要求。及达到何种要求。作用作用:指导系统开发早期发现并修改一个错误指导系统开发早期发现并修改一个错误,减少测试代价减少测试代价.注注:在以后阶段的软件开发中，对这个测试计划要不断地修正和完善，并在以后阶段的软件开发中，对这个测试计划要不断地修正和完善，并成为相应阶段文档的一部分。成为相应阶段文档的一部分。注注:大量的统计数字表明，在系统开发早期发现并修改一个错误的代价往大量的统计数字表明，在系统开发早期发现并修改一个错误的代价往往很低，越到系统开发的后期，改正同样错误所花费的代价越高。例往很低，越到系统开发的后期，改正同样错误所花费的代价越高。例如，假设在需求分析阶段检测并改正一个错误的代价为如，假设在需求分析阶段检测并改正一个错误的代价为1个单位，那么个单位，那么到了软件测试阶段检测并改正同样的错误所花费的代价，一般需要到了软件测试阶段检测并改正同样的错误所花费的代价，一般需要10个单位，而到软件发布后的代价就可能高达个单位，而到软件发布后的代价就可能高达100个单位。个单位。用户系统操作描述用户系统操作描述主要内容主要内容:从用户使用系统的角度从用户使用系统的角度,简要描述系统功能和性能简要描述系统功能和性能,使用系统的主要步骤和方法，以及系统用户的责任等。系统，使用系统的主要步骤和方法，以及系统用户的责任等。系统，作用作用:在软件开发的早期，准备一份初步的用户手册可以使在软件开发的早期，准备一份初步的用户手册可以使未来的系统用户能够从使用的角度检查、审核目标系统，从而未来的系统用户能够从使用的角度检查、审核目标系统，从而比较容易判断这个系统是否符合他们的需要。比较容易判断这个系统是否符合他们的需要。为了书写这样的文档，也会迫使系统分析员从用户的为了书写这样的文档，也会迫使系统分析员从用户的角度来考虑软件系统。这样不论是审查还是复审时角度来考虑软件系统。这样不论是审查还是复审时,就更容易发就更容易发现不一致和误解的地方，这对保证软件质量和项目成功是很重现不一致和误解的地方，这对保证软件质量和项目成功是很重要的。要的。注注:相当于一份初步的用户手册。相当于一份初步的用户手册。 SRSSRS所不能实现的作用所不能实现的作用 第一，它不是一个设计文档。它是一个第一，它不是一个设计文档。它是一个“为了为了”设计的文档。设计的文档。 第二，它不是进度或规划文档，不应该包含更适宜包含在第二，它不是进度或规划文档，不应该包含更适宜包含在工作陈述（工作陈述（SOWSOW）、软件项目管理计划）、软件项目管理计划(SPMP)(SPMP)、软件生存周、软件生存周期管理计期管理计 划划(SLCMP)(SLCMP)、软件配置管理计划、软件配置管理计划(SCMP)(SCMP)或软件质或软件质量保证计划量保证计划(SQAP)(SQAP)等文档中的信息。因此，在等文档中的信息。因此，在SRSSRS中不应给中不应给 出出: : 项目成本；项目成本； 交付进度；交付进度； 报告规程；报告规程； 软件开发方法；质量保证规程；配置管理规程；软件开发方法；质量保证规程；配置管理规程； 验证和确认规程；验收规程；安装规程。验证和确认规程；验收规程；安装规程。关于项目的需求及其需求规约关于项目的需求及其需求规约 项目需求是客户和开发者之间有关技术合同项目需求是客户和开发者之间有关技术合同- -产品产品/ /系统需求系统需求的理解，应记录在工作陈述的理解，应记录在工作陈述SOWSOW中或其他某一项目文档中或其他某一项目文档( (例如，例如，项目管理计划项目管理计划) )中。中。 即即 SRSSRS应只关注产品需求应只关注产品需求, ,即即: : 产品产品/ /系统需求系统需求- -“交付给客户的产品是什么交付给客户的产品是什么” SOWSOW应关注项目工作与管理应关注项目工作与管理, ,即即: : 项目需求项目需求- -“开发组要做的是什么开发组要做的是什么”。四四软件开发方法学软件开发方法学 概念概念:软件方法学软件方法学-支持软件开发的原理支持软件开发的原理/原则、过程和规程的体系原则、过程和规程的体系.是以软件方法为研究对象的学科。主要涉及指导软件设是以软件方法为研究对象的学科。主要涉及指导软件设计的原理和原则，以及基于这些原理、原则的方法计的原理和原则，以及基于这些原理、原则的方法和技术。和技术。狭义的软件方法学也指某种特定的软件设计指导原狭义的软件方法学也指某种特定的软件设计指导原则和方法体系。则和方法体系。掌握并能正确运用开发方法掌握并能正确运用开发方法,具有事半功倍的作用具有事半功倍的作用.软件开发软件开发本质本质软软件件生生存存周周期期过过程程定义定义软软件件生生存存周周期期模模型型软软件件工工程程生生存存周周期期过过程程支支持持过过程程方方向向(活活动动与与定定序序)的的建建立立形形成成软件开发方法学软件开发方法学结构化方法结构化方法面向对象方法面向对象方法面向数据结构面向数据结构方法方法维也纳开发方维也纳开发方法（法（VDM）给给出出实实现现开开发发过过程程的的途途径径支持支持/管理技术与方法管理技术与方法作用于作用于(一一)结构化方法结构化方法-一种特定的软件开发方法学一种特定的软件开发方法学1结构化分析方法结构化分析方法1)何谓分析何谓分析分析的三要素分析的三要素:需要使用哪些信息需要使用哪些信息;如何系统化的使用信息如何系统化的使用信息, 估算算法估算算法一般地说一般地说,分析是系统化地使用信息分析是系统化地使用信息,给出一个问题的估算给出一个问题的估算.何谓结构化分析何谓结构化分析就软件需求分析而言就软件需求分析而言,即为即为:系统化地使用问题域术语系统化地使用问题域术语,给给出该问题的模型出该问题的模型,即即:该系统的概念该系统的概念模型或称系统模型或称系统的需求规约的需求规约问题域问题域-客观事物系统客观事物系统形成形成分析分析(映射映射)可见，需求分析作为一种活动，其目标为：可见，需求分析作为一种活动，其目标为：在一个确定的抽象层（即需求层）上为客观事物系统施在一个确定的抽象层（即需求层）上为客观事物系统施加了一个结构加了一个结构,形成待开发软件系统（产品）的概念模型，形成待开发软件系统（产品）的概念模型，即需求规约（即需求规约（规格说明书），作为开发人员和客户间技术规格说明书），作为开发人员和客户间技术契约的基础，并作为而后开发活动的一个基本输入契约的基础，并作为而后开发活动的一个基本输入2)实现软件需求分析的目标对方法学的需求实现软件需求分析的目标对方法学的需求(1) 提供一组术语提供一组术语( (符号符号) )，指导抽象中需要关注的主要方，指导抽象中需要关注的主要方 面面, ,并用于表达分析中所使用的信息并用于表达分析中所使用的信息. . 这些术语形成一个特定的抽象层，即需求层这些术语形成一个特定的抽象层，即需求层. .当然，这当然，这组术语应体现组术语应体现软件设计的某些软件设计的某些“原理原理/原则原则”！ (2) (2) 依据这些术语所形成的依据这些术语所形成的“空间空间”, ,给出表达模型的工具给出表达模型的工具. . (3) (3) 给出过程指导给出过程指导. .3)需求层的确定需求层的确定一个抽象层是由一组确定的术语定义的一个抽象层是由一组确定的术语定义的,为此为了支持需为此为了支持需求分析中有关要使用的那些信息的表达求分析中有关要使用的那些信息的表达,给出了以下五个给出了以下五个术语符号术语符号: 数据流：数据流： 加工：加工： 数据存储：数据存储： 数据源：数据源： 数据潭：数据潭： 其中：其中： 数据流、数据存储数据流、数据存储-支持数据抽支持数据抽象象, ,加工加工-支持过程支持过程/ /功能的抽象，功能的抽象，用于表达用于表达系统内涵系统内涵数据源、数据潭数据源、数据潭支持系统边界支持系统边界抽象，用于表达系统抽象，用于表达系统外延外延. 是完备的。是完备的。4)模型表达工具模型表达工具这些术语形成一个特定的术语空间这些术语形成一个特定的术语空间,即即:它们之间是它们之间是”正交正交”的的.每一个术语所要表达的信息每一个术语所要表达的信息,形成了该术语的形成了该术语的”值域值域”,并且是一个偏序集并且是一个偏序集;例如例如,假定在一个学籍管理系统中假定在一个学籍管理系统中,数据流数据流-“学生各科成学生各科成绩绩”:数学数学85分分,软件工程软件工程90分分,操作系统操作系统86分分,编译编译83分等分等,构成了该数据流的构成了该数据流的“值域值域”. 这些术语确定了所建系统的形态这些术语确定了所建系统的形态.如果是一个三维空间如果是一个三维空间,那些所建系统的形态只能是那些所建系统的形态只能是:或是一条直线或是一条直线;或是一条曲线或是一条曲线;或是一个平面或是一个平面,或是一个曲面或是一个曲面; 或是一个立方体或是一个立方体,或是一个多形体或是一个多形体.现在现在,是由五个术语所确定的一个五维空间是由五个术语所确定的一个五维空间,因此该方法只因此该方法只能采用能采用DFD图来表达各种图来表达各种“形态形态”的系统的系统.例如例如旅行社旅行社订票单订票单预定预定机票机票准备准备机票机票记帐记帐费用费用航班航班帐单帐单机票机票记帐文件记帐文件航班目录航班目录旅行社旅行社5)5)过程指导过程指导 建立系统的功能模型建立系统的功能模型 -使用的工具为数据流图使用的工具为数据流图DFDDFD 首先：建立系统环境图，确定系统边界首先：建立系统环境图，确定系统边界 继之：自顶向下，逐层分解继之：自顶向下，逐层分解建立数据字典建立数据字典 -使用的工具为结构符使用的工具为结构符 定义数据流定义数据流 定义数据存储定义数据存储 定义数据项定义数据项 给出加工小说明给出加工小说明 -使用的工具可以为判定表使用的工具可以为判定表 判定树判定树问题：建立一个简化的商业自动化系统，其中：问题：建立一个简化的商业自动化系统，其中：营业员通过该系统记录每日销售的商品（营业员通过该系统记录每日销售的商品（商品名，商品编号，单价，数量，销售时间）；）；收款员通过该系统记录收到的现金数额以及购物余额；收款员通过该系统记录收到的现金数额以及购物余额；商店经理每日统计销售额，并在必要时查看某种商品的商店经理每日统计销售额，并在必要时查看某种商品的销售情况（商品名，商品编码，金额）销售情况（商品名，商品编码，金额）结构化分析方法应用实例结构化分析方法应用实例简化的商业自动化系统简化的商业自动化系统营业员收款员经理销售的商品销售的商品现金额现金额现金余额现金余额销售情况销售情况日销售额日销售额查询要求查询要求建立系统的功能模型建立系统的功能模型首先：建立系统环境图，确定系统边界首先：建立系统环境图，确定系统边界 -顶层顶层DFDDFD其中：其中：1 1 数据流为：销售的商品，日销售额等数据流为：销售的商品，日销售额等 3 3个输入流，个输入流，3 3个输出流个输出流 数据源为：营业员，经理，收款员数据源为：营业员，经理，收款员 数据潭为：经理，收款员数据潭为：经理，收款员 2 2 加工名为：要建立的系统名字加工名为：要建立的系统名字录入、修改或删除商品信息录入、修改现金额,并计算余额查询商品销售情况计算日销售额123继之：自顶向下，逐层分解继之：自顶向下，逐层分解A A、按人或部门的功能要求，将加工、按人或部门的功能要求，将加工“打碎打碎”，形成：形成：注：需给每一加工编号；注：需给每一加工编号；B B、”分派分派”数据流，形成：数据流，形成：录入、修改或删除商品信息2录入、修改现金额,并计算余额查询商品销售情况计算日销售额销售的商品销售的商品现金额现金额现金余额现金余额查询要求查询要求销售情况销售情况日销售额日销售额13其中：要根据特定的加工要求进行分派；其中：要根据特定的加工要求进行分派； 保持与顶层数据流的一致；保持与顶层数据流的一致； 可以不引入数据源和数据潭。可以不引入数据源和数据潭。录入、修改或删除商品信息录入、修改现金额,并计算余额查询商品销售情况计算日销售额销售的商品销售的商品现金额现金额现金余额现金余额查询要求查询要求销售情况销售情况日销售额日销售额销售文件销售文件123C C、引入文件，使之形成一个有机整体、引入文件，使之形成一个有机整体系统：系统：注：到一个文件，既有输入流，又有输出流，则可简化为注：到一个文件，既有输入流，又有输出流，则可简化为 ，并可不给出标识。，并可不给出标识。至此，体现精化，形成至此，体现精化，形成0 0层数据流图。层数据流图。 查询商品销售情况计算日销售额查询要求查询要求销售情况销售情况日销售额日销售额销售文件销售文件3继续继续A A、B B、C C：自顶向下，逐层分解。：自顶向下，逐层分解。例如：加工例如：加工3 3可分解为：可分解为：判定要求查询要求查询要求3。1统计销售情况3。2计算日销售额销售文件销售文件查询要求查询要求2查询要求查询要求1销售情况销售情况日销售额日销售额加工3:* *其中为什么要引入其中为什么要引入加工加工“判定要求判定要求”？建立数据字典建立数据字典 定义数据流定义数据流 定义数据存储定义数据存储 定义数据项定义数据项 引入：结构符引入：结构符 | | 用于定义数据结构用于定义数据结构 AAABCB0C0B*数据字典数据字典:、数据流、数据流:销售的商品=商品名+商品编号+单价+数量+销售时间现金额=余额=日销售额=非负实数查询要求=商品编号|日期查询要求1=商品编号查询要求2=日期销售情况=商品名+商品编号+金额、数据存贮、数据存贮:销售文件=销售的商品 、数据项 给出加工小说明给出加工小说明 -使用的工具可以为判定表使用的工具可以为判定表 判定树判定树 判断表判断表 条件类别条件类别 条件组合条件组合 操作操作 操作执行操作执行 例如：例如： 考试总分考试总分 =620 =620 =620 =620 ec,d-ee-fe-ff-g,hf-g,hh-yh-yput yput yg-xg-xput xput xx-zx-zput zput zget aget aget bget bb-db-da-ca-ceeg,hhgzzxxgyyhdbcacdeefg,hfxab事务设计事务设计事务中心事务中心输入模块输入模块路径路径1路径路径2输出模块输出模块aycgbfc-ecee-gegb-dbdd-fdf 第二步：如何将初始的第二步：如何将初始的MSDMSD转化为最终可供详转化为最终可供详 细设计使用的细设计使用的MSD MSD 基于模块化原理基于模块化原理- -高内聚高内聚 低耦合低耦合, , 给出一些设计规则经验规则给出一些设计规则经验规则, , 用于精化初始的用于精化初始的MSDMSD 体现设计人员的创造体现设计人员的创造 耦合：不同模块之间相互依赖程度的度量。耦合：不同模块之间相互依赖程度的度量。 耦合类型：耦合类型： 内容耦合：内容耦合： 公共耦合：两个以上的模块共同引用一个全局数据项。公共耦合：两个以上的模块共同引用一个全局数据项。 控制耦合：一个模块向另一模块传递一个控制信号，控制耦合：一个模块向另一模块传递一个控制信号， 接受信号的模块将依据该信号值进行必要的活动。接受信号的模块将依据该信号值进行必要的活动。 标记耦合：两个模块至少有一个通过界面传递的公共标记耦合：两个模块至少有一个通过界面传递的公共 有结构的参数。有结构的参数。 数据耦合：模块间通过参数传递基本类型的数据。数据耦合：模块间通过参数传递基本类型的数据。内聚：一个模块之内各成分之间相互依赖程度的度量。内聚：一个模块之内各成分之间相互依赖程度的度量。 内聚类型：内聚类型： 偶然内聚：一个模块之内各成分之间没有任何关系。偶然内聚：一个模块之内各成分之间没有任何关系。 逻辑内聚：几个逻辑上相关的功能放在同一模块中。逻辑内聚：几个逻辑上相关的功能放在同一模块中。 时间内聚：一个模块完成的功能必须在同一时间内完成，而时间内聚：一个模块完成的功能必须在同一时间内完成，而 这些功能只是因为时间因素关联在一起。这些功能只是因为时间因素关联在一起。 过程内聚：处理成分必须以特定的次序执行。过程内聚：处理成分必须以特定的次序执行。 通信内聚：各成分都操作在同一数据集或生成同一数据集。通信内聚：各成分都操作在同一数据集或生成同一数据集。 顺序内聚：各成分与一个功能相关，且一个成分的输出作为顺序内聚：各成分与一个功能相关，且一个成分的输出作为 另一成分的输入。另一成分的输入。 功能内聚：模块的所有成分对完成单一功能是最基本的，且功能内聚：模块的所有成分对完成单一功能是最基本的，且 该模块对完成这一功能而言是充分必要的。该模块对完成这一功能而言是充分必要的。启发性规则启发性规则- -经验的总结经验的总结（1 1）改进软件结构，提高模块独立性；）改进软件结构，提高模块独立性；（2 2）模块规模适中）模块规模适中- -每页每页6060行语句；行语句；（3 3）深度、宽度、扇入和扇出适中；）深度、宽度、扇入和扇出适中；（4 4）模块的作用域力争在控制域之内；）模块的作用域力争在控制域之内；（5 5）降低模块接口的复杂性；）降低模块接口的复杂性；（6 6）模块功能应该可以预测。）模块功能应该可以预测。应用示例：数字仪表板系统应用示例：数字仪表板系统的精化的精化读旋转信号读旋转信号收集并收集并求平均求平均转换成转换成转转/分分计算计算gph读并读并校核校核确定确定加速加速/减速减速计算里程计算里程计算计算mph和超速值和超速值计算计算燃料消耗燃料消耗产生产生加速加速/减速显示减速显示产生产生里程显示里程显示发出发出铃声铃声产生产生mph显示显示产生产生mpg显示显示旋转信号旋转信号信号信号/秒秒(sps)sps燃烧流燃烧流传感器信号传感器信号燃烧流燃烧流gphspsrpmrpm箭头指示箭头指示上箭头上箭头下箭头下箭头水平线水平线英里英里超速值超速值mphmpgmpg显示显示mph显示显示铃声铃声里程显示里程显示输入部分输入部分GetgphGetrpmGetspsGet燃料流燃料流变换燃料变换燃料流为流为ghpGet燃转信号燃转信号变换燃转信变换燃转信号为燃料流号为燃料流变换变换sps为为rpmGetspsGetsps转换为转换为spsGet转速信号转速信号变换为变换为sps变换为变换为sps、数字仪表板系统输入部分的精化数字仪表板系统输入部分的精化输入部分的初始模块结构图输入部分的初始模块结构图转速信号转速信号转速信号转速信号燃料流燃料流燃料流燃料流燃料流燃料流gphspsspsrpmspsrpmgphspsspsspsspsspsspssps转速信号转速信号转速信号转速信号输入部分输入部分计算计算gph计算计算rpm计算计算sps读燃转信号读燃转信号采集采集sps读转速信号读转速信号使用启发式规则使用启发式规则1 1，并考虑其它规则，并考虑其它规则， 可以将输入部分的模块结构图精化为：可以将输入部分的模块结构图精化为：其中：其中：sps为转速的每秒信号量；为转速的每秒信号量；sps为为sps的平均值；的平均值；sps为为sps的瞬时的瞬时变化值；变化值；rpm为每分钟转速；为每分钟转速；mph为每小时英里数；为每小时英里数；gph为每小时燃烧为每小时燃烧的燃料加仑数；的燃料加仑数；rpm为行进里程。为行进里程。输出部分输出部分PUTmpgPUTmphPUT里程里程PUT加加/减速减速PUT超速量超速量显示显示显示显示显示显示、数字仪表板系统输出部分的精化数字仪表板系统输出部分的精化输出部分的初始模块结构图输出部分的初始模块结构图显示显示对于这一初始的模块结构图，一般情况下应：对于这一初始的模块结构图，一般情况下应： 把把相相同同或或类类似似的的物物理理输输出出合合并并为为一一个个模模块块，以以减减少少模模块块之间的关联。就本例而言：之间的关联。就本例而言：左左边边前前三三个个“显显示示”，基基本本上上属属于于相相似似的的物物理理输输出出，因因此此可可以以把把它它们们合合并并为为一一个个显显示示模模块块。而而将将“PUT PUT mpgmpg”模模块块和和相相关关的的“生生成成显显示示的的模模块块合合并并为为一一个个模模块块；同同样样地地，应应把把“PUT PUT mphmph”模模块块、“PUTPUT里里程程”各各自自与与相相关关的的生生成成显显示示的的模模块合并为一个模块，参见下图。块合并为一个模块，参见下图。 其其它它求求精精的的规规则则，与与输输入入部部分分类类同同。例例如如，可可以以将将“PUT PUT 加加/ /减减速速”模模块块与与其其下下属属的的两两个个模模块块合合并并为为一一个个模模块块，将将“PUT PUT 超超速速量量”模模块块与与其其下下属属的的两两个个模模块块合合并并为为一一个个模模块块 。 输出模块输出模块生成生成mpg显示显示生成生成mph显示显示生成里程生成里程显示显示生成加生成加/减速显示减速显示生成蜂鸣生成蜂鸣显示显示通过以上求精之后通过以上求精之后, ,可得如下可得如下的模块结构图的模块结构图变换模块变换模块计算计算mpg计算计算mph计算里程计算里程计算加计算加/减速减速 、变换部分的精化、变换部分的精化首先，应该了解：对于变换部分的求精，是一首先，应该了解：对于变换部分的求精，是一项具有挑战性的工作。其中主要是根据设计准则，并要通过项具有挑战性的工作。其中主要是根据设计准则，并要通过实践，不断地总结经验，才能设计出合理的模块结构。实践，不断地总结经验，才能设计出合理的模块结构。就给定的数字仪表板系统而言，如果把就给定的数字仪表板系统而言，如果把“确定加确定加/ /减速减速”的模块放在的模块放在“计算速度计算速度mphmph”模块下面，则可以减少模块下面，则可以减少模块之间的关联，提高模块的独立性。模块之间的关联，提高模块的独立性。通过这一求精，可以得到如下的模块结构图：通过这一求精，可以得到如下的模块结构图：通过以上讨论，可以看出：在总体设计中通过以上讨论，可以看出：在总体设计中将一个给定的将一个给定的DFDDFD转换为初始的模块结构图基本转换为初始的模块结构图基本上是一个上是一个 “机械机械”的过程，一般体现不了设计人员的创的过程，一般体现不了设计人员的创造力；造力；优化设计优化设计- -将一个初始的模块结构图转换为最终将一个初始的模块结构图转换为最终的模块结构图，对设计人员将是一种挑战，其结果将的模块结构图，对设计人员将是一种挑战，其结果将直接影响软件系统开发的质量。直接影响软件系统开发的质量。( (） 详细设计层详细设计层 -主要引入了关于三种动作控制结构的术语主要引入了关于三种动作控制结构的术语/ /符号符号三种控制结构三种控制结构:顺序顺序,选择和循环选择和循环这三种结构在表达系统行为方面是完备的这三种结构在表达系统行为方面是完备的第一种表达第一种表达-伪码伪码顺序顺序begins1;s2;snend;选择选择if条件表达式条件表达式thens1elses2;循环循环while条件表达式条件表达式dos;伪码是一种混合语言。外部采用伪码是一种混合语言。外部采用形式语言的控制结构，内部使用形式语言的控制结构，内部使用自然语言。例如自然语言。例如:Begin输入一元二次方程的系数输入一元二次方程的系数a,b,c;ifb 2-4ac othen计算两计算两实根实根else输出无实根；输出无实根；end.第二种表达第二种表达-框图框图s1s2s1s2.sS1S2S3S1S2X 5X5TFFTS1S2S3S4S5S6S8S7S9S10X10&Y3结构化方法总结结构化方法总结一切系统都是由有信息流构成的一切系统都是由有信息流构成的(其中包含一些必要的数据其中包含一些必要的数据变换变换),它们的相互作用、相互影响它们的相互作用、相互影响,构成了大千世界的各式各构成了大千世界的各式各样系统。样系统。）结构化方法的世界观结构化方法的世界观方法学的提出，通常与信息域方法学的提出，通常与信息域研究的主要内容相关：研究的主要内容相关：1 1）信）信 息息 流例如，结构化方法流例如，结构化方法 2 2）信息内容例如，面向对象方法）信息内容例如，面向对象方法 3 3）信息结构例如，）信息结构例如，JACKSONJACKSON方法方法2）基于的基本原理基于的基本原理/ /原则原则 自顶向下功能分解自顶向下功能分解 数据抽象数据抽象 功能功能/ /过程抽象过程抽象 模块化；模块化；结构化方法的抽象层结构化方法的抽象层,包括包括:需求分析层需求分析层设计层设计层实现层实现层问题空间问题空间解空间解空间自自顶顶向向下下3）结构化方法是一种系统化的软件系统建模方法）结构化方法是一种系统化的软件系统建模方法,从测试的从测试的角度看角度看,结构化方法是一种特定的建立验证和确认所需标尺的方结构化方法是一种特定的建立验证和确认所需标尺的方法学法学,包括结构化分析和结构化设计。包括结构化分析和结构化设计。紧紧围绕紧紧围绕“自顶向下自顶向下”“过程抽象过程抽象”“数据抽象数据抽象”和和“模块化模块化”等基本原理等基本原理/原则原则给出了给出了完备的符号完备的符号可操作的过程可操作的过程易理解的表示工具易理解的表示工具并提供了并提供了控制信息组织复杂性的机制，例如控制信息组织复杂性的机制，例如逐层分解，数据打包等逐层分解，数据打包等以支持以支持将问题空间的一个问题映射为解空间的一个解将问题空间的一个问题映射为解空间的一个解4）该方法的组成）该方法的组成捕获的捕获的“过程过程”和和“数据数据”恰恰是客观事物的易变性恰恰是客观事物的易变性质质解的结构没有保持原系统的结构解的结构没有保持原系统的结构从而：造成从而：造成维护，验证上的困难。维护，验证上的困难。AB1B2B3B4C2C3C4C5C1DnDm数据结构数据结构1数据结构数据结构2）问题）问题1、引言、引言1）面向对象方法发展概述）面向对象方法发展概述一句话概括地说：面向对象方法是一种以对象、对象关系等一句话概括地说：面向对象方法是一种以对象、对象关系等来构造软件系统模型的系统化方法。可见来构造软件系统模型的系统化方法。可见,面向对象方法的世界面向对象方法的世界观是观是:一切系统都是由对象构成的一切系统都是由对象构成的,它们的相互作用、相互影响它们的相互作用、相互影响,构成了大千世界的各式各样系统构成了大千世界的各式各样系统.(二二)面向对象方法面向对象方法-一种特定的软件开发方法学一种特定的软件开发方法学其发展主要经历了：其发展主要经历了：（1）支持编程的面向对象语言支持编程的面向对象语言1967：Dahl和和Nygaard在挪威开发了第一个面向对象语言：在挪威开发了第一个面向对象语言：Simula-6720世纪世纪80年代初，年代初，Smallsalk语言得到广泛应用；语言得到广泛应用；随后出现了随后出现了ObjectiveC、C+和和Eiffel等。等。（2）20世纪世纪80年中期以来，面向对象分析和设计方法学得年中期以来，面向对象分析和设计方法学得到了快速发展，相继提出了很多有关的方法学，典型的有：到了快速发展，相继提出了很多有关的方法学，典型的有：1986：G.Booch的的OOD；1990：P.Coad和和E.Yourdon的的OOA，OOD1991：J.Rumbbaugh的的OMT;1994：Embly的的OSA等。等。期间，形成了以下期间，形成了以下2大学派，即：大学派，即： 第一种：以第一种：以“方法（方法（method method ）”驱动的方法学。驱动的方法学。 基本思想：在给出符号体系的基础上，明确规定基本思想：在给出符号体系的基础上，明确规定 进行的进行的“步骤步骤”，并在每一步中给出，并在每一步中给出 “实施策略实施策略”。 代表：代表：P.CoadP.Coad的的“OOAOOA（19901990）”， “ OODOOD（9191）” 优缺点分析：优缺点分析： 优点：容易学习和掌握。优点：容易学习和掌握。 缺点：不够灵活，可能对出现的新问题就没有缺点：不够灵活，可能对出现的新问题就没有 办法处理。办法处理。 第二第二种：以种：以“模型（模型（model model ）”驱动的方法学。驱动的方法学。 基本思想：给出模型化概念，即符号体系以及目标基本思想：给出模型化概念，即符号体系以及目标 模型；而不明确规定实现目标的模型；而不明确规定实现目标的“步骤步骤”， 但给出一些必要的指导。但给出一些必要的指导。 代表：代表：Rumbaugh Rumbaugh 的的“OMTOMT（19911991）”等等 优缺点分析：优缺点分析： 优点：比较灵活；。优点：比较灵活；。 缺点：与缺点：与OOAOOA相比，不易学习和掌握。相比，不易学习和掌握。（3）OMG发布的发布的UML以及以及USDP（统一软件开发过程）（统一软件开发过程） （A A）9595年，年，Grade Booch Grade Booch 、Jim RumbaughJim Rumbaugh在在OOPSAOOPSA会议上会议上 公布了他们的统一方法（公布了他们的统一方法（0.80.8版）；版）； （B B）9696年，年， G.Booch G.Booch 、J.RumbaughJ.Rumbaugh以及以及Ivar Jacobson Ivar Jacobson “三友三友”，将他们的统一建模语言命名为，将他们的统一建模语言命名为UMLUML； （C C）9797年，年，RationalRational公司发布了公司发布了UMLUML文档文档1.01.0版，作为版，作为OMGOMG 的建议方案；的建议方案； （D D）9898年，在合并不同建议的基础上，年，在合并不同建议的基础上，OMGOMG以其结果以其结果1.11.1版作为一个正式的标准。版作为一个正式的标准。 （E E）从此以后，于）从此以后，于19991999年，年，RTFRTF发布了发布了1.31.3版，版， 20002000年年9 9月，发布了月，发布了1.41.4版，版， 20032003年年3 3月，发布了月，发布了2.02.0版。版。受到业界和学术界广泛关注，特别是受到业界和学术界广泛关注，特别是UML以及相应的支持以及相应的支持工具已在软件开发中得到了广泛的应用。工具已在软件开发中得到了广泛的应用。 “在建模语言方面在建模语言方面,UML,UML已成为一种绘制面向对象设计图的已成为一种绘制面向对象设计图的标准工具标准工具, ,并已传播到非面向对象领域并已传播到非面向对象领域. .面向对象以前的主要面向对象以前的主要方法已经消逝方法已经消逝.UML.UML登场了登场了, ,并且稳居宝座并且稳居宝座. .” “统一建模语言统一建模语言UMLUML乃软件设计与需求规约语言乃软件设计与需求规约语言. .论述语言之论述语言之优劣优劣, ,有用户有用户, ,设计设计, ,实现等观点实现等观点. .这些观点既有区别这些观点既有区别, ,又有联系又有联系.UML.UML问世以来问世以来, ,褒贬不一褒贬不一, ,但其应用广泛但其应用广泛, ,成绩显著成绩显著, ,实为具有实为具有代表性之建模语言代表性之建模语言. .” 摘自摘自UNL 序序, ,徐家福译徐家福译 2 UML2 UML 1) UML 1) UML概述概述 UML是一种可视化语言，用于：是一种可视化语言，用于： （1 1）规约规约系统的制品；系统的制品； （2 2）构造构造系统的制品；系统的制品； （3 3）建立建立系统制品的文档。系统制品的文档。 UML应用范围应用范围 UMLUML作为一种一般性的语言：作为一种一般性的语言： （1 1）可用于对象方法和构件方法；）可用于对象方法和构件方法； （2 2）可用于）可用于 所有应用领域所有应用领域 （例如，航空航天、财政、通讯等）（例如，航空航天、财政、通讯等） 不同的实现平台不同的实现平台 （例如，例如，J2EE、.NET等等） 运行平台运行平台（包括包括VB（VC）、中间件、）、中间件、J2EE、.NET、框架等、框架等）应用系统应用系统祢补两者之间的祢补两者之间的“距离距离” - -建立不同抽象层次的术语空建立不同抽象层次的术语空间和模型表示工具间和模型表示工具- -支持多视角地建立系统模型支持多视角地建立系统模型这意味着：这意味着：UMLUML是系统分析和设计的工具是系统分析和设计的工具。即就软件开发方法学而言，即就软件开发方法学而言，UMLUML给出了方法学中不同抽象层次的给出了方法学中不同抽象层次的术语以及表达模型的工具。术语以及表达模型的工具。表达模型的工具表达模型的工具-USECASE图图需求获取层需求获取层表达模型的工具表达模型的工具-类图、交互图等类图、交互图等需求分析层需求分析层表达模型的工具表达模型的工具-类图、交互图等类图、交互图等设计层设计层表达模型的工具表达模型的工具2)2)面向对象方法术语面向对象方法术语/ /符号符号 基于基于面向对象方法的面向对象方法的世界观世界观, ,即即“大千世界是由对象组成的，大千世界是由对象组成的，对象有其自己的属性和运动规律，对象之间的相互作用构成了对象有其自己的属性和运动规律，对象之间的相互作用构成了客观世界各种各样的系统。客观世界各种各样的系统。” 为了支持软件开发为了支持软件开发, ,面向对象方法面向对象方法主要提供了两类术语主要提供了两类术语: : 一类是表达结构化事物的术语；一类是表达结构化事物的术语； 一类是表达关系的术语。一类是表达关系的术语。 注：注：除了这两类术语之外，除了这两类术语之外，为了控制信息组织的复杂性，还引入了用于组织特定对象结构的包。为了控制信息组织的复杂性，还引入了用于组织特定对象结构的包。同样做一类比，一个包相当一个可管理的同样做一类比，一个包相当一个可管理的“预制块预制块”。为了使建造的系统模型容易理解，引入了术语为了使建造的系统模型容易理解，引入了术语-注解，用于对模型增注解，用于对模型增加一些辅助性说明。加一些辅助性说明。(1)(1)、表达结构化事物的术语、表达结构化事物的术语 类与对象类与对象 - -体现数据抽象体现数据抽象定义与表示：定义与表示： Class :A class is a description of a Class :A class is a description of a set of objects that share the same set of objects that share the same attributes, operations, relationships, attributes, operations, relationships, and semantics. and semantics. object :An instance of a class. object :An instance of a class. 通通常常把把类类表表示示为为具具有有三三个个栏栏目目的的矩矩形形，每每个个栏栏目目分分别别代代表表类类名名、属性和操作。例如：属性和操作。例如： 类的一种表示类的一种表示类的其它种表示类的其它种表示其中，其中，类名使用黑体字，第一个字母通常要大写类名使用黑体字，第一个字母通常要大写, ,并位于第并位于第 一栏的中央一栏的中央; ; 实践中实践中, ,类名往往是从正被建模系统的词汇表中提取类名往往是从正被建模系统的词汇表中提取 的简单名词或名词短语的简单名词或名词短语; ; 类可以是抽象类，即没有实例的类类可以是抽象类，即没有实例的类, ,类名采用斜体字类名采用斜体字. .例如：例如：WindowWindowsize:Areavisibility:Booleandisplay( )hide( )属性（属性（attributeattribute） 属性是类的一个命名特性，由该类的所有对象所共享，用于属性是类的一个命名特性，由该类的所有对象所共享，用于表达对象状态的数据。表达对象状态的数据。 3 3点说明点说明 一个属性往往具有所属的类型一个属性往往具有所属的类型, ,用于描述该特性的实例可用于描述该特性的实例可以取值的范围。以取值的范围。 类的一个对象对每一个属性应有特定的值。类的一个对象对每一个属性应有特定的值。 一个类可以有多个属性，也可以没有属性。一个类可以有多个属性，也可以没有属性。 表示表示:操作（操作（operationoperation） 操作是服务的一个实现，由该类的任意对象为其行为所操作是服务的一个实现，由该类的任意对象为其行为所要求的。换言之，一个操作抽象了一个对象所要做的事情，要求的。换言之，一个操作抽象了一个对象所要做的事情，并且该类的其它对象也要做这件事情。并且该类的其它对象也要做这件事情。 2 2点说明：点说明： 调用调用一个对象上的操作可能会改变该对象的数据或状态。一个对象上的操作可能会改变该对象的数据或状态。 一个类可以有多个操作，也可以没有操作。一个类可以有多个操作，也可以没有操作。Rectangleadd()grow()move()isEmpty表示：表示：其中：其中：在实际应用中，操作名往往是描述其所在类的行为的动词在实际应用中，操作名往往是描述其所在类的行为的动词或动词短语或动词短语在操作名中，除第一个词之外，其他每个词的第一个字母在操作名中，除第一个词之外，其他每个词的第一个字母要大写要大写 可以通过给出操作的特征标记进一步描述之，特征标记通可以通过给出操作的特征标记进一步描述之，特征标记通常包括参数名、类型和默认值常包括参数名、类型和默认值; ;如果该操作是一个函数，那么如果该操作是一个函数，那么其特征标记还包括返回类型。如下所示：其特征标记还包括返回类型。如下所示：TemperatureSensorreset()setAlarm(t:temperature)value():Temperature责任（责任（responsibilityresponsibility） 一个类一个类承诺的任务承诺的任务（contractcontract）或职责）或职责(obligation).(obligation). 4 4点说明：点说明： 类的责任表达了定义类的责任表达了定义一个类的目的。一个类的目的。 例如：例如：wallwall类类 其目的是为了了解墙的高度、宽度和厚度。其目的是为了了解墙的高度、宽度和厚度。 给出一个类的责任，是建立该类模型的起始点。给出一个类的责任，是建立该类模型的起始点。 实践中，每个结构良好的类至少要有一个职责，但最多实践中，每个结构良好的类至少要有一个职责，但最多 也只能是当时所能考虑到的几个。也只能是当时所能考虑到的几个。例如：例如：一个接口一个接口“调制解调器调制解调器”有四个功能：有四个功能：interfacemodempublicvoiddial(stringpno);publicvoidhangup();publicvoidsend(charc);publicvoidrecv(); 根据责任的定义，可以认为该接口有两个职责：根据责任的定义，可以认为该接口有两个职责：连接处理（连接处理（publicvoiddial(stringpno);publicvoidhangup();）数据通信（数据通信（publicvoidsend(charc);publicvoidrecv();）显然，以上设计违背了：单一显然，以上设计违背了：单一职责职责原则（原则（SRP），即：），即：就一个类而言，应该仅有一个引起就一个类而言，应该仅有一个引起它变化的原因。它变化的原因。这条原则被称为内聚性原则。这条原则被称为内聚性原则。 类的责任是有类中定义的属性和操作实现的。在精化类类的责任是有类中定义的属性和操作实现的。在精化类 的模型时，需将责任转换为一组能够很好地完成责任的的模型时，需将责任转换为一组能够很好地完成责任的 属性和操作。属性和操作。表示：表示： 其他特征：其他特征： 除了规约以上提到的属性、操作和责任外，有时还需要规除了规约以上提到的属性、操作和责任外，有时还需要规约类的其它特征，例如属性和操作的可见性，操作的多约类的其它特征，例如属性和操作的可见性，操作的多态性等。态性等。 属性和操作的可见性属性和操作的可见性 操作的多态性操作的多态性 Rectangleadd()grow()move( )isEmptyRectangleadd()grow()move()算法算法isEmptyRectangleadd()grow()move()算法算法isEmpty类在建模中的主要用途类在建模中的主要用途模型化模型化一个系统中的词汇一个系统中的词汇要做以下工作：要做以下工作： 针对用户的问题或实现者的解决方案，标识使用针对用户的问题或实现者的解决方案，标识使用UMLUML可可描述其中的概念，作为一个类。描述其中的概念，作为一个类。注：其中可使用注：其中可使用USE CASEUSE CASE分析技术。分析技术。 标识其责任集。其中应确保每一个类通过这一责标识其责任集。其中应确保每一个类通过这一责任集予以清晰地定义，并使这些责任在类之间得到了很任集予以清晰地定义，并使这些责任在类之间得到了很好地均衡。好地均衡。 为每个类的责任的实现，提供了所需的属性和操作。为每个类的责任的实现，提供了所需的属性和操作。例如：一个零售系统例如：一个零售系统模型化模型化系统中的责任分布系统中的责任分布 其目标是：均衡系统中每一个类的责任，避免类过大或过其目标是：均衡系统中每一个类的责任，避免类过大或过小。过大小。过大- -难于复用；过小难于复用；过小- -难于理解和管理。难于理解和管理。 要做以下工作：要做以下工作： 为了完成某些行为，标识一组紧密协同工作的类。为了完成某些行为，标识一组紧密协同工作的类。 对以上的每个类，标识它的一组职责。对以上的每个类，标识它的一组职责。 从整体上观察这些类，把其中职责过多的类分解为一些从整体上观察这些类，把其中职责过多的类分解为一些教小抽象，而把责任过于锁碎的类合并为一个较大的类，教小抽象，而把责任过于锁碎的类合并为一个较大的类， 继之重新分配责任。继之重新分配责任。 考虑这些类的相互协作方式，调整它们的责任，使协作考虑这些类的相互协作方式，调整它们的责任，使协作中没有哪个类的职责过多或过少。中没有哪个类的职责过多或过少。例如：例如： 模型化模型化基本类型基本类型对简单类型建模，要做以下工作：对简单类型建模，要做以下工作：使用适当衍型的类，模型化所抽象为类型或枚举类型；其使用适当衍型的类，模型化所抽象为类型或枚举类型；其中，若需要详述与该类型相关的值域，可使用约束。中，若需要详述与该类型相关的值域，可使用约束。例如：例如： 类在使用中应注意的问题类在使用中应注意的问题每个类都应是某个有形的事物或概念的抽象。一个结构良好的每个类都应是某个有形的事物或概念的抽象。一个结构良好的类，应符合以下条件：类，应符合以下条件： 是对问题域或解域中的事物的明确抽象。是对问题域或解域中的事物的明确抽象。 嵌入了一个小的、明确定义的责任集，并能很好地实现之。嵌入了一个小的、明确定义的责任集，并能很好地实现之。 清晰地分离了抽象的规约和实现。清晰地分离了抽象的规约和实现。接口接口接口（接口（interface）是操作的一个集合，其中每个操作描述了）是操作的一个集合，其中每个操作描述了类或构件的一个服务。类或构件的一个服务。表示：表示：可以用带有分栏和关键字可以用带有分栏和关键字的矩形符号来表的矩形符号来表示接口。其中：示接口。其中： 在操作分栏中给出接口支持的操作列表在操作分栏中给出接口支持的操作列表 接口的属性分栏总是空的接口的属性分栏总是空的 也可以用小圆圈来表示接口：也可以用小圆圈来表示接口：注：该图表明，注：该图表明，类类String支支持持接接口口Hashable、Comparable，而而类类HashTable使使 用用 接接口口Hashable、Comparable。其中：其中： 接口名放在圆圈的下面，并用实线把圆圈连接到支持它接口名放在圆圈的下面，并用实线把圆圈连接到支持它 的类目上。的类目上。 这意味着这个类目要提供在接口中的所有操这意味着这个类目要提供在接口中的所有操 作，其实类目提供的操作可能要更多。作，其实类目提供的操作可能要更多。 把从类目到它支持的接口的实现关系显示为带有实把从类目到它支持的接口的实现关系显示为带有实三角箭头的虚线。三角箭头的虚线。 用带有用带有useuse标记的虚线箭头表示类目（在箭头标记的虚线箭头表示类目（在箭头尾部）使用或者需要接口提供的操作。尾部）使用或者需要接口提供的操作。显然，要显示接口的操作列表的话，就不能使用圆圈表显然，要显示接口的操作列表的话，就不能使用圆圈表示法，而应该使用矩形表示法。示法，而应该使用矩形表示法。 几点说明几点说明( (仅以类为例仅以类为例) ) 接口只描述类接口只描述类( (构件或子系统构件或子系统) )的外部可见操作，并不描述的外部可见操作，并不描述 内部结构。内部结构。 通常，接口仅描述一个特定类的有限行为。接口没有实现，通常，接口仅描述一个特定类的有限行为。接口没有实现， 接口也没有属性、状态或者关联，接口只有操作。接口也没有属性、状态或者关联，接口只有操作。 -接口在形式上等价于一个没有属性、没有方法而只有接口在形式上等价于一个没有属性、没有方法而只有 抽象操作的抽象类。抽象操作的抽象类。 接口只可以被其它类目使用，而其本身不能访问其它类目。接口只可以被其它类目使用，而其本身不能访问其它类目。 可以对接口使用泛化关系。可以对接口使用泛化关系。 关于其它可表达结构化事物的术语符号关于其它可表达结构化事物的术语符号 协作（协作（collaboration）：定义了一个交互，其中由一组角）：定义了一个交互，其中由一组角色和其它元素构成的，它们的共同工作提供了某种协作行为。色和其它元素构成的，它们的共同工作提供了某种协作行为。表示：表示：点说明：点说明：协作具有结构、行为和维度。协作具有结构、行为和维度。由于由于一个给定的类或对象可以参与多个协作，因此协一个给定的类或对象可以参与多个协作，因此协作表现了系统细化的构成模式。作表现了系统细化的构成模式。用况（用况（usecase）是对一组动作序列的描述，系统执行这些动作应产生对特是对一组动作序列的描述，系统执行这些动作应产生对特定的参与者有值的、可观察的结果。定的参与者有值的、可观察的结果。表示：表示：点说明：点说明：用况用于构造模型中的行为。用况用于构造模型中的行为。用况是通过协作予以细化的。用况是通过协作予以细化的。 主动类（主动类（activeclass）是一种至少具有一个进程或线程的类，因此它能够启动控制是一种至少具有一个进程或线程的类，因此它能够启动控制活动。活动。表示：表示：主要特性：主要特性：主动类对象的行为通常与其他元素的行为是并发的。主动类对象的行为通常与其他元素的行为是并发的。构件（构件（component）是系统设计的模块化部件，通过外部接口隐藏了它的内部实是系统设计的模块化部件，通过外部接口隐藏了它的内部实现。现。表示：表示：3点说明；点说明；在一个系统中，共享相同接口的构件可以相互替代，但其在一个系统中，共享相同接口的构件可以相互替代，但其中要保持相同的逻辑行为。中要保持相同的逻辑行为。可以结合连接件来表示构件的实现。可以结合连接件来表示构件的实现。 构件可以包含更小的构件。构件可以包含更小的构件。制品（制品（artifact）是系统中物理的、可替代的部件，其中包含物理信息是系统中物理的、可替代的部件，其中包含物理信息(比特比特).表示：表示：2点说明点说明在一个系统中，可能会存在不同类型的部署制品，例如源在一个系统中，可能会存在不同类型的部署制品，例如源代码文件代码文件、可执行程序和脚本等。可执行程序和脚本等。制品通常代表对源代码信息或运行时信息的一个物理打包制品通常代表对源代码信息或运行时信息的一个物理打包artifactWindow.dll注：以上个术语：主动类、构件和结点，都和类是相似的，注：以上个术语：主动类、构件和结点，都和类是相似的，即它们描述了一组具有相同属性、操作和相同语义的实体。即它们描述了一组具有相同属性、操作和相同语义的实体。节点（节点（node）是在运行时存在的物理元素，通常它表示一种具有记忆能是在运行时存在的物理元素，通常它表示一种具有记忆能力和处理能力的计算机资源。力和处理能力的计算机资源。表示：表示：1点说明：点说明：一个构件可以驻留在一个节点中，也可以从一个一个构件可以驻留在一个节点中，也可以从一个节点移到另一个节点。节点移到另一个节点。Server小结小结以上八个术语以上八个术语(模型化概念模型化概念)-类、接口、协作、用况、主动类、构件、制品、节点，类、接口、协作、用况、主动类、构件、制品、节点，是可包含在一个是可包含在一个UML模型中的基本模型化元素，用于抽象模型中的基本模型化元素，用于抽象客观世界中的任何实体对象客观世界中的任何实体对象它们存在一些变体，例如：它们存在一些变体，例如：类的变体类的变体-参与者、信号、实用程序参与者、信号、实用程序;主动类的变体主动类的变体-进程和线程；进程和线程；制品的变体制品的变体-应用、文档、库、页和表等。应用、文档、库、页和表等。在在UML中，把以上结构化概念统称为类目（中，把以上结构化概念统称为类目（classifier）为为了了组组织织类类目目, ,控控制制信信息息组组织织和和文文档档组组织织的的复复杂杂性性,UML,UML引引入入了术语了术语- -包。包。-语义语义 包包是是模模型型元元素素的的一一个个分分组组。一一个个包包本本身身可可以以被被嵌嵌套套在在其其它它包包中，并且可以含有子包和其它种类的模型元素。中，并且可以含有子包和其它种类的模型元素。一个包元素对外的可见性，可以通过在该元素名字前加上可一个包元素对外的可见性，可以通过在该元素名字前加上可见性符号（见性符号（+：公共的，：公共的，-：私有的，：私有的，#：受保护的）来指示。：受保护的）来指示。-表示表示 通通常常，在在大大矩矩形形中中描描述述包包的的内内容容，而而把把该该包包的的名名字字放放在在左上角的小矩形中。左上角的小矩形中。 -包之间的关系包之间的关系 标准依赖标准依赖：访问依赖和引入依赖。作用：使一个包可以访问：访问依赖和引入依赖。作用：使一个包可以访问和引入其它包。和引入其它包。 注注: :包间的依赖包间的依赖通常隐含了各包中元素之间存在着的一个或通常隐含了各包中元素之间存在着的一个或 多个依赖。多个依赖。可可以以把把所所包包含含的的元元素素画画在在包包的的外外面面，通通过过符符号号，将将这这些些元素与该包相连。元素与该包相连。这时可把该包的名字放在大矩形中。这时可把该包的名字放在大矩形中。引入引入:import获得访问并将目标名字空间中的那些具有可见性的名字获得访问并将目标名字空间中的那些具有可见性的名字 引入到客户包（即对它们的引用可不需要一个路径名）引入到客户包（即对它们的引用可不需要一个路径名）访问访问: : accessaccess 目标包中具有可见性的内容可以被客户包引用，或被嵌目标包中具有可见性的内容可以被客户包引用，或被嵌套在客户包中的其它包引用。套在客户包中的其它包引用。 注意，一个访问注意，一个访问: :不修改客户的名字空间不修改客户的名字空间; ; 不不以任何其它方式自动创建一些引用以任何其它方式自动创建一些引用 访问仅准予建立一些引用。访问仅准予建立一些引用。注注:如果在提出访如果在提出访问的那个包中还问的那个包中还存在包，那么嵌存在包，那么嵌套在其中的套在其中的包能得到与外层包能得到与外层包同样的访问。包同样的访问。(2)(2)、表达关系的术语、表达关系的术语 在在UMLUML中，有以下中，有以下4 4种关系：种关系：关联关联(association)泛化（泛化（generalization） 实现（实现（realization）依赖依赖(dependency)这这4 4种关系是种关系是UMLUML的基本关系构造块，用于表达类目的基本关系构造块，用于表达类目 之间的关系，以构造一个结构良好的之间的关系，以构造一个结构良好的UMLUML模型。模型。关联关联(association)定义：定义：关联是类目之间的结构关系，描述了一组链（关联是类目之间的结构关系，描述了一组链（linkslinks）, , 链是对象之间的连接（链是对象之间的连接（connectionconnection）。例如：）。例如： 注：如一个关联只连接两个类目，称为二元关联；注：如一个关联只连接两个类目，称为二元关联； 如一个关联连接如一个关联连接n n个类目，称为个类目，称为n n元关联元关联. .关联的语义表达（关联的语义表达（6点）：点）：u关联名关联名(name):(name):关联可以有一个名字，用于描述该关联的关联可以有一个名字，用于描述该关联的“涵涵义义”，为了避免该关联，为了避免该关联涵义涵义上的歧义性，可给出其关联方向。上的歧义性，可给出其关联方向。如上图所示。如上图所示。角色（角色（rolerole）: :当一个类参与一个关联时，有一个特定角色。当一个类参与一个关联时，有一个特定角色。在类的一个关联中，可以显式地命名该角色在类的一个关联中，可以显式地命名该角色, ,如下所示：如下所示：注：注：在明确给出关联端点名的情况下，通常可以不给出该关联在明确给出关联端点名的情况下，通常可以不给出该关联名但若一个类有多个关联，可使用关联名或端点名来区分名但若一个类有多个关联，可使用关联名或端点名来区分它们若一个类有多个端点，可使用端点名来区分它们它们若一个类有多个端点，可使用端点名来区分它们同一个类可以在其它关联中扮演相同或不同的角色同一个类可以在其它关联中扮演相同或不同的角色 多重性（多重性（multiplicitymultiplicity）: :类中对象参与一个关联的数目，类中对象参与一个关联的数目， 称为该关联角色的多重性。例如：称为该关联角色的多重性。例如：c1c2c3c4c5c6c7p1p3p2p4p5拥有关系拥有关系：，,模型化为模型化为1.20.1拥有拥有多重性的表达：多重性的表达：聚合（聚合（aggregationaggregation）: :一种特殊形式的关联，表达一种一种特殊形式的关联，表达一种“整整体体 / /部分部分”关系。即一个类表示了一个大的事物，它是有一些小关系。即一个类表示了一个大的事物，它是有一些小的事物（部分）组成的。的事物（部分）组成的。 注意：不论是整体类还是部分类，它们在概念上是处于同一注意：不论是整体类还是部分类，它们在概念上是处于同一个层次的。个层次的。- -在建模实践中在建模实践中, ,这是区分是否把一类事物标识为一个部分类这是区分是否把一类事物标识为一个部分类还是把它标识为一个类的属性的基本准则还是把它标识为一个类的属性的基本准则. . 组合（组合（compositioncomposition）定义：定义：A A form form of of aggregation aggregation which which requires requires that that a a part part instance instance be be included included in in at at most most one one composite composite at at a a time,and time,and that that the the composite composite object object is is responsible responsible for for the the creation creation and and destruction destruction of of the the parts. parts. Composition Composition may be recursive.may be recursive.Synonym: composite aggregation.Synonym: composite aggregation. Composite:A Composite:A class class that that is is related related to to one one or or more more classes by a composition relationship.classes by a composition relationship.点说明：点说明： 组组合合是是聚聚合合的的一一种种形形式式。部部分分和和整整体体之之间间具具有有很很强强的的“属属 于于”关系，具有一致的生存期关系，具有一致的生存期; ; 组合的末端，其多重性显然不能超过组合的末端，其多重性显然不能超过1 1； 在一个组合中，由一个链所连接的对象而构成的任何在一个组合中，由一个链所连接的对象而构成的任何 元组，必须都属于同一个容器对象元组，必须都属于同一个容器对象; ; 在一个组合中，其部分可以包含一些类和关联；根据需在一个组合中，其部分可以包含一些类和关联；根据需 要，也可以把它们规约为关联类。要，也可以把它们规约为关联类。该例给出了三种表示组合的方法。该例给出了三种表示组合的方法。其其中中，类类WindowWindow由由类类SilderSilder（角角色色为为ScrollbarScrollbar）、HeaderHeader（角色为（角色为titletitle） 和和PanelPanel（角色为（角色为bodybody）组成。）组成。表示：表示：表表示示组组合合的的不同方法不同方法 限定符：限定符： 一一个个限限定定符符是是一一个个关关联联的的属属性性或或属属性性表表，这这些些属属性性的的值值将将对该关联相关的对象集做了一个划分。对该关联相关的对象集做了一个划分。例如：例如：左图的限定符有一个属性左图的限定符有一个属性account#account#，表明：在一个银行中，表明：在一个银行中， 一个帐户对应一个用户，或没有对应人员。一个帐户对应一个用户，或没有对应人员。右图的限定符有两个属性，它们与右图的限定符有两个属性，它们与ChessboardChessboard一起确定了一起确定了 SquareSquare，且，且 SquareSquare是其组成部分。是其组成部分。关联类关联类一一种种模模型型元元素素，它它有有关关联联和和类类的的特特性性。一一个个关关联联类类，可可以以被被看看作作是是一一个个关关联联，但但还还有有类类的的特特性性；或或被被看看作作是是一一个个类类，但但有关联的特性。例如：有关联的特性。例如：companyperson0.1*Jobsalaryemployeremployee*Job1.*bossmanagesworker注意：注意：如果关联类只有属性而没有操作或其他关联，名字可以显示如果关联类只有属性而没有操作或其他关联，名字可以显示在在关关联联路路径径上上，从从关关联联类类符符号号中中省省去去，以以强强调调其其“关关联联性性质质”。如果它有操作和其他的关联，那么可以省略路径中的名字，如果它有操作和其他的关联，那么可以省略路径中的名字，并将他们放在类的矩形中，以强调其并将他们放在类的矩形中，以强调其“类性质类性质”。 在关联路径的两端可能都具有通常的附属信息，类符号也可在关联路径的两端可能都具有通常的附属信息，类符号也可以具有通常的内容，但在虚线上没有附属信息。以具有通常的内容，但在虚线上没有附属信息。 尽管把一个关联类画成一个关联和一个类，但它仍然是一个尽管把一个关联类画成一个关联和一个类，但它仍然是一个单一的模型元素。单一的模型元素。泛化（泛化（generalization）定义：定义：泛化是一般性事物（称为超类或父类）和它的较为特殊种类泛化是一般性事物（称为超类或父类）和它的较为特殊种类（称为子类）之间的一种关系，有时称为（称为子类）之间的一种关系，有时称为“is-a-kind-ofis-a-kind-of”关关系。系。4点说明：点说明：子类可继承父类的属性和操作，并可有更多的属性和操作；子类可继承父类的属性和操作，并可有更多的属性和操作； 子类可以替换父类的声明；子类可以替换父类的声明； 若子类的一个操作的实现覆盖了父类同一个操作的实现，若子类的一个操作的实现覆盖了父类同一个操作的实现， 这种情况被成为多态性，但两个操作必须具有相同的名字这种情况被成为多态性，但两个操作必须具有相同的名字 和参数。和参数。一个类可以有一个类可以有0 0个、个、1 1个或多个父类。没有父类且最少有一个个或多个父类。没有父类且最少有一个子类的类被称为根类或基类；没有子类的类称为叶子类。如果子类的类被称为根类或基类；没有子类的类称为叶子类。如果一个类只有一个父类，则说它使用了单继承；如果一个类有多一个类只有一个父类，则说它使用了单继承；如果一个类有多个父类，则说它使用了多继承。个父类，则说它使用了多继承。注：在大多数情况中，用类和接口之间的泛化来表明继承关系。在注：在大多数情况中，用类和接口之间的泛化来表明继承关系。在UML中，也可在其他类目之间创建泛化，例如在结点之间。中，也可在其他类目之间创建泛化，例如在结点之间。表示：表示： 分离表示法分离表示法共享表示法共享表示法 细化（细化（realization）定义：定义：细化是类目之间的一种语义关系，其中一个类目规细化是类目之间的一种语义关系，其中一个类目规约了保证另一个类目执行的契约。约了保证另一个类目执行的契约。说明：说明：在以下在以下2 2个地方会使用实现关系：个地方会使用实现关系： 接口与实现它们的类和构件之间；接口与实现它们的类和构件之间； 用况与实现它们的协作之间。用况与实现它们的协作之间。表示：表示：依赖依赖定义；定义；依赖是一种使用关系，用于描述一个事物（如类依赖是一种使用关系，用于描述一个事物（如类WindowWindow）使用另一事物（如类）使用另一事物（如类EventEvent）的信息和服务。）的信息和服务。3点说明：点说明：在大多数情况里，使用依赖来描述一个类使用另一个的操在大多数情况里，使用依赖来描述一个类使用另一个的操 作；作； 如果被使用的类发生变化，那么另一个类的操作也会受到如果被使用的类发生变化，那么另一个类的操作也会受到 影响；影响； 依赖可用于其它事物之间，例如注解之间和包之间。依赖可用于其它事物之间，例如注解之间和包之间。表示：一条有向虚线。例如：表示：一条有向虚线。例如： 为为了了进进一一步步表表达达依依赖赖的的语语义义，UMLUML对对依依赖赖进进行行了了分分类类，并并给给出出了相应的标记。了相应的标记。 绑绑定定（bindbind）：表表明明源源的的实实例例化化是是使使用用目目标标给给定定的的实实际际参参数数来来达达到到的的。例例如如，可可以以把把模模板板容容器器类类（目目标标）和和这这个个类类实实例例（源源）之之间间的的关关系系模模型型化化为为绑绑定定。其其中中绑绑定定涉涉及及到到一一个个映映射射，即实参到形参的映射。即实参到形参的映射。 导导出出（derivederive）: :表表明明可可以以从从目目标标推推导导出出源源。例例如如类类Person Person 有有属属性性“生生日日”和和 “年年龄龄”， 假假定定属属性性“生生日日”是是具具体体的的，而而“年年龄龄” 是是抽抽象象的的，由由于于“年年龄龄”可可以以从从“生生日日”导导出出，因因此可以把这两个属性之间的这一关系模型化为导出。此可以把这两个属性之间的这一关系模型化为导出。 允允许许（permitpermit）：表表明明目目标标对对源源而而言言是是可可见见的的。一一般般情情况况下下，当当许许可可一一个个类类访访问问另另一一个个类类的的私私有有特特征征时时，往往往往把把这这种种使使用用关关系模型化为允许。系模型化为允许。实例（实例（instanceOfinstanceOf）：表明源的对象是目标的一个实例。）：表明源的对象是目标的一个实例。实例化（实例化（instantiateinstantiate）：表明源的实例是由目标创建的。）：表明源的实例是由目标创建的。幂类型（幂类型（powertypepowertype）：表明源是目标的幂类型。）：表明源是目标的幂类型。精精化化（refinerefine）：表表明明源源比比目目标标更更精精细细。例例如如在在分分析析时时存存在在一一个类个类A A，而在设计时的，而在设计时的A A所包含的信息要比分析时更多。所包含的信息要比分析时更多。使用（使用（useuse）：表明源的公共部分的语义依赖于目标的语义）：表明源的公共部分的语义依赖于目标的语义. .以上谈到的以上谈到的4个术语，是个术语，是UML模型中可以包含的基本关系。模型中可以包含的基本关系。它们也有一些变体，例如精化、跟踪、包含和扩展等。它们也有一些变体，例如精化、跟踪、包含和扩展等。4 4种关系的一般用法种关系的一般用法 模型化简单依赖模型化简单依赖 例如，一种常见的依赖关系是：一个类只是使用另一个类例如，一种常见的依赖关系是：一个类只是使用另一个类作为它的操作参数。作为它的操作参数。 对此对此, ,可可从含有操作的类到被该操作用做参数的类创建一个从含有操作的类到被该操作用做参数的类创建一个依赖。即依赖。即: : CourseSchduleadd(c:Course)remove(c:Course)Course 注：注：如果操作如果操作addadd和和removeremove给出了明显的操作标记给出了明显的操作标记（c:Coursec:Course，如上所示），则一般就不需要给出这个依赖；如上所示），则一般就不需要给出这个依赖； 但当省略操作标记时或一个模型还描述了被使用类的其它但当省略操作标记时或一个模型还描述了被使用类的其它关系时，就应显示这一依赖。关系时，就应显示这一依赖。模型化单继承模型化单继承 第一步第一步: :对于给定的一组类，发现对于给定的一组类，发现2 2个或个或2 2个以上类的共同责个以上类的共同责 任、属性和操作。任、属性和操作。 第二步第二步: :把发现的共同责任、属性和操作放到一个一般类中把发现的共同责任、属性和操作放到一个一般类中 其中要注意，不要引入过多的层次。其中要注意，不要引入过多的层次。 第三步第三步: :画出从每个特殊类到一般类（父类）的泛化关系。画出从每个特殊类到一般类（父类）的泛化关系。例如：例如：注：注： 斜体字表明是斜体字表明是一个抽象类或抽一个抽象类或抽象操作；象操作； 子类中给出的子类中给出的操作为非斜体字，操作为非斜体字，表明给出了操作表明给出了操作的实现。的实现。 模型化结构关系模型化结构关系第一步：标识关联第一步：标识关联若对于每一个类，需要导航到另一个类的对象，那么就若对于每一个类，需要导航到另一个类的对象，那么就要在这要在这2 2个类之间给出一个关联。个类之间给出一个关联。这是关联的数据驱动观点。这是关联的数据驱动观点。例如，例如，一个学校信息系统中的一组类：一个学校信息系统中的一组类：例如：例如：要了解要了解Student所要参与的课程，所要参与的课程，因此就应在因此就应在Student和和Course之间给出之间给出一个关联，用于一个关联，用于描述学生参与的描述学生参与的课程；课程；若对于每一个类的对象需要与另一个类的对象进行交互，若对于每一个类的对象需要与另一个类的对象进行交互，并且后一个对象不作为前一个对象的局部变量或操作参数，那并且后一个对象不作为前一个对象的局部变量或操作参数，那么就要在这么就要在这2 2个类之间给出一个关联。个类之间给出一个关联。 这是关联的行为驱动观点。这是关联的行为驱动观点。第二步：第二步：对于标识的每一个关联，添加语义描述对于标识的每一个关联，添加语义描述例如，就上图而言，给出关联的多重性：例如，就上图而言，给出关联的多重性：每门课程至少有一名教师，而没有一名教师可以每门课程至少有一名教师，而没有一名教师可以教教0 0到多门课程。到多门课程。 每门课程是精确地属于一个系的。每门课程是精确地属于一个系的。 第三步：标识第三步：标识“整体部分整体部分”如果关联中的一个类与另一端的类相比，前者在结构上或组如果关联中的一个类与另一端的类相比，前者在结构上或组 织上是一个整体，而后者似乎是它们的一部分，那么就要把织上是一个整体，而后者似乎是它们的一部分，那么就要把 它们标识为聚合，例如，见上图：它们标识为聚合，例如，见上图： 聚合：聚合：一所学校可以有一所学校可以有0 0到多名学生，一个学生可以注册在到多名学生，一个学生可以注册在 一所或多所学校学习；一所或多所学校学习； 聚合：聚合：一所学校可以有一个或多个系，而每个系只能属于一一所学校可以有一个或多个系，而每个系只能属于一 所学校；所学校；要注意：在该例中，要注意：在该例中，DepartmentDepartment和和InstructorInstructor之间有两之间有两 个关联，其中：一个关联（聚合）说明可以指派一名教师个关联，其中：一个关联（聚合）说明可以指派一名教师到一个或多个系中工作，而一个系可以有一名或多名教师到一个或多个系中工作，而一个系可以有一名或多名教师 另一关联表明一个系只能有一名教师作系主任，而某些教另一关联表明一个系只能有一名教师作系主任，而某些教 师不是系主任。师不是系主任。基本策略基本策略 在用在用UMLUML对关系建模时，要遵循以下策略：对关系建模时，要遵循以下策略： 仅当要建模的关系不是结构关系时，才使用依赖。仅当要建模的关系不是结构关系时，才使用依赖。 这条策略意味着什么？这条策略意味着什么？ 仅当关系是仅当关系是“is-a-kind-ofis-a-kind-of”关系时，才使用泛化。关系时，才使用泛化。 聚合可否替代多继承？聚合可否替代多继承？ 一般不要引入循环的泛化关系。一般不要引入循环的泛化关系。 应保持泛化关系的平衡：继承的层次不要多深，不要过宽应保持泛化关系的平衡：继承的层次不要多深，不要过宽 （如果出现这种情况，就要寻找可能的中间抽象类）。（如果出现这种情况，就要寻找可能的中间抽象类）。 (3)、静态模型表达工具、静态模型表达工具-类图类图定义：定义：类图是给出一组类、接口、协作以及它们之间类图是给出一组类、接口、协作以及它们之间关系的图。关系的图。作用：作用： 可用于可视化地表达系统的静态模型。可用于可视化地表达系统的静态模型。 是构件图和部署图的基础。是构件图和部署图的基础。类图的内容：类图的内容：通常包含：通常包含： 类；类； 接口；接口； 依赖、泛化和关联关系。依赖、泛化和关联关系。 还可以包含注解和约束还可以包含注解和约束, ,以及或子系统，甚至以及或子系统，甚至, ,可包含可包含 一个实例一个实例, ,以便使其可视化。以便使其可视化。注注:这些成分这些成分, ,确定了所表达系统的各种形态确定了所表达系统的各种形态. .例如例如: 类图的一般用法类图的一般用法类图主要用于对系统的静态设计视图（投影）进行建模，支类图主要用于对系统的静态设计视图（投影）进行建模，支持表达系统的功能需求，既系统提供给最终用户的服务。持表达系统的功能需求，既系统提供给最终用户的服务。一般以三种方式使用类图一般以三种方式使用类图:对系统中的词汇建模对系统中的词汇建模当要决策：使用哪些类目和当要决策：使用哪些类目和UMLUML关系关系, ,作为系统的组成部分作为系统的组成部分; ;哪哪些类目类目和些类目类目和UMLUML关系关系, ,处于系统之外。此时可使用类图来描述处于系统之外。此时可使用类图来描述这些抽象和它们的责任。这些抽象和它们的责任。 对简单协作建模对简单协作建模当需要用一组类来表达系统中的某一事物语义时，可使用类当需要用一组类来表达系统中的某一事物语义时，可使用类图详细描述这组类以及它们之间的关系。图详细描述这组类以及它们之间的关系。 对逻辑数据库模式建模对逻辑数据库模式建模当需要给出数据库概念设计的指导当需要给出数据库概念设计的指导,可对要在数据库中存储的可对要在数据库中存储的信息信息,采用类图对相应的数据库模式进行建模。采用类图对相应的数据库模式进行建模。关于关于UML的图的图-模型表达工具模型表达工具UML为不同抽象层提供了为不同抽象层提供了6种可对系统静态部分建模的种可对系统静态部分建模的图形工具：图形工具：类图；类图；构件图；构件图； 组合结构图；组合结构图；对象图；对象图； 部署图；部署图；制品图。制品图。UML为不同抽象层提供了为不同抽象层提供了7种可对系统动态部分建模的种可对系统动态部分建模的图形工具：图形工具： 用况图；用况图；状态图；状态图； 活动图；活动图； 顺序图；顺序图； 通信图；通信图； 交互概观图；交互概观图； 定时图。定时图。(4)、系统行为（功能）的建模工具、系统行为（功能）的建模工具-USECASE图图USECASE图图注注:对行为的抽象，一直是人们的一个研究课题。对行为的抽象，一直是人们的一个研究课题。USECASE图的内容：图的内容：通常包含通常包含6个抽象：个抽象： 主题（主题（Subject）；）； 用况（用况（Usecases）；）； 参与者（参与者（Actor） 依赖；依赖； 泛化；泛化； 关联。关联。即：即：USE CASEUSE CASE图是一种表达动态模型的图形化工具，其中显图是一种表达动态模型的图形化工具，其中显 示了一组示了一组Use casesUse cases、ActorsActors以及它们之间的关系。以及它们之间的关系。 USE CASEUSE CASE图还可以包含包，形成一些更大的功能块。有时图还可以包含包，形成一些更大的功能块。有时 为了对一个特定的执行系统进行可视化，也把用况的实例放为了对一个特定的执行系统进行可视化，也把用况的实例放 到到USE CASEUSE CASE图中。图中。以上抽象确定了所表达的以上抽象确定了所表达的系统的各种形态系统的各种形态.注注: :为使以为使以USE CASEUSE CASE图表达的图表达的系统更易理解系统更易理解, ,包含注解和约束。包含注解和约束。关于关于USECASE图中的术语图中的术语-主题主题是由一组用况所描述的一个类，该类通常是一个系统或子是由一组用况所描述的一个类，该类通常是一个系统或子系统。其中的这些用况描述了该主题的完整行为，而参与者系统。其中的这些用况描述了该主题的完整行为，而参与者则表示与该主题进行交互的另一种类。则表示与该主题进行交互的另一种类。-USECASE定义定义：（从：（从2个视角）个视角）使用视角使用视角：Eachwaytheactorusethesystemisrepresentedasausecase.例如：例如：“做一次拼写检查做一次拼写检查”; ; “对一个文档建立索引对一个文档建立索引” 系统设计视角系统设计视角：一个一个usecase规约了系统可以执行的一个动作（规约了系统可以执行的一个动作（action）序）序列，包括一些可能的变体，并对特定的操作者（列，包括一些可能的变体，并对特定的操作者（actor）产生可）产生可见的、有值的结果。见的、有值的结果。值值1 1值值2 2 注注:以以USE CASE USE CASE 规约的系统规约的系统功能是通过与操作者（功能是通过与操作者（ actor） 可见结果的可见结果的“交互交互”予以体现的。即予以体现的。即一个一个USECASE捕获了捕获了参与交互的各方关于其行为的一个约定。通过这一约定，参与交互的各方关于其行为的一个约定。通过这一约定，描述了该语义实体在不同条件下的行为对参与者一个要求的描述了该语义实体在不同条件下的行为对参与者一个要求的响应，以实现某一目的。其中同的行为序列，依赖于所给出响应，以实现某一目的。其中同的行为序列，依赖于所给出的特定要求以及与这些要求相关的条件。的特定要求以及与这些要求相关的条件。 对于一个对于一个use caseuse case的行为，可以根据具体情况，通过交互的行为，可以根据具体情况，通过交互（图）、活动（图）和状态机予以描述，或通过前置条件和后（图）、活动（图）和状态机予以描述，或通过前置条件和后 置条件予以描述，或通过自然语言（例如事件流）予以描述。置条件予以描述，或通过自然语言（例如事件流）予以描述。也可以以以上的某一组合来描述也可以以以上的某一组合来描述。 用况可用于整个系统，也可应用于子系统、单个类和接口。用况可用于整个系统，也可应用于子系统、单个类和接口。 不论应用到什么情况，它们仅代表这些元素被期望的行为，可不论应用到什么情况，它们仅代表这些元素被期望的行为，可 作为这些元素在开发中演化时测试用例的基础作为这些元素在开发中演化时测试用例的基础, ,特别是子系统特别是子系统 的用况是回归测试的最好的源；整个系统的用况是集成测试和的用况是回归测试的最好的源；整个系统的用况是集成测试和 系统测试的最好的源。系统测试的最好的源。 图形表示图形表示： 每个用况必须有一个区别于其他用况的名字。名字是一个每个用况必须有一个区别于其他用况的名字。名字是一个字符串。字符串。PlaceorderValidateuserSensors:Calibratelocation简单名简单名受限名受限名对以后开发活动的影响：对以后开发活动的影响： 它是类、对象、操作的源，是系统分析和设计阶段的输它是类、对象、操作的源，是系统分析和设计阶段的输入之一；入之一； 是分析和设计，制定开发计划，测试计划，设计测试用是分析和设计，制定开发计划，测试计划，设计测试用 例的依据之一。例的依据之一。 Use CaseUse Case可以划分系统与外部实体的界限，是系统开发的可以划分系统与外部实体的界限，是系统开发的 起点。起点。-actor定义：定义：参与者表达了一组高内聚的角色，当用户与参与者表达了一组高内聚的角色，当用户与USE CASEUSE CASE 交互时，该用户扮演了这些角色。交互时，该用户扮演了这些角色。3点说明：点说明： 通常，一个参与者表达了与系统交互的那些人的角色、硬件通常，一个参与者表达了与系统交互的那些人的角色、硬件 的角色或其它系统的角色。的角色或其它系统的角色。 参与者实际上不是软件应用的一部分，而是在应用的环境参与者实际上不是软件应用的一部分，而是在应用的环境 之中之中, ,其其实例代表以某种特定方式与系统进行交互。实例代表以某种特定方式与系统进行交互。 一个客体对象可以扮演多个参与者，一个客体对象可以扮演多个参与者，例如一个人既可以是例如一个人既可以是 参与者参与者LoanOffierLoanOffier，又是参与者，又是参与者CostomerCostomer。一个参与者代表一个参与者代表 了客体一个方面的角色。了客体一个方面的角色。表示：表示：关系：可以定义参与者之间的泛化关系，例如：关系：可以定义参与者之间的泛化关系，例如：-关系关系 关联：参与关系，即操作者参与一个关联：参与关系，即操作者参与一个USE CASEUSE CASE。例如，操。例如，操 作者的实例与作者的实例与USE CASEUSE CASE实例相互通讯。实例相互通讯。 关联是操作者和关联是操作者和USE CASEUSE CASE之间的唯一关系。之间的唯一关系。 扩展：扩展：USE CASE AUSE CASE A到到USE CASE BUSE CASE B的一个扩展关系，指出了的一个扩展关系，指出了 USE CASE BUSE CASE B的一个实例可以由的一个实例可以由A A说明的行为予以扩说明的行为予以扩 展（根据该扩展所说明的特定条件），并依据该扩展（根据该扩展所说明的特定条件），并依据该扩 展点定义的位置，展点定义的位置，A A说明的行为被插入到说明的行为被插入到B B中。中。 包含：包含：USE CASE AUSE CASE A到到USE CASE BUSE CASE B的一个包含，指出的一个包含，指出A A的一个的一个 实例将包含实例将包含B B说明的行为，即这一行为将包含在说明的行为，即这一行为将包含在A A定定 义的那部分中。义的那部分中。 泛化：泛化：USE CASE AUSE CASE A到到USE CASE BUSE CASE B的泛化，指出的泛化，指出A A是是B B的特殊的特殊 情况。情况。 注：注：扩展扩展和和包含包含是依赖的变体。是依赖的变体。1*thesalespersonasksforthecatalogPlaceOrderextensionpointsadditionalrequests:aftercreationoftheorderSupplyCustomerDataOrderProduckArrangePaymentRequestCatalogsalesperson例：例：USE CASE USE CASE 关系关系 Actor Actor 关系关系SupervisorEstablishCredit1* 用况图的使用用况图的使用-对系统语境建模对系统语境建模给定一个系统，均有其内部的事物和外部的事物。例如；给定一个系统，均有其内部的事物和外部的事物。例如；在在一一个个信信用用卡卡系系统统中中，其其内内部部事事物物有有：帐帐户户、事事务务处处理理和和欺欺诈诈行行为为检检测测代代理理；其其外外部部事事务务有有：信信用用卡卡顾顾客客和和零零售售机机构构。其其内内部部事事物物的的责责任任是是完完成成其其外外部部事事物物所所期期望望由由系系统统提提供供的的行行为为。与与系系统统交交互互的的外外部部事事物物构构成成了了该该系系统统的的语语境境，该该语语境境定定义义了了系系统存在的环境。统存在的环境。第第一一点点:采采用用UML用用况况图图对对系系统统语语境境进进行行建建模模，应应关关注注存存在在于于系系统统周周围围的的参参与与者者,确确定定什什么么作作为为系系统统的的参参与与者者，什什么么不不作作为为系系统统的的参参与与者者，使使该该图图只只包包含含那那些些在在其其生生命命周周期期内内所所必必须须的的参参与与者者。财务结算机构（负责信财务结算机构（负责信用卡帐户的结算服务）用卡帐户的结算服务）零售机构（顾客通过该零售机构（顾客通过该机构刷卡，购买商品或机构刷卡，购买商品或服务。服务。第二点第二点: :对系统语境建模，应遵循以下策略：对系统语境建模，应遵循以下策略： 决定哪些行为是系统的一部分，那些行为是由外部实体执行决定哪些行为是系统的一部分，那些行为是由外部实体执行 的，以此标识系统边界，同时定义主题。的，以此标识系统边界，同时定义主题。 在标识系统的参与者时，应考虑以下问题：在标识系统的参与者时，应考虑以下问题： 谁需要得到系统的帮助，以完成其任务；谁需要得到系统的帮助，以完成其任务； 谁执行系统的功能；谁执行系统的功能； 系统与哪些硬件设备或其他系统交互；系统与哪些硬件设备或其他系统交互； 谁执行一些辅助功能进行系统的管理和维护。谁执行一些辅助功能进行系统的管理和维护。 将一些相似的参与者组织为一般将一些相似的参与者组织为一般/ /特殊结构。特殊结构。 在需要加深理解的地方，为每个参与者提供一个衍型。在需要加深理解的地方，为每个参与者提供一个衍型。最最后后, ,将将这这些些参参与与者者放放入入用用况况图图中中，并并建建立立它它们们与与系系统统用用况况之之间的关联间的关联- -通信路径通信路径. . -对需求建模对需求建模对系统的需求建模，应遵循以下策略：对系统的需求建模，应遵循以下策略： 首先首先, ,通过标识参与者来建立系统的语境。通过标识参与者来建立系统的语境。 其次其次, ,对于每个参与者考虑他所期望或需要系统提供的行对于每个参与者考虑他所期望或需要系统提供的行 为。并把它们作为用况。为。并把它们作为用况。 第三第三, ,通过通过分解用况所表达的行为，形成必要的泛化结构和分解用况所表达的行为，形成必要的泛化结构和 扩展、包含结构。扩展、包含结构。 第四第四, ,模型化模型化用况图中各种关系。用况图中各种关系。 最后最后, ,通过注解和约束给出这些用况的非功能需求。通过注解和约束给出这些用况的非功能需求。需求可以用各种形式予以表达，但大多数的系统需求可以用各种形式予以表达，但大多数的系统功能都可以功能都可以表示成用况。表示成用况。例如：例如：(5)、系统行为（交互）的建模工具、系统行为（交互）的建模工具-顺序图顺序图定义：顺序图是一种交互图，即由一组对象以及这些对象之定义：顺序图是一种交互图，即由一组对象以及这些对象之间的关系组成，其中还包含这些对象之间被发送的消间的关系组成，其中还包含这些对象之间被发送的消息。例如：息。例如：顺序图所包含的内容：顺序图所包含的内容：交互各方：角色或对象交互各方：角色或对象交互方式：通讯或链交互方式：通讯或链 交互内容：消息交互内容：消息像其它图形一样，可以包含注解和约束。像其它图形一样，可以包含注解和约束。这些成分确定了交互的各种形态这些成分确定了交互的各种形态.从应用的角度来看，交互图是一个交互中各元素（各方、从应用的角度来看，交互图是一个交互中各元素（各方、方式和内容）的投影。其中把这些元素的语义应用到交互方式和内容）的投影。其中把这些元素的语义应用到交互图中。图中。5点说明点说明顺序图包含了一些由时间定序的消息。消息被表示为一条箭顺序图包含了一些由时间定序的消息。消息被表示为一条箭头线，从一条生命线到另一条生命线。其中头线，从一条生命线到另一条生命线。其中:-如果消息是异步的，则用枝形箭头线表示；如果消息是异步的，则用枝形箭头线表示；-如果消息是同步的（调用），则用实心三角箭头线表示；如果消息是同步的（调用），则用实心三角箭头线表示；同步消息的回复用枝形箭头虚线表示。同步消息的回复用枝形箭头虚线表示。对象生命线，用于表示一个对象在一个特定的时间段中的存对象生命线，用于表示一个对象在一个特定的时间段中的存在。对象生命线被表示为垂直的虚线。在。对象生命线被表示为垂直的虚线。 控制焦点（控制焦点（thefocusofcontrol）,表达一个对象执行一个动表达一个对象执行一个动作的时间段。可以表达嵌套的控制焦点。控制焦点被表示为作的时间段。可以表达嵌套的控制焦点。控制焦点被表示为细高的矩形。细高的矩形。时序，一条生命线上的时序是非常重要的，使消息集合形成时序，一条生命线上的时序是非常重要的，使消息集合形成了一个偏序关系，建立了一个因果链。了一个偏序关系，建立了一个因果链。顺序图中的结构控制顺序图中的结构控制常见的控制类型有：常见的控制类型有：选择执行选择执行(Optionalexecution)一种结构控制类型一种结构控制类型,其标签为其标签为opt。仅当进入该控制操作子。仅当进入该控制操作子（controloperator），一个监护条件为真时，该控制操作子的），一个监护条件为真时，该控制操作子的体才予执行。体才予执行。注注:监护条件是一个布尔表达式，可以出现在该体中任意一个监护条件是一个布尔表达式，可以出现在该体中任意一个生命线顶端的方括号内，并且可以引用那个对象的属性。生命线顶端的方括号内，并且可以引用那个对象的属性。条件执行（条件执行（Conditionalexecution）一种结构控制类型一种结构控制类型, ,其标签为其标签为altalt。该控制操作子的体通过水平。该控制操作子的体通过水平线将其分为一些部分。每一部分表示一个条件分支，并有一个监线将其分为一些部分。每一部分表示一个条件分支，并有一个监护条件。其中：护条件。其中： 若一个部分的监护条件为真，那么该部分就被执行。但是，若一个部分的监护条件为真，那么该部分就被执行。但是，最多一个部分可以被执行；如果多个监护条件为真时，选择哪一最多一个部分可以被执行；如果多个监护条件为真时，选择哪一部分执行，这是一个非确定性的问题，其执行可以不同。部分执行，这是一个非确定性的问题，其执行可以不同。 如果没有一个监护条件为真，那么控制将绕过该控制操作子如果没有一个监护条件为真，那么控制将绕过该控制操作子而继续。而继续。 一个部分可以有一个特定的监护条件一个部分可以有一个特定的监护条件else;else;对于这一部分对于这一部分而言，如果没有其它监护条件为真，那么该部分才被执行。而言，如果没有其它监护条件为真，那么该部分才被执行。 并发执行（并发执行（Parallelexecution）一种结构控制类型一种结构控制类型, ,其标签为其标签为parpar。该控制操作子的体通过水。该控制操作子的体通过水平线将其分为多个部分。每一部分表示一个并行计算。平线将其分为多个部分。每一部分表示一个并行计算。 在大多在大多数情况下，每一部分涉及不同的生命线。数情况下，每一部分涉及不同的生命线。当进入该控制操作子时，所有部分并发执行。当进入该控制操作子时，所有部分并发执行。 在每一部分中的消息的发送在每一部分中的消息的发送/ /接受是有次序的，但在整个并接受是有次序的，但在整个并 发部分中的消息次序则完全是任意的。因此对于不同的计算的发部分中的消息次序则完全是任意的。因此对于不同的计算的交互，就不应使用这一控制结构。交互，就不应使用这一控制结构。 实际上存在很多情况，可分解为一些独立的、并发的活动，实际上存在很多情况，可分解为一些独立的、并发的活动，因此，这是一个非常有用的操作子。因此，这是一个非常有用的操作子。迭代执行（迭代执行（iterativeexecution）一种结构控制类型一种结构控制类型, ,其标签为其标签为looploop。一个监护条件出现在该体。一个监护条件出现在该体中一个生命线的顶端中一个生命线的顶端, ,只要在每一次迭代之前该监护条件为真，只要在每一次迭代之前该监护条件为真，该循环体就反复执行。当该体上面的监护条件为假时，控制绕该循环体就反复执行。当该体上面的监护条件为假时，控制绕过该控制操作子。过该控制操作子。注意：还存在其它控制操作子，但以上注意：还存在其它控制操作子，但以上4 4中是最常使用的。中是最常使用的。(6)、系统行为（生存周期）的建模工具、系统行为（生存周期）的建模工具-状态状态图图定义：定义：状态图是显示一个状态机的图，其中强调了从一个状态图是显示一个状态机的图，其中强调了从一个 状态到另一状态的控制流。状态到另一状态的控制流。一个状态机是一种行为，规约了一个对象在其生存期间因一个状态机是一种行为，规约了一个对象在其生存期间因响应事件并作出响应而经历的状态。响应事件并作出响应而经历的状态。状态状态1或或/和条件和条件Action状态状态2或或/和条件和条件Action状态状态3状态状态4或或/和条件和条件Action状态状态6状态状态5状态状态7或或/和条件和条件Action状态状态8条件条件条条件件状态图的内容状态图的内容通常包含通常包含: 简单状态和组合状态；简单状态和组合状态； 事件事件 转换转换 像其它图形一样，可以包含注解和约束。像其它图形一样，可以包含注解和约束。状态图中所包含的内容，确定了一个特定的抽象层，该抽象状态图中所包含的内容，确定了一个特定的抽象层，该抽象层决定了以状态图所表达的模型之形态。层决定了以状态图所表达的模型之形态。 从使用的角度来看，一个状态图可以包含一个状态机中从使用的角度来看，一个状态图可以包含一个状态机中任意的、所有的特征（任意的、所有的特征（featuresfeatures）, ,即状态图基本上是一个即状态图基本上是一个状态机中那些元素状态机中那些元素( (分支、结合、动作状态、活动状态、对分支、结合、动作状态、活动状态、对象、初始状态、最终状态、历史状态等象、初始状态、最终状态、历史状态等) )的一个投影。的一个投影。状态状态 定义定义: :一个状态是一个状态是类目的一个实例（以后简称对象）在其类目的一个实例（以后简称对象）在其生生 存期间的一种条件存期间的一种条件(condition)(condition)或情况（或情况（situationsituation）, ,该该 期间该对象满足这一条件，执行某一活动或等待某一消息。期间该对象满足这一条件，执行某一活动或等待某一消息。 表示表示： 一个状一个状态表达了一个表达了一个对象所象所处的特定的特定阶段，所具有的段，所具有的对外呈外呈现（外征）以及所能提供的服（外征）以及所能提供的服务。 TypingPassword(A)(B) 状态分类状态分类: : UML UML把状态分为初态、终态和正常状态把状态分为初态、终态和正常状态: : 初态初态: :表达状态机默认的开始位置，用实心圆来表示；表达状态机默认的开始位置，用实心圆来表示； 终态终态: :表达状态机的执行已经完成，用内含一个实心圆的圆表达状态机的执行已经完成，用内含一个实心圆的圆 来表示来表示; ; 正常状态正常状态: :既不是初态又不是终态的状态既不是初态又不是终态的状态, ,称为正常状态称为正常状态. . ( (注注: :在以后的叙述中，在没有特别说明的情况下所说的状在以后的叙述中，在没有特别说明的情况下所说的状 态指的是正常状态。态指的是正常状态。) ) 实际上，初态和终态都是伪状态，即只有名字。从初态实际上，初态和终态都是伪状态，即只有名字。从初态 转移到正常状态可以给出一些特征，例如监护条件和动作。转移到正常状态可以给出一些特征，例如监护条件和动作。状态的规约状态的规约：-名字名字是一个标识状态的文本串，作为状态名。也可以有匿名状态是一个标识状态的文本串，作为状态名。也可以有匿名状态没有给出状态名没有给出状态名-进入进入/退出之效应退出之效应(effect)是进入或退出该状态时所执行的动作。是进入或退出该状态时所执行的动作。为了表达进入为了表达进入/退出之效应，退出之效应，UML给出给出2个专用的动作标号：个专用的动作标号：entry该标号标识在进入该状态时所要执行的、由相应动该标号标识在进入该状态时所要执行的、由相应动作表达式所规定的动作，简称进入动作。作表达式所规定的动作，简称进入动作。exit该标号标识在退出该状态时所要执行的、由相应动作该标号标识在退出该状态时所要执行的、由相应动作表达式所规定的动作，简称退出动作。表达式所规定的动作，简称退出动作。一般情况下，进入退出之效应不能有参数或监护条件，一般情况下，进入退出之效应不能有参数或监护条件，但位于类状态机顶层的进入效应可以具有参数，以表示在创建但位于类状态机顶层的进入效应可以具有参数，以表示在创建一个对象状态机时所要接受的参数。一个对象状态机时所要接受的参数。-状态内部转移状态内部转移是指没有导致该状态改变的内部转移。一般情况下，在此是指没有导致该状态改变的内部转移。一般情况下，在此给出对象在这个状态中所要执行的内部动作或活动列表。其中给出对象在这个状态中所要执行的内部动作或活动列表。其中表达动作的一般格式为：表达动作的一般格式为：动作标号动作标号/动作表达式动作表达式其中，动作标号标识了在该环境下所要调用的动作，而该动其中，动作标号标识了在该环境下所要调用的动作，而该动作是通过作是通过/之后的动作表达式所规约，其中可以使用对象范之后的动作表达式所规约，其中可以使用对象范围内的任何属性和链。若该表达式为空，则可省略斜线分隔符。围内的任何属性和链。若该表达式为空，则可省略斜线分隔符。为了表达状态内转换中的动作或活动，为了表达状态内转换中的动作或活动，UML给出了一个专用给出了一个专用的动作标号：的动作标号：do，该标号标识正在进行由其相应动作表达式所，该标号标识正在进行由其相应动作表达式所规定的活动，并且只要对象在一个状态中没有完成由该动作表规定的活动，并且只要对象在一个状态中没有完成由该动作表达式所指定的活动，就一直执行之；当动作表达式指定的活动达式所指定的活动，就一直执行之；当动作表达式指定的活动完成时，可能会产生一个完成事件。完成时，可能会产生一个完成事件。注：动作标号注：动作标号“entry”、“exit”和和“do”均不能作为事件名。均不能作为事件名。在以上的叙述中，使用了两个词：在以上的叙述中，使用了两个词：动作动作（action）和）和活动活动(activity)一个活动是指状态机中一种可中断的计算，中断处理后仍一个活动是指状态机中一种可中断的计算，中断处理后仍可继续；可继续；而一个动作是指不可中断的原子计算，它可导致状态的改而一个动作是指不可中断的原子计算，它可导致状态的改变或导致一个值的返回。变或导致一个值的返回。可见，一个活动往往是有多个动作组成的。可见，一个活动往往是有多个动作组成的。-子状态子状态如果在一个状态机中引入另一个状态机，那么被引入的状态机如果在一个状态机中引入另一个状态机，那么被引入的状态机称为子状态机。子状态是被嵌套在另一状态中的状态。相对地，称为子状态机。子状态是被嵌套在另一状态中的状态。相对地，把没有子状态的状态称为简单状态；而把含子状态的状态称为组把没有子状态的状态称为简单状态；而把含子状态的状态称为组合状态。合状态。子状态机分类子状态机分类:顺序子状态顺序子状态机机（非正交）（非正交）和并发子状态和并发子状态机机（正交）（正交）非正交子状态机非正交子状态机注意注意:右边是一个组合右边是一个组合状态，包含一些子状态，状态，包含一些子状态，表达了一个非正表达了一个非正交状态机。一个非正交状态机。一个非正交状态机最多有一个交状态机最多有一个子初态和一个子终态。子初态和一个子终态。关于转入问题关于转入问题:从组合状态之外的一个源状态（如上图中的从组合状态之外的一个源状态（如上图中的“Idle”），），-可以转移到该组合状态，作为其目标状态；可以转移到该组合状态，作为其目标状态；-可以转移到组合状态中一个子状态，作为其目标状态。可以转移到组合状态中一个子状态，作为其目标状态。在第一种情况里，这个被嵌套的子状态机一定有一个初态，在第一种情况里，这个被嵌套的子状态机一定有一个初态，以便在进入该组合状态并执行其进入动作后，将控制传送给这以便在进入该组合状态并执行其进入动作后，将控制传送给这一初态。一初态。在第二种情况里，在执行完该组合状态的进入动作（如有的在第二种情况里，在执行完该组合状态的进入动作（如有的话）和该子状态的进入动作后，将控制传送给这一子状态。话）和该子状态的进入动作后，将控制传送给这一子状态。关于离开问题关于离开问题:离开一个组合状态的转移，其源可以是该组合状态，也可以离开一个组合状态的转移，其源可以是该组合状态，也可以是该组合状态中的一个子状态。无论哪种情况，控制都是首先是该组合状态中的一个子状态。无论哪种情况，控制都是首先离开被嵌套的状态，即执行被嵌套状态的退出动作（如有的话）离开被嵌套的状态，即执行被嵌套状态的退出动作（如有的话），然后离开该组合状态，即执行该组合状态的退出动作（如有，然后离开该组合状态，即执行该组合状态的退出动作（如有的话）。因此，如果一个转移，其源是一个组合状态，那么该的话）。因此，如果一个转移，其源是一个组合状态，那么该转移的本质是终止被嵌套状态机的活动。当控制到达该组合状转移的本质是终止被嵌套状态机的活动。当控制到达该组合状态的子终态时，就触发一个活动完成的转移。态的子终态时，就触发一个活动完成的转移。对于一个包含非正交子状态机的组合状态而言，有时需要对于一个包含非正交子状态机的组合状态而言，有时需要知道在转移出该组合状态之前所执行的那个活动所在的子状态，知道在转移出该组合状态之前所执行的那个活动所在的子状态，为此为此UML引入了一个概念引入了一个概念-浅历史状态，用于指明这样的子状浅历史状态，用于指明这样的子状态，并用来表示之。如下图所示。态，并用来表示之。如下图所示。相对于相对于H所表示的浅历史，可用所表示的浅历史，可用H*来表示深历史，来表示深历史，即在任何深度上表示最深的、被嵌套的状态。即在任何深度上表示最深的、被嵌套的状态。正交子状态机正交子状态机正交子状态机是组合状态中一些并发执行的子状态。如下所正交子状态机是组合状态中一些并发执行的子状态。如下所示：示：其中，使用虚线段形成了两个正交区域（根据需要，可形其中，使用虚线段形成了两个正交区域（根据需要，可形成多个正交区域），分别以成多个正交区域），分别以“Testing”和和“Commanding”标记之，并且每个区域均有自己的初态和标记之，并且每个区域均有自己的初态和终态。终态。关于转入问题关于转入问题:分岔分岔当一个转移到达具有多个正交区域的组合状态时，控制就被当一个转移到达具有多个正交区域的组合状态时，控制就被分成多个并发流分成多个并发流-分岔。分岔。正交区域的执行是并行的，相当于存在两个被嵌套的状态机。正交区域的执行是并行的，相当于存在两个被嵌套的状态机。关于离开问题关于离开问题:汇合汇合-如果一个正交区域先于另一个到达它的终态时，那么该区如果一个正交区域先于另一个到达它的终态时，那么该区域的控制将在该终态等待，直到另一个区域的控制达到自己的域的控制将在该终态等待，直到另一个区域的控制达到自己的终态时，两个区域的控制才汇合成一个控制流终态时，两个区域的控制才汇合成一个控制流-汇合。汇合。-当一个转移离开这样的组合状态时，控制就汇成一个控制流。当一个转移离开这样的组合状态时，控制就汇成一个控制流。-如果所有正交区域均达到它们的终态，或存在一个指示离开如果所有正交区域均达到它们的终态，或存在一个指示离开组合状态的转移，那么就汇成一个流。组合状态的转移，那么就汇成一个流。-被延迟事件被延迟事件被延迟事件是那些在一个状态中不予处理的事件列表。往往被延迟事件是那些在一个状态中不予处理的事件列表。往往需要一个队列机制，对这样的事件予以推迟并予排队，以便在需要一个队列机制，对这样的事件予以推迟并予排队，以便在该对象的另一状态中予以处理。该对象的另一状态中予以处理。小结小结:状态的规约状态的规约,涉及涉及:命名命名进入进入/退出之效应退出之效应;状态内部转移状态内部转移子状态与组合状态子状态与组合状态;被延迟事件被延迟事件.下面介绍状态图中第二个基本元素下面介绍状态图中第二个基本元素-事件。事件。事件事件一个事件是对一个有意义的发生的规约，该发生有其自己一个事件是对一个有意义的发生的规约，该发生有其自己的时空。在状态机的语境下，一个事件是一个激励的时空。在状态机的语境下，一个事件是一个激励（stimulus），可引发状态的转换。），可引发状态的转换。事件的种类：事件的种类：内部事件内部事件：是在系统内对象之间传送的事件。例如，溢出：是在系统内对象之间传送的事件。例如，溢出异常。异常。外部事件外部事件：是在系统和它的参与者之间传送的事件。例如：是在系统和它的参与者之间传送的事件。例如按下一个按钮，一个来自传感器的中断。按下一个按钮，一个来自传感器的中断。在在UMLUML中，可模型化中，可模型化4 4种事件：种事件： 信号（信号（signalsignal） 信号是消息的一个类目，是消息类型。信号是消息的一个类目，是消息类型。 像类一样，信号有属性和操作，信号之间可以有泛化。像类一样，信号有属性和操作，信号之间可以有泛化。 在在UMLUML中，可将信号模型化为衍型类中，可将信号模型化为衍型类, ,例如例如: : 并并可可用用依依赖赖衍衍型型来来表表示示一一个个操操作作发发送送了了一一个个特特定定的信号。的信号。Collisionforce:Float在在UMLUML中中，可可以以通通过过在在类类的的附附加加栏栏中中对对信信号号命命名名来来为为对对象象可可能接受的、有名的信号进行模型化。能接受的、有名的信号进行模型化。 调用（调用（callcall） 一个调用事件表示对象接受到一个操作调用的请求。一个调用事件表示对象接受到一个操作调用的请求。 几点说明：几点说明： 可以使用在类的定义中的操作定义来规约调用事件可以使用在类的定义中的操作定义来规约调用事件 该事件或触发状态机中的一个状态转换，或调用目标对该事件或触发状态机中的一个状态转换，或调用目标对象的一个方法。象的一个方法。 “信信号号”是是一一种种异异步步事事件件，而而“调调用用”一一般般是是同同步步事事件，但可以把件，但可以把“调用调用”规约为异步调用。规约为异步调用。通常信号由状态机处理，而调用事件由一个方法通常信号由状态机处理，而调用事件由一个方法来处理。来处理。 在在UML中，将一个对象可能接受的调用事件模型化为中，将一个对象可能接受的调用事件模型化为该对象类的一个操作。该对象类的一个操作。 时间事件和变化事件时间事件和变化事件 时间事件时间事件是表示推移一段时间的事件。是表示推移一段时间的事件。时时间间表表达达式式可可以以是是复复杂杂的的，也也可可以以是是简简单单的的，例例如如：after 2 seconds,at(1 jan 2007,12.00).after 2 seconds,at(1 jan 2007,12.00). 变化事件变化事件是表示一个条件得到满足或表示状态的一个变化。是表示一个条件得到满足或表示状态的一个变化。 发送事件和接受事件发送事件和接受事件发发送送事事件件是是表表示示类类的的一一个个实实例例发发送送一一个个调调用用事事件件或或信信号号事事件件。接接受受事事件件是是表表示示类类的的一一个个实实例例接接受受一一个个调调用用事事件件或或信信号号事事件。件。 如如果果是是一一个个同同步步调调用用事事件件，那那么么发发送送者者和和接接受受者者都都处处在在该该操操作作执执行行期期间间的的一一个个汇汇聚聚点点上上，即即发发送送者者的的控控制制流流一一直直被被挂挂起起，直到该操作执行完成。直到该操作执行完成。 如如果果是是一一个个信信号号事事件件，那那么么发发送送者者和和接接受受者者并并不不汇汇合合，即即发发送者发送出信号后并不等待接受者的响应。送者发送出信号后并不等待接受者的响应。 在在以以上上两两种种情情况况下下，事事件件可可能能被被丢丢失失（如如果果没没有有定定义义对对该该事事件件的的响响应应的的话话），事事件件的的丢丢失失可可能能触触发发接接受受者者的的状状态态机机（如如果果有的话）或引起一个常规的方法调用。有的话）或引起一个常规的方法调用。 状态转换状态转换定义定义:一个状态转换是两个状态间的一种关系，指明：在第一一个状态转换是两个状态间的一种关系，指明：在第一个状态中的一个对象将执行一些确定的动作，当规约的事件发个状态中的一个对象将执行一些确定的动作，当规约的事件发生并规约的条件满足时，进入第二个状态。生并规约的条件满足时，进入第二个状态。状态转换的规约状态转换的规约:一般涉及以下一般涉及以下5个部分：个部分：源状态：引发该状态转换的那个状态。源状态：引发该状态转换的那个状态。转换触发器：在源状态中由对象识别的事件，并且一旦满足转换触发器：在源状态中由对象识别的事件，并且一旦满足其监护条件，则使状态发生转换。其中其监护条件，则使状态发生转换。其中,在同一个简单状态图中，在同一个简单状态图中，如果触发了多个转换，如果触发了多个转换，“点火点火”的是那个优先级最高的转换；的是那个优先级最高的转换；如果这多个转换具有相同的优先级，那么就随机地选择并如果这多个转换具有相同的优先级，那么就随机地选择并“点点火火”一个转换。一个转换。 监护（监护（guard）条件：一个布尔表达式，当某个转换触发器接）条件：一个布尔表达式，当某个转换触发器接受一个事件时，如果该表达式有值为真，则触发一个转换；若受一个事件时，如果该表达式有值为真，则触发一个转换；若有值为假，则不发生状态转换，并且此时如果没有其它可以被有值为假，则不发生状态转换，并且此时如果没有其它可以被触发的转换，那么该事件就要丢失。触发的转换，那么该事件就要丢失。效应（效应（effect）：一种可执行的行为。例如可作用于对象上）：一种可执行的行为。例如可作用于对象上的一个动作，或间接地作用于其他对象的动作，但这些对象对的一个动作，或间接地作用于其他对象的动作，但这些对象对那个对象是可见的。那个对象是可见的。目标状态：转换完成后所处的那个状态。目标状态：转换完成后所处的那个状态。表达及其格式表达及其格式:在在UML中，把状态转换表示为从源状态出发、并在目标状态中，把状态转换表示为从源状态出发、并在目标状态上终止的带箭头的实线。转换可以予以标记，其格式为：上终止的带箭头的实线。转换可以予以标记，其格式为：转换触发器转换触发器监护条件监护条件/动作表达式动作表达式其中：其中： 转换触发器：描述带参数的事件。其格式为：转换触发器：描述带参数的事件。其格式为：事件名事件名(由逗号分隔的参数表由逗号分隔的参数表) 监护条件：通常是一个布尔表达式，其中可以使用事件参数，监护条件：通常是一个布尔表达式，其中可以使用事件参数，也可以使用具有这个状态机的对象之属性和链，甚至可在监护也可以使用具有这个状态机的对象之属性和链，甚至可在监护条件处直接指定对象可达的某个状态，例如：条件处直接指定对象可达的某个状态，例如：“inState1”或或“notinState2”。 动作表达式：给出触发转换时所执行的动作，其中可以使动作表达式：给出触发转换时所执行的动作，其中可以使用对象属性、操作和链以及触发事件的参数，或在其范围内的用对象属性、操作和链以及触发事件的参数，或在其范围内的其它特征。其它特征。动作表达式可以是由一些有区别的、产生事件的动作所组成动作表达式可以是由一些有区别的、产生事件的动作所组成的动作序列，如发送信号或调用操作。动作表达式的细节与为的动作序列，如发送信号或调用操作。动作表达式的细节与为模型所选择的动作语言有关。模型所选择的动作语言有关。在在UML中，其状态图是基于中，其状态图是基于DavidHarel提出的表示状态机提出的表示状态机的符号。但由于的符号。但由于UML中的概念更侧重于面向对象系统，因此中的概念更侧重于面向对象系统，因此其形式化程度不如其形式化程度不如Harel的符号，且一些细节也有所不同。的符号，且一些细节也有所不同。状态图的一般用法状态图的一般用法建立一个系统动态方面的模型，这些动态方面包括任意种建立一个系统动态方面的模型，这些动态方面包括任意种类对象、任意系统结构（类、接口、构件和节点）视觉下以类对象、任意系统结构（类、接口、构件和节点）视觉下以事件定序的行为。事件定序的行为。建立一个场景的模型，其主要途径是针对建立一个场景的模型，其主要途径是针对use caseuse case给出相给出相应的状态图。应的状态图。其中，不论是其中，不论是还是还是，通常都是对反应型对象（，通常都是对反应型对象（reactive reactive objectobject）的行为进行建模。）的行为进行建模。 反应型对象，或称为事件驱动的对象，其行为特征是响反应型对象，或称为事件驱动的对象，其行为特征是响应其外部语境中所出现的事件，并作出相应的反应。应其外部语境中所出现的事件，并作出相应的反应。反应型对象一般开始处于休眠状态（反应型对象一般开始处于休眠状态（idleidle），直到接受一），直到接受一个事件或称为事件驱动的对象，其行为特征是响应其外部语个事件或称为事件驱动的对象，其行为特征是响应其外部语境中所出现的事件，处理完后又处于休眠状态，等待下一个境中所出现的事件，处理完后又处于休眠状态，等待下一个事件。事件。 对于这一类对象，应关注它的对于这一类对象，应关注它的那些那些“稳定稳定”的状态的状态，关注那些触发状态转换的关注那些触发状态转换的事件事件以及有关状态转换的以及有关状态转换的 动作动作。为反应型对象建立一个状态机模型时，其步骤为：为反应型对象建立一个状态机模型时，其步骤为： 选择状态机的语境，即是类、是用况或是整个系统。选择状态机的语境，即是类、是用况或是整个系统。 选择其实例（例如类的对象）的初始状态和最终状态选择其实例（例如类的对象）的初始状态和最终状态,并分并分别给出初始状态和最终状态的前置条件和后置条件，以便指别给出初始状态和最终状态的前置条件和后置条件，以便指导以后的建模工作。导以后的建模工作。 标识某一可用的时间段，考虑该实例在此期间内存在的条标识某一可用的时间段，考虑该实例在此期间内存在的条件，以此判断该实例的其它状态。对此应以该实例的高层状件，以此判断该实例的其它状态。对此应以该实例的高层状态开始，继之再考虑这些状态的可能的子状态。态开始，继之再考虑这些状态的可能的子状态。 判断该实例在整个生存周期内所有状态的有意义的偏序。判断该实例在整个生存周期内所有状态的有意义的偏序。 判断可以触发状态转换的事件。可以逐一从一个合理定序判断可以触发状态转换的事件。可以逐一从一个合理定序的状态到另一个状态，来模型化其中的事件。的状态到另一个状态，来模型化其中的事件。 为这些状态转移填加动作（作为一个为这些状态转移填加动作（作为一个Mealy机），或为这机），或为这些状态填加动作（作为一个些状态填加动作（作为一个Moore机）。机）。 使用子状态、分支、合并和历史状态等，考虑简化状态机使用子状态、分支、合并和历史状态等，考虑简化状态机的方法。的方法。 检查在某一组合事件下所有状态的可达性。检查在某一组合事件下所有状态的可达性。 检查是否存在死状态，即不存在任何组合事件可以使该实检查是否存在死状态，即不存在任何组合事件可以使该实例从这一状态转换到任一其它状态。例从这一状态转换到任一其它状态。 跟踪整个状态机，检查是否符合所期望的事件次序和响应。跟踪整个状态机，检查是否符合所期望的事件次序和响应。应用实例：创建一个控制器状态机的状态图，其中该控制应用实例：创建一个控制器状态机的状态图，其中该控制器负责对一些传感器进行监视。器负责对一些传感器进行监视。当创建这种控制器的一个对象时，由于要做一些初始化工当创建这种控制器的一个对象时，由于要做一些初始化工作，因此该对象首先进入作，因此该对象首先进入“初始化初始化”（intializing）状态；）状态；一旦完成初始化活动后，则自然进入一旦完成初始化活动后，则自然进入“休眠休眠”（Idle）状）状态；态；在休眠状态中，按一定时间间隔，接受传感器的在休眠状态中，按一定时间间隔，接受传感器的alarm事事件件(具有参数具有参数S，表示相关的传感器，表示相关的传感器)，一旦当接收到一个，一旦当接收到一个alarm事件，或接受到用户发送的事件，或接受到用户发送的attention信号，控制就从休眠状信号，控制就从休眠状态转移到态转移到“活化活化”（Active）状态，或转移到）状态，或转移到“命令命令”（Command）状态；）状态；在活化状态中，仅当发生在活化状态中，仅当发生clearing事件或需要发送事件或需要发送attention信号时，分别进入休眠状态或命令状态。信号时，分别进入休眠状态或命令状态。在嵌入式系统中，以上是一种常见的控制行为，其状态图如在嵌入式系统中，以上是一种常见的控制行为，其状态图如下所示：下所示：其中其中:在该状态图的休眠状态上，有一个由时间事件触发的自在该状态图的休眠状态上，有一个由时间事件触发的自转移，意指每隔转移，意指每隔10秒，接受传感器的秒，接受传感器的alarm事件。事件。该状态图没有终止状态，意指该控制器不间断地运行。该状态图没有终止状态，意指该控制器不间断地运行。UML总结：总结：UML的作用的作用对对“自顶向下自顶向下”的建模人员来讲的建模人员来讲： 提供了跨越问题空间到目前提供了跨越问题空间到目前“运行平台运行平台”之间丰富之间丰富的建模元素的建模元素基于给定的术语，可确定不同的抽象层次，基于给定的术语，可确定不同的抽象层次，支支持持“概念建模概念建模”和和“软件建模软件建模”。运运行平行平台台问题空间问题空间注：注：UMLUML提供的术语提供的术语 -体现了软件设计的体现了软件设计的不同原理不同原理ActorActorUse caseUse case关联关联 泛化泛化USE CASEUSE CASE图图分析类分析类 分析包分析包 Use caseUse case细化细化类图，交互图，类图，交互图，活动图，状态机图等活动图，状态机图等提供了相应的模型表示工具。提供了相应的模型表示工具。例如：例如：即紧紧围绕即紧紧围绕“面向对象方法是一种以对象和对象关系来创面向对象方法是一种以对象和对象关系来创建系统模型的系统化软件开发方法学建系统模型的系统化软件开发方法学”，给出表达，给出表达“对象对象”、“对象关系对象关系”的术语，并给出了表达模型的工具，其的术语，并给出了表达模型的工具，其主要目的是：支持软件开发人员从不同目的（静态、动态）主要目的是：支持软件开发人员从不同目的（静态、动态）、针对不同粒度（系统、子系统、类目等），从不同抽象、针对不同粒度（系统、子系统、类目等），从不同抽象层和从不同视角来创建模型，并建立相应的文档。层和从不同视角来创建模型，并建立相应的文档。具体地说：具体地说：为了支持抽象系统分析和设计中的事物，为了支持抽象系统分析和设计中的事物，UML给出了给出了8个基本个基本术语，即：类、接口、协作、用况、主动类、构件、制品、结术语，即：类、接口、协作、用况、主动类、构件、制品、结点，并给出了这些基本术语的一些变体。点，并给出了这些基本术语的一些变体。每个术语都体现着一定的软件设计原理，例如类体现了数每个术语都体现着一定的软件设计原理，例如类体现了数据抽象、过程抽象、局部化以及信息隐蔽等原理；用况体现了据抽象、过程抽象、局部化以及信息隐蔽等原理；用况体现了问题分离、功能抽象等原理；接口体现了功能抽象等。当使用问题分离、功能抽象等原理；接口体现了功能抽象等。当使用这些术语创建系统模型时，其语义就映射到相应的模型元素。这些术语创建系统模型时，其语义就映射到相应的模型元素。为了表达模型元素之间的关系，为了表达模型元素之间的关系，UML给出了给出了4个术语个术语,即：关联、即：关联、泛化、细化和依赖，以及它们的一些变体。可以作为泛化、细化和依赖，以及它们的一些变体。可以作为UML模型模型中的元素中的元素,用于表达各种事物之间的基本关系。用于表达各种事物之间的基本关系。这些术语都体现了结构抽象原理，特别是泛化概念的使用，这些术语都体现了结构抽象原理，特别是泛化概念的使用，可以有效地进行可以有效地进行“一般一般/特殊特殊”结构的抽象，支持设计的复用。结构的抽象，支持设计的复用。并且为了进一步描述这些模型元素的语义，还给出一些特定的并且为了进一步描述这些模型元素的语义，还给出一些特定的概念和表示，例如给出限定符这一概念，是为了增强关联的语概念和表示，例如给出限定符这一概念，是为了增强关联的语义。义。 为了组织以上两类模型元素，为了组织以上两类模型元素，UML给出了包这一术语，在实际给出了包这一术语，在实际应用中，可以把包作为控制信息复杂性的机制。应用中，可以把包作为控制信息复杂性的机制。为了使创建的系统（或系统成分）模型清晰、易懂，为了使创建的系统（或系统成分）模型清晰、易懂，UML给给出了注解这一术语。出了注解这一术语。为了表达概念模型和软件模型，为了表达概念模型和软件模型，UML提供了提供了13种图形化工具，种图形化工具，它们是：类图、对象图、构件图、包图、部署图、组合结构图，它们是：类图、对象图、构件图、包图、部署图、组合结构图，以及以及USECASE图、状态图、顺序图、通讯图、活动图、交互概图、状态图、顺序图、通讯图、活动图、交互概观图，定序图。观图，定序图。前前6个图可用于概念模型和软件模型的静态结构方面；而后个图可用于概念模型和软件模型的静态结构方面；而后7个模型可用于概念模型和软件模型的动态结构方面个模型可用于概念模型和软件模型的动态结构方面.其中其中:类图可用于创建系统的结构模型，表达构成系统各成分之类图可用于创建系统的结构模型，表达构成系统各成分之间的静态关系，给出有关系统（或系统成分）的一些说明性信间的静态关系，给出有关系统（或系统成分）的一些说明性信息；息；usecase图可用于创建有关系统（或系统成分）的功能模图可用于创建有关系统（或系统成分）的功能模型，表达系统（或系统成分）的功能结构，给出有关系统（或型，表达系统（或系统成分）的功能结构，给出有关系统（或系统成分）在功能需求方面的信息；系统成分）在功能需求方面的信息；状态图可用于创建有关系统（或系统成分）的行为生存周状态图可用于创建有关系统（或系统成分）的行为生存周期模型，表达有关系统（或系统成分）的一种动态结构，给出期模型，表达有关系统（或系统成分）的一种动态结构，给出有关系统（或系统成分）在生存期间可有哪些阶段、每一阶段有关系统（或系统成分）在生存期间可有哪些阶段、每一阶段可从事的活动以及对外所呈现的特征等方面的信息；可从事的活动以及对外所呈现的特征等方面的信息；顺序图可用于创建有关系统（或系统成分）的交互模型顺序图可用于创建有关系统（或系统成分）的交互模型,表达有关系统（或系统成分）的一种交互结构，给出有关参与表达有关系统（或系统成分）的一种交互结构，给出有关参与交互的各方、交互方式以及交互内容交互的各方、交互方式以及交互内容.对对“自底向上自底向上”的设计思想交流来讲：的设计思想交流来讲：提供了表达系统结构模型和行为模型的图形化工具提供了表达系统结构模型和行为模型的图形化工具（14个）个）图行为图结构图类图对象图构件图包图部署图组合结构图USECASE图活动图状态图交互图顺序图通信图交互概观图定时图注：需要进一步需要阅读的内容：注：需要进一步需要阅读的内容：1）“公共机制公共机制”2）对象图，构件图，包图，部署图，组合结构图；）对象图，构件图，包图，部署图，组合结构图；（注：除对象图外，它们都是软件设计中的产物。）（注：除对象图外，它们都是软件设计中的产物。）USECASE图，活动图，通讯图，交互概观图，定序图。图，活动图，通讯图，交互概观图，定序图。UML与与RUPActorActorUse caseUse case关联关联 泛化泛化USE CASEUSE CASE图模型图模型分析类分析类 分析包分析包 Use caseUse case细化细化分析模型分析模型设计模型设计模型部署模型部署模型RUP3统一软件过程统一软件过程(RUP)1)概述概述(1)UML是一种可视化的建模语言，而不是一种特定的软是一种可视化的建模语言，而不是一种特定的软件开发方法学。作为一种软件开发方法学，为了支持软件开发方法学。作为一种软件开发方法学，为了支持软件开发活动，例如软件设计，至少涉及三方面的内容：件开发活动，例如软件设计，至少涉及三方面的内容：一是应定义设计抽象层，即给出该层的一些术语，二是一是应定义设计抽象层，即给出该层的一些术语，二是应给出该层的模型表达工具，三是应给出如何把需求层应给出该层的模型表达工具，三是应给出如何把需求层的模型映射为设计层的模型，即过程。的模型映射为设计层的模型，即过程。UML仅包括前两仅包括前两方面的内容，即给出了一些可用于定义软件开发各抽象方面的内容，即给出了一些可用于定义软件开发各抽象层的术语（符号），给出了各层表达模型的工具。层的术语（符号），给出了各层表达模型的工具。(2)RUP的本质及特点的本质及特点本质本质:是是“一般的过程框架一般的过程框架”.即即:-为软件开发，进行不同抽象层之间为软件开发，进行不同抽象层之间“映射映射”，安排其开，安排其开发活动的次序，指定任务和需要开发的制品，提供了指导；发活动的次序，指定任务和需要开发的制品，提供了指导；-为对项目中的制品和活动进行监控与度量，提供了相应的为对项目中的制品和活动进行监控与度量，提供了相应的准则。准则。换言之，换言之，RUP比较完整地定义了将用户需求转换成产品所需比较完整地定义了将用户需求转换成产品所需要的活动集，并提供了活动指南以及对产生相关文档的要求。要的活动集，并提供了活动指南以及对产生相关文档的要求。适用于：大多数软件系统的开发，涉及适用于：大多数软件系统的开发，涉及 - -不同应用领域不同应用领域 - -不同类型的组织不同类型的组织 - -不同的技能水平不同的技能水平 - -不同的项目规模不同的项目规模 可见可见, RUP , RUP 和和UML UML 是是“统一统一”的方法学。的方法学。RUP的突出特点的突出特点是一种以用况（是一种以用况（UseCase）为驱动的、以体系结构为中心的、）为驱动的、以体系结构为中心的、迭代、增量式开发。迭代、增量式开发。以用况为驱动以用况为驱动意指在系统的生存周期中，意指在系统的生存周期中，以用况作为基础，驱动有关以用况作为基础，驱动有关人员对所要建立系统之功能人员对所要建立系统之功能需求进行交流，驱动系统分需求进行交流，驱动系统分析、设计、实现和测试等活析、设计、实现和测试等活动，包括制定计划、分配任动，包括制定计划、分配任务、监控执行和进行测试等，务、监控执行和进行测试等，并将它们有机地组合为一体，并将它们有机地组合为一体，使各个阶段中都可以回溯到使各个阶段中都可以回溯到用户的实际需求。用户的实际需求。USECASE分分析析输入输入设设计计实实现现跟踪跟踪输入输入跟踪跟踪输入输入跟踪跟踪输入输入输入输入测测试试输入输入跟踪跟踪输入输入从从USE CASEUSE CASE模型的视觉模型的视觉从分析模型的视觉从分析模型的视觉从设计模型的视觉从设计模型的视觉从实现模型的视觉从实现模型的视觉从部署模型的视觉从部署模型的视觉给给出出体体系系结结构构描描述述以体系结构为中心以体系结构为中心意指在系统的生存周期中，开发的任何阶段（意指在系统的生存周期中，开发的任何阶段（RUP规定了规定了四个阶段，即初始阶段、细化阶段、构造阶段和移交阶段）都四个阶段，即初始阶段、细化阶段、构造阶段和移交阶段）都要给出相关模型视角下的有关体系结构的描述，作为构思、构要给出相关模型视角下的有关体系结构的描述，作为构思、构造、管理和改善系统的主要制品。造、管理和改善系统的主要制品。系统体系结构是对系统语义的概括表述，内含一些决策，主系统体系结构是对系统语义的概括表述，内含一些决策，主要涉及软件系统的组织（包括构成系统的结构元素、各元素的要涉及软件系统的组织（包括构成系统的结构元素、各元素的接口、由元素间的各种协作所描述的各元素行为、由结构元素接口、由元素间的各种协作所描述的各元素行为、由结构元素和行为元素构成的子系统、相关的系统功能和性能、其他约束和行为元素构成的子系统、相关的系统功能和性能、其他约束等）以及支持这种组织的体系结构风格。等）以及支持这种组织的体系结构风格。系统体系结构对所有与项目有关人员来说都是能够理解的，系统体系结构对所有与项目有关人员来说都是能够理解的，因此便于用户和其他关注者对系统达到共识，以便建立和控制因此便于用户和其他关注者对系统达到共识，以便建立和控制系统的开发、复用和演化。系统的开发、复用和演化。因此，在系统体系结构描述中，应关注子系统、构件、接口、因此，在系统体系结构描述中，应关注子系统、构件、接口、协作、关系和节点等重要模型元素，而忽略其他细节。协作、关系和节点等重要模型元素，而忽略其他细节。具体地说，体系结构描述应根据相关模型的视角：具体地说，体系结构描述应根据相关模型的视角：展示对体系结构有意义上的用况、子系统展示对体系结构有意义上的用况、子系统(不涉及子系统不涉及子系统的隐含成分和私有成分，及其变种的隐含成分和私有成分，及其变种)、接口、类、接口、类(主要为主动类主要为主动类)、构件、节点和协作；、构件、节点和协作；展示对系统体系结构有意义的非功能需求，例如性能、展示对系统体系结构有意义的非功能需求，例如性能、安全、分布和并发等；安全、分布和并发等；简述相关的平台、遗产、所用的商业软件、框架和模板简述相关的平台、遗产、所用的商业软件、框架和模板机制等；以及机制等；以及各种体系结构模式。各种体系结构模式。例如，为获得系统用况模型视角下的系统体系结构描述，应：例如，为获得系统用况模型视角下的系统体系结构描述，应：在一般性地了解系统用况之后，勾画与特定用况和平台无关在一般性地了解系统用况之后，勾画与特定用况和平台无关的系统体系结构轮廓。的系统体系结构轮廓。关注一些关键用况。所谓关键用况，是指那些有助于降低最关注一些关键用况。所谓关键用况，是指那些有助于降低最大风险的用况，对系统用户来说是最重要的用况，以及有助于大风险的用况，对系统用户来说是最重要的用况，以及有助于实现所有重要的功能而不遗留任何重大问题的用况。实现所有重要的功能而不遗留任何重大问题的用况。给出每一关键用况的描述。其中应考虑软件需求、中间件、给出每一关键用况的描述。其中应考虑软件需求、中间件、遗产系统和非功能性需求等，以便产生更加成熟的用况和更多遗产系统和非功能性需求等，以便产生更加成熟的用况和更多的系统体系结构成分。的系统体系结构成分。对以上三步进行迭代，得到一个文档化的体系结构基线。并对以上三步进行迭代，得到一个文档化的体系结构基线。并在此基础上，形成一个稳定的系统体系结构描述。在此基础上，形成一个稳定的系统体系结构描述。阶阶段段核心工作流核心工作流迭代、增量式开发迭代、增量式开发意指通过开发活动的迭代，不断地产生相应的增量。在意指通过开发活动的迭代，不断地产生相应的增量。在RUP中，规定了四个开发阶段：初始阶段中，规定了四个开发阶段：初始阶段（theinceptionphase）、精化阶段精化阶段（theelaborationphase）、构造阶段、构造阶段（theconstructionphase）和移交阶段和移交阶段（thetransitionphase）每次迭代都要按照专门的计划和评估标准，通过一组明确的每次迭代都要按照专门的计划和评估标准，通过一组明确的活动，产生一个内部的或外部的发布版本。两次相邻迭代所得活动，产生一个内部的或外部的发布版本。两次相邻迭代所得到的发布版本之差，称为一个增量，因此增量是系统中一个较到的发布版本之差，称为一个增量，因此增量是系统中一个较小的、可管理的部分小的、可管理的部分(一个或几个构造块一个或几个构造块)。贯穿整个生存周期的迭代，形成了项目开发的一些里程碑。贯穿整个生存周期的迭代，形成了项目开发的一些里程碑。-每一阶段的结束，是项目的一个主里程碑（共四个），产生每一阶段的结束，是项目的一个主里程碑（共四个），产生系统的一个体系结构基线，即模型集合所处的当时状态。系统的一个体系结构基线，即模型集合所处的当时状态。-主里程碑是管理者与开发者的同步点，以决定是否继续进行主里程碑是管理者与开发者的同步点，以决定是否继续进行项目，确定项目的进度、预算和需求等。项目，确定项目的进度、预算和需求等。-在四个阶段中的每一次迭代的结束，是一个次里程碑，产生在四个阶段中的每一次迭代的结束，是一个次里程碑，产生一个增量。次里程碑是如何进行后续迭代的决策点。一个增量。次里程碑是如何进行后续迭代的决策点。-系统体系结构基线的建立，是精化阶段的一个目标，期间通系统体系结构基线的建立，是精化阶段的一个目标，期间通过不断演化，到该阶段末得到这一基线，是系统的过不断演化，到该阶段末得到这一基线，是系统的“骨架骨架”.-该基线包括早期版本的用况模型、分析模型、设计模型、部该基线包括早期版本的用况模型、分析模型、设计模型、部署模型、实现模型和测试模型，但此时用况模型和分析模型较署模型、实现模型和测试模型，但此时用况模型和分析模型较为成熟。为成熟。-在实践中，体系结构描述和体系结构基线往往同时开发，以在实践中，体系结构描述和体系结构基线往往同时开发，以便指导整个软件开发的生命周期。期间，体系结构描述不断更便指导整个软件开发的生命周期。期间，体系结构描述不断更新，以便反映体系结构基线的变化。新，以便反映体系结构基线的变化。注注:该基线应该是坚实的，因为它是开发人员当时和将来进行该基线应该是坚实的，因为它是开发人员当时和将来进行开发时所要遵循的标准开发时所要遵循的标准;并应与最终系统并应与最终系统(对客户发布的产品对客户发布的产品)几乎具有同样的骨架。但最后形成的体系结构基线是系统各几乎具有同样的骨架。但最后形成的体系结构基线是系统各种模型和各模型视角下体系结构描述的一个集合。种模型和各模型视角下体系结构描述的一个集合。综上可知，综上可知，RUP的迭代增量式开发，是演化模型的一个变体，的迭代增量式开发，是演化模型的一个变体，即规定了即规定了“大大”的迭代数目的迭代数目-四阶段，并规定了每次迭代的目标。四阶段，并规定了每次迭代的目标。初始阶段的基本目标初始阶段的基本目标是：是：获得与特定用况和平台无关的系统体系结构轮廓，以此获得与特定用况和平台无关的系统体系结构轮廓，以此建立产品功能范围；建立产品功能范围；编制初始的业务实例，从业务角度指出该项目的价值，减编制初始的业务实例，从业务角度指出该项目的价值，减少项目主要的错误风险。少项目主要的错误风险。简言之，其目标是：建立该项目的生存周期目标简言之，其目标是：建立该项目的生存周期目标（objectives）精化阶段的基本目标精化阶段的基本目标是：是：通过捕获并描述系统的大部分需求（一些关键用况），建立通过捕获并描述系统的大部分需求（一些关键用况），建立系统体系结构基线的第一个版本，主要包括用况模型和分析模系统体系结构基线的第一个版本，主要包括用况模型和分析模型，减少次要的错误风险型，减少次要的错误风险.从而到该阶段末，就能够估算成本、从而到该阶段末，就能够估算成本、进度，并能详细地规划构造阶段。进度，并能详细地规划构造阶段。构造阶段的基本目标构造阶段的基本目标是：是：通过演化，形成最终的系统体系结构基线（包括系统的各通过演化，形成最终的系统体系结构基线（包括系统的各种模型和各模型视角下体系结构描述）种模型和各模型视角下体系结构描述）;开发了完整的系统，确保产品可以开始向客户交付开发了完整的系统，确保产品可以开始向客户交付,即具即具有初始操作能力。有初始操作能力。交付阶段的基本目标交付阶段的基本目标是：确保有一个实在的产品，发布给用户是：确保有一个实在的产品，发布给用户群。期间，培训用户如何使用该软件。群。期间，培训用户如何使用该软件。需求需求设计设计编码编码测试测试集成集成需求需求设计设计编码编码测试测试集成集成开开发发反反馈馈开开发发反反馈馈.核核心心系系统统开开发发第第二二次次迭迭代代注：这注：这4个阶段是演化模型的一个变体。个阶段是演化模型的一个变体。演化模型（演化模型（Evolutionary modelEvolutionary model）-一种迭代风范一种迭代风范是是一一种种有有弹弹性性的的过过程程模模式式，由由一一些些小小的的开开发发步步组组成成，每每一一步步历历经经需需求求分分析析、设设计计、实实现现和和验验证证，产产生生软软件件产产品品的的一一个个增增量量。通过这些迭代，完成最终软件产品的开发。通过这些迭代，完成最终软件产品的开发。 针对事先不能完整地定义需求针对事先不能完整地定义需求 针对用户的核心需求针对用户的核心需求, ,开发核心系统开发核心系统 根据用户的反馈根据用户的反馈, ,实施活动的迭代实施活动的迭代演化模型还具有以下优点：演化模型还具有以下优点： 在需求不能予以规约时，可以使用这一演化模型。在需求不能予以规约时，可以使用这一演化模型。 用户可以通过运行系统的实践，对需求进行改进。用户可以通过运行系统的实践，对需求进行改进。 与瀑布模型相比，需要更多用户与瀑布模型相比，需要更多用户/ /获取方的参与。获取方的参与。 缺点有：缺点有： 演化模型的使用演化模型的使用, ,需要有力的管理。需要有力的管理。 演化模型的使用很容易成为不编写需求或设计文档的借口，演化模型的使用很容易成为不编写需求或设计文档的借口， 即使很好地理解了需求或设计。即使很好地理解了需求或设计。 用户用户/ /获取方不易理解演化模型的自然属性，因此当结果不获取方不易理解演化模型的自然属性，因此当结果不 够理想时，可能产生抱怨。够理想时，可能产生抱怨。2)需求获取的目标及其基本途径需求获取的目标及其基本途径需求获取面临的挑战需求获取面临的挑战 问题空间理解问题空间理解 人与人之间的交流人与人之间的交流 需求的不断变化需求的不断变化 需求获取技术特征需求获取技术特征 方便通讯（使用易于理解的语言）方便通讯（使用易于理解的语言） 提供定义系统边界的方法提供定义系统边界的方法 提供划分、抽象、投影等方法提供划分、抽象、投影等方法 允许采用多种可供选择的设计方法允许采用多种可供选择的设计方法 适应需求的变化适应需求的变化 支持使用问题空间的术语，思考问题和编制文档支持使用问题空间的术语，思考问题和编制文档 (1)需求获取的目标需求获取的目标对大系统的开发来说，需求一般包括需求获取和需求分析对大系统的开发来说，需求一般包括需求获取和需求分析 需求获取的目标是：需求获取的目标是：客观问题（系统）客观问题（系统）系统需求获取模型形成形成-涉及：不同概念和不同处理逻辑涉及：不同概念和不同处理逻辑体系结构描述-USECASE模型(2) (2) 实现实现需求获取目标的基本途径需求获取目标的基本途径 实现实现实际问题到软件开发需求获取层的映射，即从软实际问题到软件开发需求获取层的映射，即从软件开发的角度件开发的角度- -实现第一次抽象。实现第一次抽象。 其中至少涉及以下其中至少涉及以下3 3个问题：个问题： 如何定义需求获取层，即给出该层的术语；如何定义需求获取层，即给出该层的术语； 如何确定模型表示工具；如何确定模型表示工具； 如何映射。如何映射。实际问题实际问题需求获取层需求获取层模型表示模型表示工具工具 需求获取层的术语（概念）及表达模型的工具需求获取层的术语（概念）及表达模型的工具 术语术语: : USE CASEUSE CASE actor actor 以及以及 4 4个表达关系的概念：关联、包含、扩展、泛化个表达关系的概念：关联、包含、扩展、泛化 工具工具:USE CASE:USE CASE图图实际问题实际问题模型表示工具-USECASE图图体系结构描述-USECASE模型如何映射如何映射-需求工作流需求工作流总体来说，需求工作流包括以下四步，但它们并非是严格总体来说，需求工作流包括以下四步，但它们并非是严格分离的。分离的。要做的工作要做的工作 产生的制品产生的制品-列出候选的需求列出候选的需求特征（特征（Feature）列表）列表-理解系统语境理解系统语境领域模型或业务模型领域模型或业务模型-捕获功能需求捕获功能需求Usecase模型模型-捕获非功能需求捕获非功能需求补充需求或针对一些特定需求补充需求或针对一些特定需求的的usecases其中其中:特征（特征（Feature）列表）列表特征特征: :一个新的项一个新的项（ item item ）及相关的简要描述及相关的简要描述（shrinksshrinks） ，称为特征（称为特征（ featurefeature）。）。应用系统应用系统潜在的抽象层潜在的抽象层例如：例如：按学科计算每一学生的期末考试平均成绩。按学科计算每一学生的期末考试平均成绩。 统计统计2 2科以上不及格的人数。科以上不及格的人数。 给出各分段给出各分段（0-600-60，60-8560-85，85-10085-100）的人数分布情况。的人数分布情况。feature特征作为需求特征作为需求, , 被转换为其它制品被转换为其它制品: :应用系统应用系统潜在的抽象层潜在的抽象层（特征层）（特征层）一个抽象层一个抽象层（USECASE层）层）USECASE1USECASEUSECASE2USECASE3制品：制品：USE CASEUSE CASE模型模型规约规约规约规约形成形成Actor关联关联关于特征的几点说明：关于特征的几点说明：- -每一特征有一个简短的名字和简要的说明或定义。每一特征有一个简短的名字和简要的说明或定义。 - -每一特征还有一组对规划有意义的信息，可以包括：每一特征还有一组对规划有意义的信息，可以包括： 状态（状态（ StatusStatus），例如），例如 ，提交，批准，确认，提交，批准，确认 是否是组成的等。是否是组成的等。 估算的实现成本。估算的实现成本。( ( 所需的资源类型和人所需的资源类型和人/ /时）。时）。 优先级（优先级（PriorityPriority）( (e.g.,critical, important, or e.g.,critical, important, or ancillary ancillary) )。 实现中相联的风险等级。实现中相联的风险等级。业务模型或领域模型业务模型或领域模型领域模型领域模型作用作用:领域模型捕获了系统语境中的一些重要对象类型。其中领域模型捕获了系统语境中的一些重要对象类型。其中 领域对象表示系统工作环境中存在的事物或发生的事件领域对象表示系统工作环境中存在的事物或发生的事件 一般来说，领域类以三种形态出现一般来说，领域类以三种形态出现：业务对象：表示那些被业务所操纵（业务对象：表示那些被业务所操纵（ manipulatemanipulate）的事）的事 物（物（ thingthing），例如定单，帐目和合同等），例如定单，帐目和合同等 实在对象实在对象（Real-world objectsReal-world objects）和概念：例如飞机，火箭等和概念：例如飞机，火箭等 事件（事件（EventsEvents）：例如飞机到达，飞机起飞等）：例如飞机到达，飞机起飞等 一般来说，领域模型是以类图予以描述的。一般来说，领域模型是以类图予以描述的。OrderdateofsubmissiondeliveryaddressItemdescriptionpicturecostInvoiceamountdateofsubmissionlastdateofpaymentAccountbalanceowner1.*payable1.*buyer1seller1注注:领域模型中的一个类图领域模型中的一个类图, ,捕获了该系统语境中捕获了该系统语境中 的一些重要的概念的一些重要的概念. .例如例如: : 领域类领域类Order,Invoice,Item,andAccount业务模型业务模型业务模型可以分为以下业务模型可以分为以下2个层次：个层次：业务业务usecase模型模型抽象一个特定业务抽象一个特定业务.一般可用一般可用USECASE图来表达图来表达,其中以其中以业业务务usecase来描述该业务的处理（来描述该业务的处理（businessprocesses）,以以业业务务actors来描述与该业务交互的客户（来描述与该业务交互的客户（customers）.例如例如:取款取款银行服务员银行服务员 业务对象业务对象模型模型业务对象模型是一个业务的内部（业务对象模型是一个业务的内部（interior）模型。通）模型。通过一组过一组workers、businessentities、workunits来来细化细化业务业务usecase模型中的每一个模型中的每一个业务业务usecase。其中，其中， Business entity:表示某些事物（表示某些事物（something）,例如例如一张发票一张发票它们在一个它们在一个业务业务usecase中被使用之。中被使用之。 work unit:是这样实体的一个集合，对最终用户而言，形成是这样实体的一个集合，对最终用户而言，形成了可认知的整体。了可认知的整体。workers:使用该使用该业务业务usecase的工作人员的工作人员.注注:Businessentities和和workunit可作为领域类，用于表达可作为领域类，用于表达领域中的概念，例如定单，栏目，发票等。领域中的概念，例如定单，栏目，发票等。一般地一般地,每一个每一个业务业务usecase的细化可以通过交互图和活动的细化可以通过交互图和活动图来表达。图来表达。 Use-Case模型模型 Use-Case Use-Case 模型模型 用以表达客户认可的需求用以表达客户认可的需求- -系统必须系统必须 满足的条件和能力。满足的条件和能力。 Use-CaseUse-Case模型模型 作为客户和开发人员之间的一种共识。作为客户和开发人员之间的一种共识。 Use-Case Use-Case 模型是一个系统的一种模型，包括模型是一个系统的一种模型，包括 actorsactors、 use cases use cases 以及它们之间的关系。以及它们之间的关系。Use-CasesystemUse-CasemodelActorUsecase*1TheUse-Casesystemdenotesthetop-levelpackageofthemodelUse-Case模型以及其内容模型以及其内容参与需求工作流的有关人员参与需求工作流的有关人员SystemAnalysisresponsibleforUse-caseSpecifierresponsibleforUser-interfacedesignerresponsibleforArchitectresponsibleforusecasemodelActorGlossaryUsecaseUserinterfaceprototypeArchitectureDescription 构造系统构造系统USE CASEUSE CASE模型中的活动模型中的活动 活动活动1:1:发现并描述发现并描述ActorActor和和USE CASEUSE CASE 任务任务1:1:发现发现 ActorActor-当存在业务模型时当存在业务模型时,可直接发现一些候选的可直接发现一些候选的actors，即：，即：对于业务中的每一个对于业务中的每一个worker，可以建议一个候选的，可以建议一个候选的actor对于每一个将要使用该信息系统的对于每一个将要使用该信息系统的业务业务actor,即每一个业务客户，即每一个业务客户，可建议一个候选的可建议一个候选的actor。-当有或没有领域模型时当有或没有领域模型时分析人员就要与客户一起标识分析人员就要与客户一起标识actor，并将所标识，并将所标识actor进行分类，进行分类，形成形成一些候选的一些候选的actors。Note:还要标识表示外部系统的还要标识表示外部系统的actoractor和系统维护和运行和系统维护和运行 所需要的所需要的actor actor 。 针对候选的针对候选的actors,可用以下可用以下2条准则来确定最终系统条准则来确定最终系统actors:第一条准则：至少要识别出一个用户，可以扮演候选的第一条准则：至少要识别出一个用户，可以扮演候选的 actoractor。该准则将帮助我们仅发现那些相关的该准则将帮助我们仅发现那些相关的actorsactors，避免，避免 actor actor 仅是一些想象的仅是一些想象的“事物事物”。第二条准则：系统中不同第二条准则：系统中不同actors actors 实例之间，其角色的重叠实例之间，其角色的重叠 应是最少的。应是最少的。其中其中,如果如果2 2个或多个个或多个actorsactors有着几乎相同的角色，那么就有着几乎相同的角色，那么就 应该考虑：应该考虑： 是否将这些角色组合到一个是否将这些角色组合到一个actoractor的角色中，或的角色中，或 是否需要发现另外一个是否需要发现另外一个“一般化一般化”的的actoractor，使之，使之具具 有那些重叠的、公共的角色，并可以通过有那些重叠的、公共的角色，并可以通过“泛化泛化”， 形成那些特定形成那些特定actoractor。任务任务2:Actors2:Actors的命名与描述的命名与描述Actors的命名的命名：对对actorsactors的命名的命名, ,可可“传达传达”（ conveyconvey）所期望的语义）所期望的语义, ,因因 此给出恰当的名字是非常重要的。此给出恰当的名字是非常重要的。Actors的描述的描述：对对actoractor的描述，应包含其角色（责任）以及为了完成其的描述，应包含其角色（责任）以及为了完成其 责任所需要的条件。责任所需要的条件。例如例如:theBuyer, SellerBuyerABuyer representsapersonwhoisresponsibleforbuyinggoodsorservicesasdescribedinthebusinessusecaseSales:fromOrdertoDelivery.Thispersonmaybeanindividualorsomeonewithinabusinessorganization.TheBuyerofgoodsandservicesneedtheBilling and Payment Systemtosendorderandtopayinvoices.SellerA Sellerrepresentsapersonwhosellsanddeliversgoodsorservices.TheSellerusesthesystemtolookfornewordersandtosendorderconfirmations,invoices,andpaymentreminders.对对usecase的理解的理解在在UML中，用况是系统向它的参与者提供结果（值）的功能中，用况是系统向它的参与者提供结果（值）的功能块，表达参与者使用系统的方式，因此一个用况可用于规约系块，表达参与者使用系统的方式，因此一个用况可用于规约系统可执行的、与参与者进行交互的一个动作序列，包括其中的统可执行的、与参与者进行交互的一个动作序列，包括其中的可选动作序列，用况并有其自己的属性。可选动作序列，用况并有其自己的属性。一个用况的实例，其行为表现为：一个用况的实例，其行为表现为：-首先，系统外部的一个参与者实例，直接启动该用况实例首先，系统外部的一个参与者实例，直接启动该用况实例中的一条路径，并使之处于一个开始状态中的一条路径，并使之处于一个开始状态;-继之继之,执行这条路径中的动作序列，使该用况实例从一个状执行这条路径中的动作序列，使该用况实例从一个状态转化为另一状态；其中，在执行该序列的每一动作中，包含态转化为另一状态；其中，在执行该序列的每一动作中，包含内部计算、路径选择和向某一参与者发送消息；内部计算、路径选择和向某一参与者发送消息；任务任务3:3:发现发现Use Case Use Case -在一个新的状态中，等待在一个新的状态中，等待actor发送另一外部消息，以此引发送另一外部消息，以此引发该状态下的动作之执行。发该状态下的动作之执行。-如此继续，经历了许多状态，直到该用况实例被终止。如此继续，经历了许多状态，直到该用况实例被终止。其中其中,由于我们把系统用况模型中的用况实例看作是原子的，由于我们把系统用况模型中的用况实例看作是原子的，因此只存在一类发生在参与者实例和用况实例之间的交互。这因此只存在一类发生在参与者实例和用况实例之间的交互。这意味着用况实例不能与其它用况实例发生交互，但每个用况的意味着用况实例不能与其它用况实例发生交互，但每个用况的行为可以被其它用况所中断。并且在大部分情况里，是一个参行为可以被其它用况所中断。并且在大部分情况里，是一个参与者实例引发一个用况实例，但也有可能由一个事件所引发，与者实例引发一个用况实例，但也有可能由一个事件所引发，例如由系统之外的定时时钟所引发。例如由系统之外的定时时钟所引发。-当已有一个业务模型时，可直接标识一些临时的用况当已有一个业务模型时，可直接标识一些临时的用况,即为其即为其中的一个中的一个“工作人员工作人员”或或“业务参与者业务参与者”的角色，对应地创建的角色，对应地创建一个用况一个用况;继之继之,对这些暂时的用况进行细化和调整，并确定对这些暂时的用况进行细化和调整，并确定工作人员工作人员和和业务参与者业务参与者的哪些任务可由系统自动地予以实现，而后对确定的哪些任务可由系统自动地予以实现，而后对确定的用况进行重新组织，以便更好地适应系统参与者的的要求的用况进行重新组织，以便更好地适应系统参与者的的要求。-当没有业务模型时，就要与客户和当没有业务模型时，就要与客户和/或用户一起来标识用况。或用户一起来标识用况。其中，需要一个一个地审阅参与者其中，需要一个一个地审阅参与者,为每一个参与者建议一些侯为每一个参与者建议一些侯选的用况。例如，研究一个参与者需要哪些用况，为什么需要选的用况。例如，研究一个参与者需要哪些用况，为什么需要这些用况，并研究参与者的创建、改变、跟踪、迁移等工作，这些用况，并研究参与者的创建、改变、跟踪、迁移等工作，通常需要哪些用况来支持之，研究通常需要哪些用况来支持之，研究业务用况业务用况中使用的业务对象，中使用的业务对象，例如定单和帐目等。例如定单和帐目等。不论采用什么方法，在发现候选用况中还需要进一步考虑一不论采用什么方法，在发现候选用况中还需要进一步考虑一些问题，例如：些问题，例如： 参与者是否还可能要通知系统一些外部事件，包括已经发参与者是否还可能要通知系统一些外部事件，包括已经发生的一些事件，例如：发票已经过期。生的一些事件，例如：发票已经过期。 是否还可能存在一些其他的参与者是否还可能存在一些其他的参与者，他们执行系统的启动、，他们执行系统的启动、终止和维护。终止和维护。 是否存在一些侯选的用况，不宜作为系统最终的用况是否存在一些侯选的用况，不宜作为系统最终的用况，而，而应把它们作为其他用况的组成部分。应把它们作为其他用况的组成部分。创建的用况是否可以作为一个功能单元，容易修改、测试创建的用况是否可以作为一个功能单元，容易修改、测试和管理之等。和管理之等。 对用户和系统之间的一个交互序列，是否在一个用况中予对用户和系统之间的一个交互序列，是否在一个用况中予以规约，还是在多个用况中予以规约等。以规约，还是在多个用况中予以规约等。在确定系统最终的用况当中，会涉及一个很难处理的问题，在确定系统最终的用况当中，会涉及一个很难处理的问题，即用况范围大小的确定。其中必须考虑：它是否是完整的即用况范围大小的确定。其中必须考虑：它是否是完整的 （completecomplete），是否是另一用况的继续），是否是另一用况的继续. . 下面给出两条确定用况大小的基本准则：下面给出两条确定用况大小的基本准则：第一条准则：用况应为它的参与者产生有值的结果第一条准则：用况应为它的参与者产生有值的结果(result of value)，特别地，用况应向一个特定的参与者交付了可见的结果特别地，用况应向一个特定的参与者交付了可见的结果（值）（值）.这一准则的目的是为了避免发现的用况太小。这一准则的目的是为了避免发现的用况太小。第二条准则：用况最好只有一个特定的参与者第二条准则：用况最好只有一个特定的参与者(particular actor)。这条准则的目的是为了使所标识的用况都有一个真实用户，从这条准则的目的是为了使所标识的用况都有一个真实用户，从而可以避免发现的而可以避免发现的用况太大。用况太大。注注:基于一些参与者而第一次发现的用况，常常需要予以重基于一些参与者而第一次发现的用况，常常需要予以重新组织，重新评估，使之更加新组织，重新评估，使之更加“稳定稳定”。例如，。例如，假定已经有了一个体系结构描述，那么就要对新捕获的假定已经有了一个体系结构描述，那么就要对新捕获的用况进行必要的调整，以便适应已有的体系结构。用况进行必要的调整，以便适应已有的体系结构。任务任务4:用况的描述用况的描述对用况的描述程度，取决于是在什么时候。一般或在发现时，对用况的描述程度，取决于是在什么时候。一般或在发现时，或在需要精化时（参见或在需要精化时（参见4）任务）任务3）。）。在用况发现时，其描述一般应该：在用况发现时，其描述一般应该：首先给出该首先给出该UAECASE的名字；继之，给出该用况的概要描述。的名字；继之，给出该用况的概要描述。根据需要，概要描述一般可以采用两种形式，一种是简单地给根据需要，概要描述一般可以采用两种形式，一种是简单地给出用况的功能，例如出用况的功能，例如：“PayInvoiceUseCases “The use case Pay Invoice is used by a Buyer to schedule invoice payments. The Pay Invoice use case then effects the payment on the due date.”第二种形式是首先概括其动作，而后一步一步地列出系统与第二种形式是首先概括其动作，而后一步一步地列出系统与其参与者交互时所要做的事情。例如其参与者交互时所要做的事情。例如： “Before this use case can be initiated, the Buyer has already received an invoice (delivered by another use case called Invoice Buyer ) and has also received the goods or services ordered.: 1. The buyer studies the invoice to pay and checks that it is consistent with the original order. 2. The Buyer schedules the invoice for payment by the bank. 3. On the day payment is due, the system checks to see if there is enough money in the Buyers account. If enough money is available, the transaction is made.”通过以上活动通过以上活动1:-形成了系统的粗略用况模型，记为用况模型形成了系统的粗略用况模型，记为用况模型概述概述。-以这一用况模型以这一用况模型概述概述为此基础上，进而可形成系统的一些为此基础上，进而可形成系统的一些非功能需求和相应的应用术语集。非功能需求和相应的应用术语集。活动活动2:2:确定确定use caseuse case的优先级（的优先级（ PriorityPriority） 目标目标 这一活动目标是，在活动这一活动目标是，在活动1）和）和2）的基础上，确定哪些用况）的基础上，确定哪些用况适宜在早期迭代中予以开发，哪些用况适宜在后期迭代中予适宜在早期迭代中予以开发，哪些用况适宜在后期迭代中予以开发，并形成系统用况模型以开发，并形成系统用况模型概述概述视觉下的体系结构描述。视觉下的体系结构描述。输入与输出输入与输出ArchitectUseCasemodeloutlinedSupplementaryRequirementsGlossaryArchitectureDescriptionviewoftheusecasemodelPrioritizedUseCases 实施实施-刻画在体系结构方面具有意义的用况，包括刻画在体系结构方面具有意义的用况，包括: :对某一重要、关键功能的用况的描述对某一重要、关键功能的用况的描述; ;包括对那些必须在软件生存周期早期予以开发的、某一重包括对那些必须在软件生存周期早期予以开发的、某一重 要的用况的描述。要的用况的描述。作用作用 -确定在规划的下一个迭代中，需要哪些开发活动和任务确定在规划的下一个迭代中，需要哪些开发活动和任务; ;-在这一规划中在这一规划中, ,当然还需要考虑其它非技术因素，例如系当然还需要考虑其它非技术因素，例如系 统开发的业务和经济方面的因素。统开发的业务和经济方面的因素。活动活动3:UseCase精化精化目的目的详细地描述事件流，包括详细地描述事件流，包括use caseuse case是怎样开始的，是怎样结束是怎样开始的，是怎样结束的，是怎样与的，是怎样与actors actors 进行交互的。进行交互的。 输入与输出输入与输出UsecaseSpecifierUseCasemodeloutlinedSupplementaryRequirementsGlossaryUseCasedetailedDetailaUseCaseTheresultisadetaileddescriptionofaparticularusecaseintextanddiagram. 精化途径精化途径 涉及涉及: :如何描述一个如何描述一个 use caseuse case中所有可选的路径；中所有可选的路径； 在一个在一个 use caseuse case的描述中包括的内容；的描述中包括的内容； 如何在必要时形式化地给出如何在必要时形式化地给出use caseuse case的描述。的描述。 有效技术有效技术：事件流技术：事件流技术 对用况的精化描述，可以用事件流（对用况的精化描述，可以用事件流（Flow of Flow of EventsEvents）描述技术，规约当一个用况执行时，系统做了）描述技术，规约当一个用况执行时，系统做了什么，以及系统如何与其参与者参与者进行交互。什么，以及系统如何与其参与者参与者进行交互。 一个用况可以被认为有一个开始状态，一些中间状态，一个用况可以被认为有一个开始状态，一些中间状态，并从一个状态转换为另一状态，如下所示：并从一个状态转换为另一状态，如下所示： 其中，红箭头线表示基本路径，曲线是其它可选路径。其中，红箭头线表示基本路径，曲线是其它可选路径。 首先首先，从开始状态到终止状态选择一条完整的基本路径，从开始状态到终止状态选择一条完整的基本路径，并对其进行描述。其中，这一基本路径的选择应该是用户并对其进行描述。其中，这一基本路径的选择应该是用户认为它是一条最通常的、并对相关参与者产生最有意义值认为它是一条最通常的、并对相关参与者产生最有意义值的路径。一般来说，这一基本条路径还应包含系统的一些的路径。一般来说，这一基本条路径还应包含系统的一些例外和异常处理。例外和异常处理。 接之接之，描述其余可选路径。其中，是否把其中那些很小，描述其余可选路径。其中，是否把其中那些很小的可选路径，作为基本路径的组成部分，还是作为一条独的可选路径，作为基本路径的组成部分，还是作为一条独立的路径，这是一个设计决策问题，取决于该描述是否精立的路径，这是一个设计决策问题，取决于该描述是否精确，是否容易阅读。确，是否容易阅读。例如：例如：“PathsofthePayInvoiceUseCasePrecondition:Thebuyerhasreceivedthegoodsorservicesorderedandatleastoneinvoicefromthesystem.Thebuyernowplanstoscheduletheinvoice(s)forpayment.FlowofEventsBasicPath1Thebuyerinvokestheusecasebybeginningtobrowsetheinvoicesreceivedbythesystem.Thesystemchecksthatthecontentofeachinvoiceisconsistentwithorderconfirmationsreceivedearly(aspartoftheConfirmOrderusecase)andsomehowindicatesthistothebuyer.Theorderconfirmationdescribeswhichitemswillbedelivered,when,where,andatwhatprice.2Thebuyerdecidestoscheduleaninvoiceforpaymentbythebank,andthesystemgeneratesapaymentrequesttotransfermoneytothesellersaccount.Notethatabuyermaynotschedulethesameinvoiceforpaymenttwice.3later,ifthereisenoughmoneyinthebuyersaccount,apaymenttransactionismadeonthescheduleddate.Duringthetransaction,moneyistransferredfromthebuyersaccounttothesellersaccount,asdescribedbytheabstractusecasePerformTransaction(whichisusedbyPayInvoice).Thebuyerandthesellerarenotifiedoftheresultofthetransaction.Thebankcollectafeeforthetransaction,whichiswithdrawnfromthebuyersaccountbythesystem.4Theusecaseinstanceterminates.AlternativePathInStep2,thebuyermayinsteadaskthesystemtosendaninvoicerejectionbacktotheseller.InStep3,ifthereisnotenoughmoneyintheaccount,theusecasewillcancelthepaymentandnotifythebuyer.Post-condition:Theusecaseinstanceendswhentheinvoicehasbeenpaidorwhentheinvoicepaymentwascanceledandnomoneywastransferred.” 一般来说，在用况的一个精化描述中，其基本内容包括：一般来说，在用况的一个精化描述中，其基本内容包括： 定义一个前置条件，用于表达该用况的开始状态；定义一个前置条件，用于表达该用况的开始状态； 定义第一个要执行的动作，例如上例中的定义第一个要执行的动作，例如上例中的 Step 1Step 1，描，描 述该用况是如何开始的，什么时候开始。述该用况是如何开始的，什么时候开始。 定义该用况中基本路径所要求的动作及其次序。上例中定义该用况中基本路径所要求的动作及其次序。上例中 以次序号（以次序号（ Step 1-4)Step 1-4)）定义了动作及其执行次序；）定义了动作及其执行次序； 描述该用况是如何结束的，什么时候结束（例如描述该用况是如何结束的，什么时候结束（例如 Step Step 4 4 ）；）； 定义一个后置条件，用于表达可能的结束状态；定义一个后置条件，用于表达可能的结束状态； 描述基本路径之外的可选路径；描述基本路径之外的可选路径； 定义系统与参与者之间的交互以及它们之间的交换定义系统与参与者之间的交互以及它们之间的交换 ( (例例如如Step 2 Step 2 和和Step 3)Step 3)，即描述该用况的动作是如何被相关参，即描述该用况的动作是如何被相关参与者激发的，以及它们是如何响应参与者的要求。其中，如与者激发的，以及它们是如何响应参与者的要求。其中，如果该系统与其它系统交互，则必须规约这一交互果该系统与其它系统交互，则必须规约这一交互, ,例如引用一例如引用一个标准的通讯协议。个标准的通讯协议。 描述系统中使用的有关对象、值和资源描述系统中使用的有关对象、值和资源 ( (例如例如Step 3)Step 3)，即描述在一个该用况的动作序列中，如何使用为该用况属性即描述在一个该用况的动作序列中，如何使用为该用况属性所赋予的值。所赋予的值。 总之总之, ,在用况描述中，必须明确描述系统做什么（执行的动在用况描述中，必须明确描述系统做什么（执行的动作）作） ，描述参与者做什么，并从参与者做什么中分离出系统，描述参与者做什么，并从参与者做什么中分离出系统的责任。否则用况描述就不够精确。的责任。否则用况描述就不够精确。注意注意: : 一个事件流的描述应包括一组管理上适于修改、复审、设一个事件流的描述应包括一组管理上适于修改、复审、设计、实现和测试的动作序列，并作为用户手册的一节内容。计、实现和测试的动作序列，并作为用户手册的一节内容。 对每一个用况的事件流，一般采用正文来描述其中的动作对每一个用况的事件流，一般采用正文来描述其中的动作序列，只有当该用况的动作序列和序列，只有当该用况的动作序列和/ /或该用况与其参与者的交互或该用况与其参与者的交互较为复杂时，才可使用活动图、状态图或交互图来描述之，而较为复杂时，才可使用活动图、状态图或交互图来描述之，而且在实际工作中的很多情况下，正文描述和这些图之间往往是且在实际工作中的很多情况下，正文描述和这些图之间往往是相互补充的。相互补充的。 不管采用什么描述技术，都必须描述所有的可选路径，否不管采用什么描述技术，都必须描述所有的可选路径，否则就不能说给出了该用况的规约。则就不能说给出了该用况的规约。 规约人员应当：规约人员应当： 紧密地与该紧密地与该use caseuse case的实际用户一起工作；在与其交谈的实际用户一起工作；在与其交谈中，通常需要记录他们对该中，通常需要记录他们对该use case use case 的理解的理解, ,并与其讨论建议并与其讨论建议方案。方案。 只有当满足以下条件时，才能说结束了用况描述：只有当满足以下条件时，才能说结束了用况描述： 用况是很容易可理解的；用况是很容易可理解的； 用况是正确的（即捕获了正确的需求）；用况是正确的（即捕获了正确的需求）； 用况是完备的（例如，描述了所有可能的路径）用况是完备的（例如，描述了所有可能的路径）; ; 用况是一致的。用况是一致的。用况的描述可以在需求捕获结束的复审会中，由分析用况的描述可以在需求捕获结束的复审会中，由分析员予以评估，也可以由用户和客户予以评估。但仅客员予以评估，也可以由用户和客户予以评估。但仅客户和用户才能确认用况是否是准确的。户和用户才能确认用况是否是准确的。关于半形式化的关于半形式化的Use-CaseUse-Case描述描述 前置条件前置条件 对于一个复杂的实时系统，对于一个复杂的实时系统， use caseuse case可能是相当负责的，可能是相当负责的，例如例如actorsactors和和 use case use case 之间的交互可能经过相当多的状态和之间的交互可能经过相当多的状态和状态转换，从而几乎不可能保持正文描述的状态转换，从而几乎不可能保持正文描述的use case use case 的一致的一致性。性。 相关的技术相关的技术 为此，需要使用更结构化的描述技术，这样的技术一般使为此，需要使用更结构化的描述技术，这样的技术一般使用可视化的建模技术，来描述用可视化的建模技术，来描述use cases use cases 。以下技术可以帮助。以下技术可以帮助系统分析人员更好地理解系统分析人员更好地理解use cases use cases ：BrowsingScheduleRejectInvoiceScheduledPayonduedateInvoicePaidInvoiceCancelledThestatechartdiagramforthePayInvoiceusecaseshowinghowaninstanceoftheInvoiceusecasemovesoverseveralstatesinseriesofstatetransitions.UML状态图状态图用于描述用于描述use caseuse case的状的状态和状和状态之之间的的转换。v活动图活动图 用于描述状态之间更详细的动作序列。用于描述状态之间更详细的动作序列。 注：活动图源于注：活动图源于SDLSDL的状态转换图（的状态转换图（ SDL state transition SDL state transition diagrams diagrams），它是已予证明的、用于电信的一种语言。），它是已予证明的、用于电信的一种语言。w交互图交互图 用于描述一个用于描述一个use caseuse case的实例如何与的实例如何与 actor actor 的一个实例的一个实例 进行交互。为此，交互图给出了进行交互。为此，交互图给出了use case use case 以及参与的以及参与的 actoractor（s s）。）。注意注意: : 在使用这些图当中，由于问题的复杂性，有时可能会出在使用这些图当中，由于问题的复杂性，有时可能会出现一些大的、复杂的图，以至于很难阅读和理解，特别对于现一些大的、复杂的图，以至于很难阅读和理解，特别对于那些不是软件开发人员来说更难阅读。那些不是软件开发人员来说更难阅读。 这些图是一些更接近开发细节的图，应与系统其它模型这些图是一些更接近开发细节的图，应与系统其它模型保持一致。保持一致。建议：建议： 应谨慎地使用这些图，在一般情况下，应采用应谨慎地使用这些图，在一般情况下，应采用 use caseuse case的的正文描述（即事件流描述）。正文描述（即事件流描述）。 在很多情况中，正文描述和这些图是互补的。在很多情况中，正文描述和这些图是互补的。活动活动4:4:用户界面的原型构造用户界面的原型构造 目的目的 建造一个建造一个用户界面的原型，使用户有效地执行用户界面的原型，使用户有效地执行use casesuse cases。 步骤步骤 第一步，用户界面的逻辑设计第一步，用户界面的逻辑设计 第二步，物理用户界面的设计第二步，物理用户界面的设计 第三步，开发用户界面原型，演示为了执行该第三步，开发用户界面原型，演示为了执行该use use case case，用户怎样使用该系统。，用户怎样使用该系统。 注：如何进行以上三步，可参见有关文献。注：如何进行以上三步，可参见有关文献。活动活动5 :Use Case 5 :Use Case 模型的结构化模型的结构化前置条件前置条件: : 系系统分析分析员已已经标识了了actors actors 和和 use cases, use cases, 已已经以以图予以了描述，并予以了描述，并给出了整个出了整个use case use case 模型的模型的说明。明。 use case use case 规约人人员已已经对每一每一use caseuse case开开发了了详细的的描述。描述。 做什么做什么： 抽取抽取use caseuse case描述中一般的、共享的功能，用于特定描述中一般的、共享的功能，用于特定 use caseuse case描述。描述。 抽取抽取use caseuse case描述中附加的或可描述中附加的或可选的（的（additional or additional or optional optional）功能，它）功能，它们可能被可能被扩展展为特定特定use caseuse case描述。描述。使用泛化关系，标识并描述那些共享功能使用泛化关系，标识并描述那些共享功能 例如：例如：BuyerSellerPayInvoicePayInvoice和和PerformTransaction这这2个个usecase之间的泛化关系之间的泛化关系PerformTransaction使用使用扩展关系，标识并描述附加的或可选的功能扩展关系，标识并描述附加的或可选的功能 例如：例如：BuyerSellerPayInvoicePayInvoice和和PayOverdraftFee这这2个个usecases之间的扩展关系之间的扩展关系extendPerformTransactionPayOverdraftFee 标识标识use caseuse case之间的其它关系之间的其它关系 use casesuse cases之间还包括其它关系，例如包含关系（之间还包括其它关系，例如包含关系（includeinclude ）。）。在用况的结构化中，应注意以下问题：在用况的结构化中，应注意以下问题： 在建立用况的结构中，应尽可能地反映用况的实际情况。否在建立用况的结构中，应尽可能地反映用况的实际情况。否则，不论对用户或客户，还是对开发人员本身，要理解这些用则，不论对用户或客户，还是对开发人员本身，要理解这些用况以及它们的意图就变得相当困难。况以及它们的意图就变得相当困难。在用况的结构化中，不论是施加什么结构，对新引入的用况在用况的结构化中，不论是施加什么结构，对新引入的用况都不应太小或太大。因为，在以后的开发中，对每一个用况都都不应太小或太大。因为，在以后的开发中，对每一个用况都需要对其做进一步处理，成为一个特定的制品。例如在需求获需要对其做进一步处理，成为一个特定的制品。例如在需求获取阶段，用况规约人员需要给出它的描述，而在后续的分析和取阶段，用况规约人员需要给出它的描述，而在后续的分析和设计中，设计人员需要对不同的用况予以细化设计中，设计人员需要对不同的用况予以细化（realizationrealization），），这样，如果用况太小或太大，势必产生一系列管理上的问题。这样，如果用况太小或太大，势必产生一系列管理上的问题。在建立用况的结构中，应尽量避免对用况模型中的用况功能在建立用况的结构中，应尽量避免对用况模型中的用况功能进行分解。最好在分析和设计中对每一用况进行精化进行分解。最好在分析和设计中对每一用况进行精化（refiningrefining），其中如果需要的话，以面向对象风格把用况中），其中如果需要的话，以面向对象风格把用况中所定义的功能作为概念分析层上对象之间的协作，这样可以对所定义的功能作为概念分析层上对象之间的协作，这样可以对需求产生更深入的理解。需求产生更深入的理解。 通过对用况模型的结构化，最终形成系统的一个精化用况模通过对用况模型的结构化，最终形成系统的一个精化用况模型，记为用况模型型，记为用况模型 精化精化 。RUP需求获取小结需求获取小结(四点四点)需求获取以及相关制品需求获取以及相关制品 work to be done result artifacts-ListcandidaterequirementsFeaturelist-UnderstandsystemcontextBusinessordomainmodel-CapturefunctionalrequirementsUsecasemodel-CapturenonfunctionalSupplementaryrequirementsrequirementsorindividualusecases(forusecasespecificreq.)业务模型或领域模型业务模型或领域模型建立了系统的语境，是创建系建立了系统的语境，是创建系统统usecase模型的基础。模型的基础。wusecase模型模型Use-CaseModel是软件和客户就需求的一个共识，即系统是软件和客户就需求的一个共识，即系统必须具有的条件（必须具有的条件（conditions）和能力（）和能力（capabilities）。TheUse-Case模型为系统分析、设计、实现以及测试提供模型为系统分析、设计、实现以及测试提供了基本的输入。了基本的输入。AUse-Case模型是系统的一个模型，包含系统中模型是系统的一个模型，包含系统中actors、usecases以及它们之间的关系。即：以及它们之间的关系。即：Use-CasesystemUse-CasemodelActorUsecase*1TheUse-Casemodelanditscontents.TheUse-Casesystemdenotesthetop-levelpackageofthemodeluse-case模型捕获了功能需求。非功能需求特定于单个的模型捕获了功能需求。非功能需求特定于单个的usecase，其，其规约具有一般性，并不针对一个特定的规约具有一般性，并不针对一个特定的use case use case 。use-case模型的描述，可以通过：模型的描述，可以通过：-asurveydescription-adetaileddescriptionofeachusecase. 对于对于use case use case 模型中的每一模型中的每一 use case use case ，应驱动开发的后，应驱动开发的后续工作，并实现它们的无缝连接。即在分析阶段和设计阶段，续工作，并实现它们的无缝连接。即在分析阶段和设计阶段，应标识相匹配的应标识相匹配的 use-case use-case 细化细化（realizationrealization），并标识测试阶段，并标识测试阶段中的一组测试用例（中的一组测试用例（ test cases test cases ）。）。捕获需求阶段的活动捕获需求阶段的活动序序号号输入输入活动活动执行者执行者输出输出1业业务务模模型型或或领领域域模模型型,补充需求补充需求,特征表特征表发发现现参参与与者和用况者和用况系系统统分分析析员员、客客户户、用户、其他分析员用户、其他分析员用用况况模模型型概概述述，术语表术语表2用用况况模模型型概概述述，补补充充需求，术语表需求，术语表赋赋予予用用况况优先级优先级体系结构设计者体系结构设计者体体系系结结构构描描述述用况模型角度用况模型角度3用用况况模模型型概概述述，补补充充需求，术语表需求，术语表细化用况细化用况用况描述者用况描述者用况用况详述详述4用用况况详详述述，用用况况模模型型概概述述，补补充充需需求求，术术语表语表人人机机接接口口原型化原型化人机接口设计者人机接口设计者人机接口原型人机接口原型5用用况况详详述述，用用况况模模型型概概述述，补补充充需需求求，术术语表语表构构造造用用况况模型模型系统分析员系统分析员用况模型用况模型详述详述)需求分析的目标及其途径需求分析的目标及其途径(1)目标目标:实际问题实际问题？需求获取模型需求获取模型形成形成？需求分析模型需求分析模型形成形成需需求求获获取取需需求求分分析析注：实现第二次抽象注：实现第二次抽象注：实现第一次抽象注：实现第一次抽象(2) (2) 实现实现需求分析目标的基本途径需求分析目标的基本途径 实现实现需求获取层到需求分析层的映射，即从软件开发需求获取层到需求分析层的映射，即从软件开发的角度的角度- -实现第二次抽象。如同实际问题层到需求获取层实现第二次抽象。如同实际问题层到需求获取层一样一样, ,其中至少涉及以下其中至少涉及以下3 3个问题：个问题： 如何定义需求分析层，即给出该层的术语；如何定义需求分析层，即给出该层的术语； 如何确定模型表示工具；如何确定模型表示工具； 如何映射。如何映射。需求分析层的术语（概念）需求分析层的术语（概念） 术语术语: : 分析类（分析类（Analysisclass） UseCase细化（细化（UseCaseRealization-Analysis） 分析包（分析包（AnalysisPackage） 其中其中: :分析类（分析类（Analysisclass）一个分析类抽象地表达了一个分析类抽象地表达了 系统设计中系统设计中 的一个或多个类和的一个或多个类和/ /或子系统。或子系统。分析类的基本性质：分析类的基本性质： 分析类关注处理功能需求，而将非功能需求的处理延迟到分析类关注处理功能需求，而将非功能需求的处理延迟到 以后的设计和实现活动中，并作为类的特殊需求。以后的设计和实现活动中，并作为类的特殊需求。 分析类的行为一般是通过高层的责任予以定义的分析类的行为一般是通过高层的责任予以定义的( (一个责一个责 任是高内聚的一组由类所定义的行为的正文描述任是高内聚的一组由类所定义的行为的正文描述),),很少通很少通 过操作和其声明（过操作和其声明（ signaturessignatures）予以定义或提供接口。）予以定义或提供接口。 分析类的属性也是在很高层次上定义的。这类属性经常是分析类的属性也是在很高层次上定义的。这类属性经常是 问题域上的概念，并可通过问题域就可以了解其含义。问题域上的概念，并可通过问题域就可以了解其含义。 分析类所涉及的关联，多数是概念性的，例如关联的导航分析类所涉及的关联，多数是概念性的，例如关联的导航 性，在分析中并非十分重要，而在设计中就是基本的。性，在分析中并非十分重要，而在设计中就是基本的。目的：使分析类在问题域中更加突出，与设计和实现中的类目的：使分析类在问题域中更加突出，与设计和实现中的类 相比，粒度大，是概念性的。相比，粒度大，是概念性的。-边界类边界类(Boundaryclasses):内涵内涵：用于模型化：用于模型化系统和其系统和其actors之间的交互。该交互一般涉及向用之间的交互。该交互一般涉及向用户和外部系统发出请求和从他们那里接受信息。户和外部系统发出请求和从他们那里接受信息。与设计平台的关系与设计平台的关系：边界类常常是在更高的概念层上，对：边界类常常是在更高的概念层上，对windows,forms,communicationinterfaces,printerinterfaces,sensors,terminals,andAPIs等的抽象，忽略其中的一些细节等的抽象，忽略其中的一些细节-例如用户窗例如用户窗口的宽度，并且不需要描述该交互的物理实现（口的宽度，并且不需要描述该交互的物理实现（realize）。）。基于的设计原理基于的设计原理：分离不同的用户界面或通讯界面，形成一个或多个：分离不同的用户界面或通讯界面，形成一个或多个边界类。边界类。分析类的种类分析类的种类：三种：边界类三种：边界类（Boundaryclasses）实体类实体类（Entityclasses）控制类控制类（Controlclasses）-实体类（实体类（Entityclasses）:内涵内涵：用于模型化：用于模型化那些需要长期足留系统的对象那些需要长期足留系统的对象-例如人的信息例如人的信息,以及与行以及与行为相关的某些现象为相关的某些现象例如实际的一个事件。例如实际的一个事件。与业务类的关系与业务类的关系：在大多数情况下，实体类对应业务模型中的业务类。其中一个主要区在大多数情况下，实体类对应业务模型中的业务类。其中一个主要区别是：现在所考虑的实体类，一般是要由系统处理的那些对象。别是：现在所考虑的实体类，一般是要由系统处理的那些对象。与设计平台的关系与设计平台的关系：实体类一般表示一个逻辑数据结构和属性，以理解系统依赖什么信息。实体类一般表示一个逻辑数据结构和属性，以理解系统依赖什么信息。基于的设计原理基于的设计原理：分离待处理的不同信息分离待处理的不同信息,形成一些不同的对象。形成一些不同的对象。-控制类（控制类（ControlClasses）：）：内涵内涵:用于模型化用于模型化系统的动态性（系统的动态性（dynamics）,包括包括:用于表达协同、定序、事务以及对其它对象的控制；用于表达协同、定序、事务以及对其它对象的控制；用于封装那些与特定用于封装那些与特定usecase有关的控制；有关的控制；用于表达复杂的推导和计算，例如不与用于表达复杂的推导和计算，例如不与任何存贮在系统中的特任何存贮在系统中的特定定信息有关的业务逻辑信息有关的业务逻辑.简言之简言之,控制类处理并协调边界类对象和实体类对象的基本动作控制类处理并协调边界类对象和实体类对象的基本动作（actions）和控制流，并向它们委派工作。）和控制流，并向它们委派工作。基于的设计原理基于的设计原理：问题分离问题分离控制类分离一些不同的控制、协调、定序以及不同的复杂业务逻辑，并控制类分离一些不同的控制、协调、定序以及不同的复杂业务逻辑，并予以封装，形成一些所谓的控制类，其中一般要涉及其他一些对象。予以封装，形成一些所谓的控制类，其中一般要涉及其他一些对象。其中而不能封装那些与其中而不能封装那些与actors交互有关的问题（由边界类予以封装）交互有关的问题（由边界类予以封装）也不能封装那些与系统处理的信息有关的问题（由实体类予以封装）也不能封装那些与系统处理的信息有关的问题（由实体类予以封装）分析包（分析包（Analysis PackageAnalysis Package） 分析包提供了一种组织分析制品的手段，形成一些可管理分析包提供了一种组织分析制品的手段，形成一些可管理的部分。的部分。 分析包可包含分析类、分析包可包含分析类、 use case use case 细化以及其它分析包细化以及其它分析包: :Analysispackage*AnalysisclassUsecaseRealization-analysisAnalysispackagecontents分析包的主要特征分析包的主要特征（characteristic） 高内聚、低耦合；高内聚、低耦合； 表达了对所要分析问题的一种分离；例如，将不同领域知表达了对所要分析问题的一种分离；例如，将不同领域知 识分为不同的包予以分析识分为不同的包予以分析; ; 对具有领域知识的人来说，是可以阅读、理解的。这是对具有领域知识的人来说，是可以阅读、理解的。这是由由 于包于包是针对功能需求和问题域予以创建的是针对功能需求和问题域予以创建的; ; 很有可能成为一些子系统或成为一些子系统的组成部分。很有可能成为一些子系统或成为一些子系统的组成部分。 在某些情况中，甚至可以反映一个完整的顶层设计。在某些情况中，甚至可以反映一个完整的顶层设计。 Use-Case细化（细化（Use-CaseRealization-Analysis） 内涵内涵（何谓何谓 Use-Case Use-Case 细化？）细化？） 一个一个Use-Case Use-Case 细化是分析模型中的一个协作（细化是分析模型中的一个协作（ a a collaborationcollaboration ），描述了一个特定的），描述了一个特定的 Use-CaseUse-Case如何运用分析如何运用分析类以及分析类的交互对象进行细化和执行类以及分析类的交互对象进行细化和执行 。 作用作用： Use-Case Use-Case 细化对细化对use-caseuse-case模型中的一个特定的模型中的一个特定的 use use case case 提供了一中直接方式的跟踪。提供了一中直接方式的跟踪。 如何表达如何表达Use-Case Use-Case 细化？细化？正文的事件流正文的事件流类图类图交互图交互图模型表达模型表达AnalysismodelAnalysisSystemAnalysisPackageAnalysisClassUse-CaseRealization-Analysis分析模型是分析包的一个层次结构，包含分析类和分析模型是分析包的一个层次结构，包含分析类和use-caseuse-case细化。细化。*1AnalysisSystemdenotesthetop-levelpackageofthemodel. Workflow活动活动1:体系结构分析（体系结构分析（ArchitecturalAnalysis）目标：通过标识目标：通过标识分析包，分析包，分析类，分析类， 公共的特定需求，公共的特定需求，建立分析模型和体系结构的建立分析模型和体系结构的“骨架骨架”？需求分析模型需求分析模型形成形成需求获取模型需求获取模型任务任务1：标识分析包：标识分析包基本输入：基本输入：usecase模型模型-基于功能需求和问题域，即考虑需要的应用和业务，基于功能需求和问题域，即考虑需要的应用和业务， 对分析工作进行划分，形成一些分析包。对分析工作进行划分，形成一些分析包。 -依据依据use casesuse cases的主要功能（方面），把一些的主要功能（方面），把一些use use cases cases 分派到特定的包中。分派到特定的包中。 -精化该包中的功能。精化该包中的功能。 USECASE1USECASE3USECASE2USECASE5USECASE6USECASE4其中其中, use cases, use cases的分派，需要考虑以下问题的分派，需要考虑以下问题, ,以支持包的高以支持包的高 内聚：内聚： 一个包中的一个包中的 use cases use cases 是否支持一个特定的是否支持一个特定的业务过程业务过程； 一个包中的一个包中的 use cases use cases 是否支持一个特定的是否支持一个特定的系统系统actoractor。 一个包中的一个包中的 use cases use cases 是否具有是否具有“泛化泛化”和和“扩展扩展”关系。关系。注意：注意： 一个分析包将一些变化分别局部到（一个分析包将一些变化分别局部到（ localize to localize to ）一个业务过程，一个一个业务过程，一个actoractor的行为，一组高耦合的的行为，一组高耦合的use cases use cases 通过通过 use casesuse cases细化，可以演化包的结构。细化，可以演化包的结构。支付发票支付发票采购员发票管理采购员发票管理采购员获取发票采购员获取发票发送余额发送余额销售员发票管理销售员发票管理tracetracetrace例如例如: :该例表明，如何基于网络银行的用况模型来标识它的分析包该例表明，如何基于网络银行的用况模型来标识它的分析包,其其中三个用况：中三个用况：“获取发票的采购员获取发票的采购员”、“支付发票支付发票”、“发送发送余额余额”，紧紧围绕，紧紧围绕“买卖买卖”业务中的有关发票处理问题，因此，业务中的有关发票处理问题，因此，可以把这些用况作为一个分析包。可以把这些用况作为一个分析包。但是，网络银行软件面对的是具有不同要求的客户，有的客但是，网络银行软件面对的是具有不同要求的客户，有的客户仅是采购员户仅是采购员，而另一客户仅是销售员，而有的客户既是采购，而另一客户仅是销售员，而有的客户既是采购员，又是销售员。因此，为了满足客户的这一需求，就需要把员，又是销售员。因此，为了满足客户的这一需求，就需要把这三个用况分为如图的这三个用况分为如图的2个分析包：个分析包：“采购员发票管理采购员发票管理”和和“销销售员发票管理售员发票管理”。注意：支持注意：支持“买卖买卖”业务过程还有其它用况业务过程还有其它用况，但为了使例子简，但为了使例子简单而予忽略之。单而予忽略之。任务任务2：处理分析包之间的共性：处理分析包之间的共性方法：抽取共享类，继之把共享类放到一个包中，并让其它包方法：抽取共享类，继之把共享类放到一个包中，并让其它包依赖该类或该类所在的更一般化的包。依赖该类或该类所在的更一般化的包。USECASE1USECASE3USECASE2USECASE5USECASE6USECASE4USECASE细化中的一个共细化中的一个共享类享类-体现体现包之间的共性包之间的共性任务任务3 3：标识服务包（：标识服务包（ Service PackagesService Packages） 在包的层次结构中，除了考虑以上那种对在包的层次结构中，除了考虑以上那种对“共性共性”的依赖外，的依赖外，时常还要考虑服务依赖，即应用层的包依赖下层提供的服务包。时常还要考虑服务依赖，即应用层的包依赖下层提供的服务包。 何谓服务，在何谓服务，在RUPRUP中服务是指功能上紧密相关的、可被多个中服务是指功能上紧密相关的、可被多个用况使用的一组动作。用况使用的一组动作。 一个服务的主要特征是：一个服务的主要特征是： 服务是不能分割的，或系统完整地提供之，或不提供之；服务是不能分割的，或系统完整地提供之，或不提供之； 服务是针对客户而言的，而用况是针对用户而言的，即当服务是针对客户而言的，而用况是针对用户而言的，即当细化一个用况时，可能需要多个服务，即一个用况需要多个不细化一个用况时，可能需要多个服务，即一个用况需要多个不同服务中的动作。同服务中的动作。 何谓服务包何谓服务包: :由服务所组成的包称为服务包。由服务所组成的包称为服务包。 显然服务包是一个功能包，通常包含一组功能相关的类。显然服务包是一个功能包，通常包含一组功能相关的类。 服务包的主要特征是：服务包的主要特征是： 是不可分离的，即如果客户需要这一包，就要其中的所有类；是不可分离的，即如果客户需要这一包，就要其中的所有类； 一般只涉及一个参与者或很少几个参与者；一般只涉及一个参与者或很少几个参与者； 可构成以后设计和实现的一个基本输入，可形成一个服务子可构成以后设计和实现的一个基本输入，可形成一个服务子系系 统，以支持设计模型和实现模型的结构化；统，以支持设计模型和实现模型的结构化； 所定义的功能，往往可以作为设计和实现中的一个发布单位，所定义的功能，往往可以作为设计和实现中的一个发布单位， 因此它所表达的功能可能是系统的内嵌因此它所表达的功能可能是系统的内嵌（“add-inadd-in”）功能；功能； 服务包可独立执行，对于同一服务的不同方面，可以由系统服务包可独立执行，对于同一服务的不同方面，可以由系统的的 2 2个不同服务包提供，例如：个不同服务包提供，例如： “英文的拼写检查英文的拼写检查”； “美语的拼写检查美语的拼写检查” 服务包之间的依赖，通常是非常受限制的。服务包之间的依赖，通常是非常受限制的。可见，服务包的引入，可用于系统的结构化处理，即可见，服务包的引入，可用于系统的结构化处理，即: : 依据服务包所提供的服务，把它放到分析包层次结构中的依据服务包所提供的服务，把它放到分析包层次结构中的低层，以便应用包对它的引用。低层，以便应用包对它的引用。 应用包应用包B依赖依赖 应用包应用包A服务包服务包依赖依赖当系统功能需求得到了很好理解，并且已存在很多分当系统功能需求得到了很好理解，并且已存在很多分析类的情况下，才能有效地标识服务包。析类的情况下，才能有效地标识服务包。 标识服务包的基本方法标识服务包的基本方法: : 或依据客户对有关服务的要求，或依据客户对有关服务的要求， 或直接将多个功能相关的分析类所提供的服务，标识为或直接将多个功能相关的分析类所提供的服务，标识为 一个服务包。一个服务包。 例如，假定：例如，假定： - - 类类A A的一个变化，很可能要求类的一个变化，很可能要求类B B的一个变化；的一个变化； - - 把类把类A A拿掉，使类拿掉，使类B B成为多余的；成为多余的； - - 类类A A的一个对象与类的一个对象与类B B的一个对象，可能需要以多个不同的一个对象，可能需要以多个不同 的消息发生交互。的消息发生交互。 这时就可以将类这时就可以将类A A和类和类B B所提供的服务标识为一个服务包。所提供的服务标识为一个服务包。 任务任务4 4 ：定义分析包的依赖：定义分析包的依赖 目标：目标：发现相对独立的包，实现包的高内聚和低耦合。发现相对独立的包，实现包的高内聚和低耦合。 途径途径: :通常使用特定应用包和公用包通常使用特定应用包和公用包, ,把分析模型分为两个把分析模型分为两个层面，清晰地区分特殊性功能和一般性功能。层面，清晰地区分特殊性功能和一般性功能。 例如例如: : 分析包的层次和依赖分析包的层次和依赖 通过以上任务通过以上任务1 1、2 2、3 3和和4 4，就可以形成对体系结构是具有重，就可以形成对体系结构是具有重要影响的分析包的层次结构。要影响的分析包的层次结构。采购员发票管理采购员发票管理销售员发票管理销售员发票管理帐目管理帐目管理应用共享层应用共享层特定应用层特定应用层依赖依赖任务任务5 5：标识重要的实体类：标识重要的实体类 目标目标: :标识在体系结构方面具有重要意义的实体类。为此：标识在体系结构方面具有重要意义的实体类。为此： 途径途径: : 首先，基于需求捕获中标识的领域类和业务实体，发现其首先，基于需求捕获中标识的领域类和业务实体，发现其中对体系结构具有意义的类，作为分析模型中的实体类，以此中对体系结构具有意义的类，作为分析模型中的实体类，以此形成体系结构的初始骨架。一般情况下形成体系结构的初始骨架。一般情况下, ,即使对于一个比较大的即使对于一个比较大的系统，这样的类也只在系统，这样的类也只在1010个个-20-20个左右。个左右。此时，不必标识过多的类，也不必了解更多的此时，不必标识过多的类，也不必了解更多的细节，因为在以后对细节，因为在以后对use-case进行细化，标识其进行细化，标识其中实际需要的实体类时，可能还需要重复以上中实际需要的实体类时，可能还需要重复以上的工作。的工作。 其次，使用领域模型中领域类之间的聚合和关联，或使用业其次，使用领域模型中领域类之间的聚合和关联，或使用业务模型中业务实体之间的聚合和关联，来标识这些实体类之间务模型中业务实体之间的聚合和关联，来标识这些实体类之间一组暂定的关联。一组暂定的关联。 任务任务6 6：标识公共的特定需求：标识公共的特定需求 在分析期间，不论是对已标识的包还是对已标识的分析类，在分析期间，不论是对已标识的包还是对已标识的分析类，为了支持以后的设计和实现，都可能会出现一些特殊需求。例为了支持以后的设计和实现，都可能会出现一些特殊需求。例如对以下问题的约束和限制：如对以下问题的约束和限制： 永久性；永久性； 分布与并发；分布与并发； 安全性安全性; ; 容错能力容错能力 事务管理等。事务管理等。 因此，该任务的目标是标识每一特殊需求的关键特征。因此，该任务的目标是标识每一特殊需求的关键特征。 通过以上六项任务的实施，其中系统化地使用了有关分析包、通过以上六项任务的实施，其中系统化地使用了有关分析包、服务包、依赖、关键实体类等术语，给出了系统的体系结构描服务包、依赖、关键实体类等术语，给出了系统的体系结构描述，称为分析模型视角下的体系结构描述，记为体系结构描述述，称为分析模型视角下的体系结构描述，记为体系结构描述分析分析。 可见可见, ,分析模型视觉下的体系结构描述分析模型视觉下的体系结构描述, ,描述一些在体系结描述一些在体系结构方面具有重要意义的制品。一般包括：构方面具有重要意义的制品。一般包括： 分析包以及它们的依赖分析包以及它们的依赖 一些关键的分析类一些关键的分析类 活动活动2:UseCase分析分析目标：目标：标识那些在标识那些在use caseuse case事件流的执行中所需要的对象和类。事件流的执行中所需要的对象和类。 将将 use caseuse case的行为，分布的行为，分布 （DistributeDistribute）到交互的分析）到交互的分析 对象。对象。 捕获捕获use caseuse case细化上的特定需求。细化上的特定需求。 （Anothertermforusecaseanalysiswouldbeuse-caserefinement.Werefineeachusecaseasacollaborationofanalysisclasses.）UsecaseengineeringUseCasemodelSupplementaryRequirementsArchitectureDescriptionviewoftheanalysismodelAnalyzeausecase分析一个分析一个usecase的输入和输出的输入和输出Businessmodelordomainmodelusecaserealization-analysisAnalysisclassoutlined任务任务1：标识分析类：标识分析类标识那些细化标识那些细化use caseuse case所需要的实体类、控制类和边界类。所需要的实体类、控制类和边界类。并给出它们的名字、责任、属性和关系。并给出它们的名字、责任、属性和关系。-准备工作准备工作首先首先应从系从系统之外的角度，来精化用况的事件流正文描述之外的角度，来精化用况的事件流正文描述.-一般性指导：一般性指导： 标识实体类标识实体类 在活动在活动1 1的任务的任务5 5中，已经标识了一些对体系结构具有重要中，已经标识了一些对体系结构具有重要影响的实体类，在此基础上，基于该用况的事件流正文描述，影响的实体类，在此基础上，基于该用况的事件流正文描述，发现其中其余逻辑对象（即发现其中其余逻辑对象（即“大大”对象），并依据类的定义，对象），并依据类的定义，来标识其它实体类。来标识其它实体类。其中其中, ,应应: : 学习学习/ /研究研究use caseuse case的描述；的描述； 更深入地研究已有的领域模型；更深入地研究已有的领域模型； 考虑在考虑在 use-caseuse-case细化中还需要什么信息，以实现其功能细化中还需要什么信息，以实现其功能 还要思考还要思考: :， 是否应把这些信息标识为边界类、控制类的属性；是否应把这些信息标识为边界类、控制类的属性； 是否在是否在use caseuse case细化中需要这些信息；细化中需要这些信息； 如果是的话，这样的如果是的话，这样的“信息信息”就不应作为实体就不应作为实体类。类。 标识边界类标识边界类 在标识该用况的边界类中，可把边界类分为核心边界类和在标识该用况的边界类中，可把边界类分为核心边界类和原子边界类原子边界类: : 核心边界类核心边界类: :是指系统与人（参与者）进行交互的接口；是指系统与人（参与者）进行交互的接口； 原子边界类原子边界类: :是指系统与外部系统、设备等进行交互的接是指系统与外部系统、设备等进行交互的接 口，或实体类之间进行交互的接口。口，或实体类之间进行交互的接口。人人系统或设备系统或设备实体类实体类核心边界类核心边界类原子边界类原子边界类 核心边界类的标识核心边界类的标识 为每一个与该用况交互的人（参与者），标识一个核心边为每一个与该用况交互的人（参与者），标识一个核心边界类，并用这个类来表示用户接口的基本窗口（界类，并用这个类来表示用户接口的基本窗口（ primary primary window window ）。其中，应考虑以下）。其中，应考虑以下2 2个问题个问题: : 第一个问题是：如果该参与者已经与已标识的某一边界类第一个问题是：如果该参与者已经与已标识的某一边界类进行交互，那么就应该考虑是否复用那个边界类，减少基本进行交互，那么就应该考虑是否复用那个边界类，减少基本窗口的数目；窗口的数目； 第二个问题是：考虑是否在这一核心边界类与其他边界类第二个问题是：考虑是否在这一核心边界类与其他边界类之间存在泛化关系，尤其重要的是，考虑这一核心边界类是之间存在泛化关系，尤其重要的是，考虑这一核心边界类是否是某些原子边界类的父类。否是某些原子边界类的父类。 原子边界类的标识原子边界类的标识 -对以前发现的每一个实体类，如果它们所表达的一些逻对以前发现的每一个实体类，如果它们所表达的一些逻辑对象在相应的用况执行期间，辑对象在相应的用况执行期间， 参与者（人）需要通过一个参与者（人）需要通过一个核心边界类与这些逻辑对象进行交互，那么就为这样的实体核心边界类与这些逻辑对象进行交互，那么就为这样的实体类标识一个原子边界类。继之，可依据不同的可用性准则，类标识一个原子边界类。继之，可依据不同的可用性准则，对这些原子边界类进行精化，以利于创建对这些原子边界类进行精化，以利于创建“好好”的用户接口。的用户接口。 -对该用况的每个外部系统的参与者对该用况的每个外部系统的参与者, ,标识一个原子边界类，标识一个原子边界类，用于表达通信界面。其中，如果该通讯涉及多层协议，那么用于表达通信界面。其中，如果该通讯涉及多层协议，那么就有必要区别对待这些不同的层次，为所关注的不同层标识就有必要区别对待这些不同的层次，为所关注的不同层标识不同的边界类。不同的边界类。 标识控制类标识控制类 为负责处理该用况细化的控制和协调，标识一个控制类为负责处理该用况细化的控制和协调，标识一个控制类, , 并依据该用况的需求，精化这一控制类。其中应当注意：并依据该用况的需求，精化这一控制类。其中应当注意： 有时，由控制类负责的一些控制最好封装在一个边界类有时，由控制类负责的一些控制最好封装在一个边界类中，特别地，如果当相关的参与者在这一控制中其到很大作中，特别地，如果当相关的参与者在这一控制中其到很大作用时，可能就不需要控制类。用时，可能就不需要控制类。 有时，由控制类负责的控制是相当复杂的，这时最好把有时，由控制类负责的控制是相当复杂的，这时最好把这样的控制封装在这样的控制封装在2 2个或多个控制类中。个或多个控制类中。在完成实体类、边界类和控制类的标识之后，一般可采用一在完成实体类、边界类和控制类的标识之后，一般可采用一个类图，汇聚参与该用况细化的所有分析类，并在其细化中个类图，汇聚参与该用况细化的所有分析类，并在其细化中给出中所使用的各种关系。给出中所使用的各种关系。任务任务2：分析（类）对象交互的描述：分析（类）对象交互的描述工具：工具：使用交互图来描述（类）对象之间的交互。使用交互图来描述（类）对象之间的交互。 途径途径: : 在创建一个交互图当中，在创建一个交互图当中， 首先，确定细化该用况所必要的交互，这一般应从用况的首先，确定细化该用况所必要的交互，这一般应从用况的流开始，一次经过一个流。其中涉及参与交互的分析对象和参流开始，一次经过一个流。其中涉及参与交互的分析对象和参与者实例，通常在交互的定序中，自然就能在任务中所标识的与者实例，通常在交互的定序中，自然就能在任务中所标识的分析类中发现参与交互的客体。分析类中发现参与交互的客体。例如，例如， “银行客户银行客户”和用况和用况“取款取款”的交互，所涉及的对象有：的交互，所涉及的对象有： ：银行客户：银行客户， ：人机接口：人机接口， ：取钱接口：取钱接口， ：划拨：划拨， ：帐户：帐户 ：银行客户：银行客户标识身份标识身份：人机接口：人机接口取款请求取款请求：划拨取款：划拨取款消息消息-发发现现”人人机机接接口口”责任的种子责任的种子责任责任人机接口责任人机接口责任:-鉴别身份鉴别身份-发出取款请求发出取款请求其次，分派该用况的功能，这一般应基于激活该用况的一其次，分派该用况的功能，这一般应基于激活该用况的一个消息个消息-作为作为“种子种子”，来发现相关对象的责任。，来发现相关对象的责任。例如例如最后，再根据其责任，发现该交互图中各个链。其中，应在与最后，再根据其责任，发现该交互图中各个链。其中，应在与这一用况细化相关的交互图中或在类图中，明确给出一个关联这一用况细化相关的交互图中或在类图中，明确给出一个关联中所有对象之间的链，中所有对象之间的链，例如：例如：银行客户：银行客户标识身份标识身份取款请求取款请求通知客户通知客户自动取款自动取款：人机接口：人机接口：帐户：帐户：取钱接口：取钱接口：划拨取款：划拨取款验证并划拨验证并划拨验证失败验证失败注意注意: : 协作图中的链，通常是分析类之间的关联实例。这些关协作图中的链，通常是分析类之间的关联实例。这些关联或已经存在，或以这些链定义了有关关联的需求。在这一联或已经存在，或以这些链定义了有关关联的需求。在这一步中，应该在与这一步中，应该在与这一 use-caseuse-case细化相关的类图中，给出所细化相关的类图中，给出所有明显的关联有明显的关联 对象之间的链，以及有关每一特定对象的需求（由消息对象之间的链，以及有关每一特定对象的需求（由消息捕获而来的），应该予以特别的关注。捕获而来的），应该予以特别的关注。 如果如果 use case use case 具有不同的、有区别的流或子流，一具有不同的、有区别的流或子流，一般需要为每一个般需要为每一个 流创建一个交互图。这样：流创建一个交互图。这样： - -可以使可以使 use-case use-case 细化更加清晰；细化更加清晰； - -有助于使抽取的协作图可用来表达一般性、复用的交互有助于使抽取的协作图可用来表达一般性、复用的交互对系统用况模型中的每一用况实施上述两项任务，就可形成对系统用况模型中的每一用况实施上述两项任务，就可形成整个系统的用况细化整个系统的用况细化分析分析。活动活动3 3：类的分析：类的分析 通过活动通过活动1 1和活动和活动2 2，已经标识了系统中所有分析类，但没，已经标识了系统中所有分析类，但没有给出它们的详细描述有给出它们的详细描述. . 目标：目标：一是标识并维护分析类的责任；一是标识并维护分析类的责任； 二是基于它们在用况细化中的角色，标识并维护分二是基于它们在用况细化中的角色，标识并维护分 析类的属性和关系；析类的属性和关系； 三是捕获分析类细化中的特殊需求。三是捕获分析类细化中的特殊需求。 一般性指导一般性指导: : 任务任务1 1：标识责任：标识责任 组合一个类在不同用况细化中所扮演的角色组合一个类在不同用况细化中所扮演的角色. . 首先从类的角色中抽取该类的责任，而后基于用况的一次又一次的首先从类的角色中抽取该类的责任，而后基于用况的一次又一次的 细化（包括用况细化细化（包括用况细化 分析分析 ，用况细化，用况细化 设计设计 等），不断增加其责任等），不断增加其责任 或变更已有的责任。或变更已有的责任。 任务任务2 2：标识属性：标识属性 一个属性规约了类的一个特性，一般隐含在类的责任要求一个属性规约了类的一个特性，一般隐含在类的责任要求之中，因此，标识类的属性就要关注类的责任的要求。之中，因此，标识类的属性就要关注类的责任的要求。 实体类属性的标识实体类属性的标识 实体类属性的标识一般特别明显。特别地，如果一个实实体类属性的标识一般特别明显。特别地，如果一个实体类能跟踪到一个领域模型中的领域类，或能跟踪到业务模体类能跟踪到一个领域模型中的领域类，或能跟踪到业务模型中的业务实体类，那么领域类和业务实体类的属性是标识型中的业务实体类，那么领域类和业务实体类的属性是标识实体类属性的有价值的输入。实体类属性的有价值的输入。 边界类属性的标识边界类属性的标识 在标识边界类属性中，对那些与人（参与者）交互的边界在标识边界类属性中，对那些与人（参与者）交互的边界类，其属性常常表达由该参与者操纵的信息项，例如，标记类，其属性常常表达由该参与者操纵的信息项，例如，标记的正文栏。而对那些与外系统（参与者）交互的边界类，其的正文栏。而对那些与外系统（参与者）交互的边界类，其属性常常表现为一个通讯接口的性质。属性常常表现为一个通讯接口的性质。 控制类属性的标识控制类属性的标识 由于控制类属性通常具有较短的生命期，因此一般很少标由于控制类属性通常具有较短的生命期，因此一般很少标识控制类的属性。但是，在特定情况下，为了表达用况细化识控制类的属性。但是，在特定情况下，为了表达用况细化期间那些需要计算的值或需要推导的值，那么就要为这些值期间那些需要计算的值或需要推导的值，那么就要为这些值标识一些相应的属性。标识一些相应的属性。 在标识分析类的属性中，应当注意以下问题：在标识分析类的属性中，应当注意以下问题： 所标识的属性，其名字一般为名词；所标识的属性，其名字一般为名词； 属性类型一定是问题域中的概念，一般不要限定其实现属性类型一定是问题域中的概念，一般不要限定其实现环境；例如，在分析中，环境；例如，在分析中，“帐帐”可以是一个属性，而在设计可以是一个属性，而在设计中，与之对应的可以是中，与之对应的可以是“整型整型”。并且在选择一个属性类型。并且在选择一个属性类型时，应考虑复用已有的类型。时，应考虑复用已有的类型。 如果因为属性的原因使类变的非常复杂且不易理解，那如果因为属性的原因使类变的非常复杂且不易理解，那么这时就应考虑把其中某些属性分离出来，形成一个么这时就应考虑把其中某些属性分离出来，形成一个“整体整体/ /部分部分”结构。结构。 属性的表达一般只简单给出由类处理的性质属性的表达一般只简单给出由类处理的性质（propertyproperty），），并且可以在该类的责任描述中给出。其中如果一个类的属性并且可以在该类的责任描述中给出。其中如果一个类的属性很多或很复杂，可以在类图中仅给出属性框。很多或很复杂，可以在类图中仅给出属性框。任务任务3 3：标识关联和聚合：标识关联和聚合 标识关联标识关联 交互图中的链，表达了分析对象与其它对象的交互，因此交互图中的链，表达了分析对象与其它对象的交互，因此这些链通常是类之间关联的实例。因此应研究协作图中的链，这些链通常是类之间关联的实例。因此应研究协作图中的链，确定需要哪些关联，并定义关联的多重性、角色名、自关联、确定需要哪些关联，并定义关联的多重性、角色名、自关联、关联类、限定角色以及关联类、限定角色以及N N元关联等。元关联等。 标识聚合标识聚合 当一些对象表达了一些相互包含的概念，例如一辆轿车，当一些对象表达了一些相互包含的概念，例如一辆轿车，包含一名驾驶员和一些乘客；或当一些对象表达了一些相互包含一名驾驶员和一些乘客；或当一些对象表达了一些相互组合的概念，例如一辆轿车，由一个发动机和多个车轮组成；组合的概念，例如一辆轿车，由一个发动机和多个车轮组成；或当一些对象表达了客体的一个概念集，例如一个家庭，有或当一些对象表达了客体的一个概念集，例如一个家庭，有父亲、母亲和儿子，这时就把这一事实标识为聚合。父亲、母亲和儿子，这时就把这一事实标识为聚合。 标识泛化标识泛化由于泛化的基本目的是使分析模型更容易予以理解，因此，由于泛化的基本目的是使分析模型更容易予以理解，因此，具有一般意义的类应在更高的概念层上。例如具有一般意义的类应在更高的概念层上。例如: :其中，由于定单和发票具有类似的责任，因此可以作为交易其中，由于定单和发票具有类似的责任，因此可以作为交易对象的一个特殊化对象。对象的一个特殊化对象。TradeObjectOrderInvoiceTheTradeobjectgeneralizesInvoiceandOrder.活动活动4：包的分析：包的分析 目标目标: :一是确保分析包尽可能与其它包相对独立；一是确保分析包尽可能与其它包相对独立； 二确保分析包实现了它的目标，即细化了某些领域类二确保分析包实现了它的目标，即细化了某些领域类 或用况；或用况； 三是描述依赖，以益于可以估计未来的变化。三是描述依赖，以益于可以估计未来的变化。 一般性指导：一般性指导： 如果一个包中的类与其他一些包中的类具有关联，那么如果一个包中的类与其他一些包中的类具有关联，那么 就应在该包与那些其它包之间定义一个依赖并维护之就应在该包与那些其它包之间定义一个依赖并维护之. . 参见下页例参见下页例. . 确保该包所包含类是正确的，并力求使这些包仅包含相关确保该包所包含类是正确的，并力求使这些包仅包含相关 对象的功能，实现包的高内聚。对象的功能，实现包的高内聚。 限制与其他包的依赖。特别地，如果有些包所包含的类过限制与其他包的依赖。特别地，如果有些包所包含的类过 多地依赖其他包，那么对这些包就要考虑重新布局问题。多地依赖其他包，那么对这些包就要考虑重新布局问题。发票处理销售员发票管理发票处理帐目管理帐目帐目帐目管理帐目需要销售员发票管理例如例如: : 在包在包“销售员发票管理销售员发票管理”中包含一个类中包含一个类“发票处理发票处理”，而，而该类与包该类与包“帐目管理帐目管理”中的类中的类“帐目帐目”有关联，这样就需要有关联，这样就需要在这两个包之间建立一个相应的依赖。在这两个包之间建立一个相应的依赖。 RUP RUP需求分析小结需求分析小结( (四点四点) )第一点第一点: :关于需求分析关于需求分析 RUPRUP的分析如同结构化分析一样，其目标之一是在一个特定的分析如同结构化分析一样，其目标之一是在一个特定的抽象层上建立系统分析模型。为此，作为一种特定的系统分的抽象层上建立系统分析模型。为此，作为一种特定的系统分析方法学：析方法学： 首先，给出了三个术语：分析包、分析类和用况细化首先，给出了三个术语：分析包、分析类和用况细化. . 这三个术语可以表达这三个术语可以表达“大粒度大粒度”的概念，开发人员使的概念，开发人员使用用 这些术语可以规约系统分析中所要使用的信息。这些术语可以规约系统分析中所要使用的信息。 分析包分析包 分析包体现了分析包体现了“局部化局部化”、“问题分离问题分离”等软件设计原理。等软件设计原理。通过分析包这一术语可以把系统一些变化局部到一个业务过程、通过分析包这一术语可以把系统一些变化局部到一个业务过程、一个参与者的行为，或一组紧密相关的用况，形成一些不同的一个参与者的行为，或一组紧密相关的用况，形成一些不同的系统分析包。系统分析包。 一个分析包中可以包含一些分析类、用况细化和一些子包。一个分析包中可以包含一些分析类、用况细化和一些子包。 服务包和共享包是一些特殊的分析包，服务包将一些变化局服务包和共享包是一些特殊的分析包，服务包将一些变化局部到系统提供的一些单个的服务中，并展示了一个重要的指南，部到系统提供的一些单个的服务中，并展示了一个重要的指南，即在分析期间可以通过服务包来构造复用。即在分析期间可以通过服务包来构造复用。 通过依赖，可以形成包的一个层次结构，其中应用包一般位通过依赖，可以形成包的一个层次结构，其中应用包一般位于该结构的上层，而服务包和共享包位于该结构的下层。包的于该结构的上层，而服务包和共享包位于该结构的下层。包的层次结构可以作为系统的顶层设计。层次结构可以作为系统的顶层设计。 分析类分析类 分析类是一种粒度比较大的类，有其责任、概念性的属性和分析类是一种粒度比较大的类，有其责任、概念性的属性和关系。关系。 分析类分为边界类、实体类和控制类。分析类分为边界类、实体类和控制类。 在应用中，一般将用户接口、一个通讯接口方面的一个变在应用中，一般将用户接口、一个通讯接口方面的一个变 化，局部化到一个或多个边界类中；化，局部化到一个或多个边界类中； 一般将系统所处理信息方面的一个变化，局部化一般将系统所处理信息方面的一个变化，局部化 到一个或多个实体类中；到一个或多个实体类中； 一般将控制、协调、定序、事务和复杂业务逻辑一般将控制、协调、定序、事务和复杂业务逻辑 （它们要涉及多个边界和（它们要涉及多个边界和/ /或实体对象）方面的或实体对象）方面的 一个变化，局部化到一个或多个控制类中。一个变化，局部化到一个或多个控制类中。 用况细化用况细化 用况细化是一个协作，可用于对系统用况模型中的用况进行用况细化是一个协作，可用于对系统用况模型中的用况进行精化。换言之，用况细化将一些变化局部到对应的用况中，通精化。换言之，用况细化将一些变化局部到对应的用况中，通过分析类之间的协作，规约用况的行为是如何实现的。过分析类之间的协作，规约用况的行为是如何实现的。 银行客户银行客户1:标识身份标识身份2:要求取款要求取款人机接口人机接口人机接口人机接口划拨取款划拨取款帐目帐目5:交钱交钱3:验证并划拨验证并划拨4:自动取款自动取款协作协作注意注意:精化了精化了usecase和相关的特殊需求。和相关的特殊需求。 其次其次, ,给出了分析模型的语法给出了分析模型的语法, ,用于表达该抽象层上的系统模用于表达该抽象层上的系统模 型。型。 分析模型是对需求的一种精化，给出了在这一抽象层上的系分析模型是对需求的一种精化，给出了在这一抽象层上的系统结构。统结构。 AnalysismodelAnalysisSystemAnalysisPackageAnalysisClassUse-CaseRealization-Analysis*1AnalysisSystemdenotesthetop-levelpackageofthemodel. 最后，给出了实施系统分析的活动，支持开发人员系统化地最后，给出了实施系统分析的活动，支持开发人员系统化地使用用以上三个术语所表达的信息，建立系统分析模型。使用用以上三个术语所表达的信息，建立系统分析模型。序序号号输入输入活动活动执行者执行者输出输出1用用况况模模型型、补补充充需需求求、业业务务模模型型或或领领域域模模型型、体系结构描述体系结构描述用况模型角度用况模型角度体体 系系 结结 构构分析分析体体 系系 结结 构构设计者设计者分分析析包包概概述述、分分析析类类概概述述、体体系系结结构构描描述述分析模型角度分析模型角度2用用况况模模型型、补补充充需需求求、业业务务模模型型或或领领域域模模型型、体系结构描述体系结构描述分析模型角度分析模型角度分析用况分析用况用用 况况 工工 程程师师用用况况实实现现-分分析析、分分析析类类概述概述3用用况况实实现现-分分析析、分分析析类类概概述述对类分析对类分析构构 件件 工工 程程师师分析类分析类完成完成4系系统统体体系系结结构构描描述述分分析析模型角度模型角度、分析包、分析包概述概述对对 包包 进进 行行分析分析构构 件件 工工 程程师师分析包分析包完成完成第二点第二点: :关于分析模型视角下的体系结构描述关于分析模型视角下的体系结构描述 基于基于RUPRUP的特征的特征- -以体系结构为中心，分析的目标之二是建以体系结构为中心，分析的目标之二是建立系统分析模型视角下的体系结构描述。立系统分析模型视角下的体系结构描述。 该描述表达了在体系结构方面具有重要意义的元素，包括该描述表达了在体系结构方面具有重要意义的元素，包括包之间的依赖包之间的依赖和那些具有较多关联的分析类。和那些具有较多关联的分析类。 可见，分析模型视角下的体系结构描述将体系结构方面的可见，分析模型视角下的体系结构描述将体系结构方面的一些变化局部到一些依赖和分析类的关联上。一些变化局部到一些依赖和分析类的关联上。基本原则：基本原则：向向“稳定稳定”的的包包进行依赖！进行依赖！第三点第三点: Use Case: Use Case模型与分析模型的比较模型与分析模型的比较 Use-Case Model Analysis ModelUse-Case Model Analysis Model 使用客户语言来描述的；使用客户语言来描述的； 使用开发者语言来描述的；使用开发者语言来描述的； 给出的是系统对外的视图；给出的是系统对外的视图； 给出的是系统对内的视图；给出的是系统对内的视图； 使用使用use casesuse cases 予以结构化予以结构化 使用衍型类予以结构化的，使用衍型类予以结构化的， 的的, ,但给出的是外部视角但给出的是外部视角 但给出的是内部视角下的但给出的是内部视角下的 下的系统结构；下的系统结构； 系统结构；系统结构； 可以作为客户和开发者之可以作为客户和开发者之 可以作为开发者理解系统可以作为开发者理解系统 间关于间关于 “系统应做什么、系统应做什么、 如何勾画、如何设计和如如何勾画、如何设计和如何何 不应做什么不应做什么”的契约；的契约； 实现的基础；实现的基础； 需求之间可能存在一些冗需求之间可能存在一些冗 在需求之间不应存在冗余、在需求之间不应存在冗余、 余、不一致和冲突等问题；余、不一致和冲突等问题； 不一致和冲突等问题；不一致和冲突等问题； Use-CaseModelAnalysisModel 捕获的是系统功能，包括捕获的是系统功能，包括 给出的是细化的系统功能给出的是细化的系统功能, , 在体系结构方面具有意义在体系结构方面具有意义 包括在体系结构方面具有包括在体系结构方面具有 的功能；的功能； 意义的功能；意义的功能； 定义了一些进一步需要在定义了一些进一步需要在 定义了定义了use caseuse case模型中模型中 分析模型中予以分析的分析模型中予以分析的use use 每一个每一个use caseuse case的细化。的细化。 casecase。 第四点第四点: :分析模型对以后工作的影响分析模型对以后工作的影响 如果把分析模型作为以后设计活动的基本输入，那么对设如果把分析模型作为以后设计活动的基本输入，那么对设计模型以及相应的体系结构描述将在产生以下及方面影响：计模型以及相应的体系结构描述将在产生以下及方面影响： 对设计中子系统的影响对设计中子系统的影响 分析包一般将影响设计子系统的结构。一般情况下，分析包分析包一般将影响设计子系统的结构。一般情况下，分析包和服务包应分别对应设计中特定应用层的子系统和应用共享层和服务包应分别对应设计中特定应用层的子系统和应用共享层的子系统，如下图所示：的子系统，如下图所示：特别地，在许多情况下，服务包和对应的服务子系统之间是一特别地，在许多情况下，服务包和对应的服务子系统之间是一对一（同构）的。对一（同构）的。分析包分析包分析包分析包服务包服务包子系统子系统子系统子系统子系统子系统服务包服务包子系统子系统特定应用层特定应用层应用共享层应用共享层影响影响 对设计类的影响对设计类的影响 分析包可以作为类设计时的规格说明。即分析包可以作为类设计时的规格说明。即: : 一方面，分析类以及它们的责任、属性和关系应是进行类一方面，分析类以及它们的责任、属性和关系应是进行类的操作、属性和关系设计的逻辑输入。的操作、属性和关系设计的逻辑输入。 另一方面，在对具有不同衍型的分析类进行设计时，需要另一方面，在对具有不同衍型的分析类进行设计时，需要不同的技术和技能，例如不同的技术和技能，例如: : - -实体类的设计，常常需要使用数据库技术实体类的设计，常常需要使用数据库技术; ; - -边界类的设计常常需要使用用户界面技术，当在考虑数边界类的设计常常需要使用用户界面技术，当在考虑数据库技术和用户界面技术时，有关分析类的大多数特殊需求，据库技术和用户界面技术时，有关分析类的大多数特殊需求，例如永久性、并发等，应由对应的设计类予以处理。例如永久性、并发等，应由对应的设计类予以处理。 对对Use caseUse case细化细化 设计设计 的影响的影响 Use caseUse case细化细化 分析分析 对对Use caseUse case细化细化 设计设计 将有两个方面作用将有两个方面作用: : 一是它们有助于为一是它们有助于为use caseuse case创建更精确的规格说明。其中创建更精确的规格说明。其中可采用状态图或活动图等，把每一个可采用状态图或活动图等，把每一个use caseuse case描述为分析类之描述为分析类之间的一个协作，替代间的一个协作，替代use-case use-case 模型中每一个模型中每一个use caseuse case的事件的事件流描述，这样就对系统需求产生了一个可理解的形式规约。流描述，这样就对系统需求产生了一个可理解的形式规约。 一是当对一是当对 use casesuse cases进行设计时，进行设计时，Use-caseUse-case细化细化 分析分析 可作可作为其输入。为其输入。 这有助于这有助于: : 标识参与标识参与Use-caseUse-case细化细化 设计设计 中的设计类。中的设计类。 确定确定Use-caseUse-case细化细化 设计设计 中中, ,依据所考虑的技术（数依据所考虑的技术（数 据库技术，用户界面技术），需要处理的需求据库技术，用户界面技术），需要处理的需求, ,即在即在 Use-caseUse-case细化细化 分析分析 中所捕获的大多数特殊需求。中所捕获的大多数特殊需求。总之，设计中应尽量地保持分析模型的结构。总之，设计中应尽量地保持分析模型的结构。 对创建设计模型视角下体系结构描述的影响对创建设计模型视角下体系结构描述的影响 分析模型视角下的体系结构描述，可以作为创建设计模型视分析模型视角下的体系结构描述，可以作为创建设计模型视角下体系结构描述的输入。其中，通过关注跟踪依赖，不但可角下体系结构描述的输入。其中，通过关注跟踪依赖，不但可以使不同视图中的元素相互跟踪，而且还可以使在体系结构方以使不同视图中的元素相互跟踪，而且还可以使在体系结构方面有意义的想法几乎面有意义的想法几乎“平稳平稳”地地“流经流经”不同的模型。不同的模型。？设计模型设计模型形成形成需求分析模型需求分析模型设设计计需求分析需求分析4)、设计的目标及其途径、设计的目标及其途径(1)目标：目标：设计的基本输入是分析的结果设计的基本输入是分析的结果,定义满足分析所需要的结构定义满足分析所需要的结构.部署模型部署模型体系结构描述体系结构描述（部署模型）（部署模型）use-case细化细化设计设计设计类设计类接口接口设计子系统设计子系统体系结构描述体系结构描述（设计模型）（设计模型）(2) (2) 实现实现设计目标的基本途径设计目标的基本途径 实现实现需求分析层到设计层的映射，即从软件开发的角需求分析层到设计层的映射，即从软件开发的角度度- -实现第三次抽象。如同实际问题层到需求获取层一样实现第三次抽象。如同实际问题层到需求获取层一样, ,其中至少涉及以下其中至少涉及以下3 3个问题：个问题： 如何定义设计层，即给出该层的术语；如何定义设计层，即给出该层的术语； 如何确定模型表示工具；如何确定模型表示工具； 如何映射。如何映射。设计层的术语设计层的术语-回答第一个问题回答第一个问题设计类（设计类（Design classDesign class） 一个设计类是对系统实现中一个类或类似构造的一个无缝一个设计类是对系统实现中一个类或类似构造的一个无缝抽象。设计类的主要特征为：抽象。设计类的主要特征为： 设计类可细化为多个接口，如下图所示：设计类可细化为多个接口，如下图所示：DesignClassOperationsAttributesRelationshipsMethodsImplementationrequirementsisactive:true,false*Interface realizeNote:activeclass:itsobjectsmaintainownthreadofcontrolandrunconcurrentlywithotheractiveobjects.用况细化用况细化 设计设计 用况细化用况细化 设计设计 是设计模型中的一个协作，其中，使用设计是设计模型中的一个协作，其中，使用设计类及其对象，描述一个特定用况是如何予以细化的，如何执类及其对象，描述一个特定用况是如何予以细化的，如何执行的。行的。 表达协作的工具可以是类图、交互图和正文事件流等。表达协作的工具可以是类图、交互图和正文事件流等。 设计子系统设计子系统 设计子系统设计子系统提供了一种组织设计制品的手段，成为一些可提供了一种组织设计制品的手段，成为一些可以更易管理的部分。以更易管理的部分。 DesignClass*Interface realizeDesignSubsystemUseCaserealization-Design* 设计子系统和分析模型之间的关系设计子系统和分析模型之间的关系: : 分析模型中的包结构分析模型中的包结构, ,一般对应设计子系统的层次结构。特一般对应设计子系统的层次结构。特别是别是, ,分析模型中的服务包一般对应设计子系统层次结构低层分析模型中的服务包一般对应设计子系统层次结构低层上的服务子系统上的服务子系统. .如下图所示。如下图所示。 在应用中，一般通过使用服务子系统，把一些变化局部化在应用中，一般通过使用服务子系统，把一些变化局部化到不同的服务子系统中，形成一些封装相应变化的单个服务。到不同的服务子系统中，形成一些封装相应变化的单个服务。对应对应分析模型中的服务包分析模型中的服务包对应的服务子系统对应的服务子系统接口（接口（InterfaceInterface） 接口用于规约由设计类和设计子系统提供的操作。因此，接口用于规约由设计类和设计子系统提供的操作。因此，一个接口的重要关联是：一个接口的重要关联是：可见，可见，接口提供了一种分离功能的手段，其中使用了与实现接口提供了一种分离功能的手段，其中使用了与实现 中方法对应的操作，因此提供接口的设计类和设计子中方法对应的操作，因此提供接口的设计类和设计子 系统，必须提供细化该接口操作的方法。系统，必须提供细化该接口操作的方法。 子系统之间的大多数接口，对体系结构是有意义的。子系统之间的大多数接口，对体系结构是有意义的。DesignClass*realizeDesignSubsystem*InterfacerealizeDesignmodelDesignSystemDesignSubsystemsDesignClassUse-CaseRealization-Design设计模型、部署模型设计模型、部署模型-回答第二个问题回答第二个问题设计模型设计模型 是设计子系统的层次结构（是设计子系统的层次结构（ hierarchyhierarchy），包含设计），包含设计类、类、 use-case use-case 细化和接口。细化和接口。*1DesignSystemdenotesthetop-levelsubsystemofthemodel.Interface*描述了描述了设计模型的模型的顶层子系子系统是由是由协作作予以表达的予以表达的, ,其中其中使用了使用了设计类和和对象象表达了系统实现中表达了系统实现中子系统子系统和和构件构件的抽象。的抽象。设计模型视角下的体系结构描述，是从设计模型的角度，描设计模型视角下的体系结构描述，是从设计模型的角度，描述那些在体系结构方面具有意义的制品。述那些在体系结构方面具有意义的制品。通常，这些制品包括：通常，这些制品包括：子系统的结构，包括它们的接口以及它们之间的依赖。子系统的结构，包括它们的接口以及它们之间的依赖。注释注释:由于子系统和它们的接口构成了系统的基本结构，因由于子系统和它们的接口构成了系统的基本结构，因此一般来说子系统的结构对体系结构而言是非常有意义的。此一般来说子系统的结构对体系结构而言是非常有意义的。DesignSubsystemInterfacerealizeDesignSubsystemDesignSubsystemrealize对体系结构有意义设计类，如下所示：对体系结构有意义设计类，如下所示：注释注释:其中类其中类A和类和类B存在一个关联，使设计子系统存在一个关联，使设计子系统X和设计和设计子系统子系统B之间具有依赖关系，因此类之间具有依赖关系，因此类A和类和类B是对体系是对体系结构具有意义的类。结构具有意义的类。设计子系统设计子系统X接接口口依赖依赖设计子系统设计子系统YAB设设计计子子系系统统Z对体系结构有意义的设计类，一般包括对体系结构有意义的设计类，一般包括:-对体系结构有意义的分析类所对应那些设计类对体系结构有意义的分析类所对应那些设计类;-具有一般性、核心的主动类具有一般性、核心的主动类;-表达通用设计机制的设计类，以及表达通用设计机制的设计类，以及-与以上这些设计类相关的其他设计类。与以上这些设计类相关的其他设计类。对于这样一些对体系结构有意义的设计类而言，一般只考对于这样一些对体系结构有意义的设计类而言，一般只考虑抽象类，而不考虑它的子类，除非该子类展现了某些与其虑抽象类，而不考虑它的子类，除非该子类展现了某些与其抽象类不同的行为，并对体系结构有意义。抽象类不同的行为，并对体系结构有意义。 Use-case Use-case 细化细化设计设计 某些重要的、关键功能的、必须在软件生存周期早期予以开某些重要的、关键功能的、必须在软件生存周期早期予以开发的发的Use-case Use-case 细化细化设计设计。这样的这样的Use-case Use-case 细化细化设计设计，涉及许多设计类，也可能涉，涉及许多设计类，也可能涉 及许多子系统，或涉及以前提及到的关键设计类。及许多子系统，或涉及以前提及到的关键设计类。通常，通常， Use-case Use-case 细化细化设计设计对应对应use-caseuse-case模型视觉的体系模型视觉的体系 结构中的结构中的 use casesuse cases，对应分析模型视觉的体系结构中的，对应分析模型视觉的体系结构中的 use casesuse cases细化细化分析分析。部署模型（部署模型（Deployment ModelDeployment Model）部署模型是一个对象模型，描述了系统的物理分布，即怎部署模型是一个对象模型，描述了系统的物理分布，即怎样把功能分布于各个节点（样把功能分布于各个节点（nodesnodes）。）。可见可见, ,部署模型本身展现了软件体系结构和系统体系结构部署模型本身展现了软件体系结构和系统体系结构（硬件）之间的一个映射（硬件）之间的一个映射（mapping mapping ）。）。DeploymentModelNode*关于部署模型的几点说明：关于部署模型的几点说明： 部署模型包含一些节点及节点之间的关系，其中每一个节部署模型包含一些节点及节点之间的关系，其中每一个节 点表达一个计算资源，常常是处理器或类似的硬件设备。点表达一个计算资源，常常是处理器或类似的硬件设备。 节点功能是由部署在该结点上构件所定义的；节点之间的节点功能是由部署在该结点上构件所定义的；节点之间的 关系是由节点之间的通讯手段表达的，例如关系是由节点之间的通讯手段表达的，例如internetinternet、 intranetintranet和和 总线等。总线等。在实际应用中部署模型可以描述多个不同的网络配置，包括在实际应用中部署模型可以描述多个不同的网络配置，包括 测试配置和仿真配置。测试配置和仿真配置。部署模型视角下的体系结构描述部署模型视角下的体系结构描述从部署模型的视角，描述该模型中那些对体系结构有意义从部署模型的视角，描述该模型中那些对体系结构有意义的制品。但由于部署模型是十分重要的模型，因此应描述其的制品。但由于部署模型是十分重要的模型，因此应描述其体系结构视觉下的所有方面，包括体系结构视觉下的所有方面，包括节点节点与与构件构件( (实现期间所实现期间所发现的那些构件发现的那些构件) )之间的映射。之间的映射。 工作流工作流-回答第三个问题回答第三个问题实施准备实施准备：开始设计时，应更深入地理解以下问题：开始设计时，应更深入地理解以下问题： - -非功能需求；非功能需求； - -有关对程序设计语言的限制（有关对程序设计语言的限制（constrainsconstrains）；）； - -数据库技术；数据库技术； - -用况技术；用况技术； - -事务（事务（transactiontransaction）技术等）技术等. . 活动活动1:体系结构设计（体系结构设计（ArchitecturalDesign）目标目标: : 给出设计模型和部署模型，以及这两个模型视觉下的体系给出设计模型和部署模型，以及这两个模型视觉下的体系 结构描述。为此，需要标识：结构描述。为此，需要标识： - - 节点，以及它们的网络配置；节点，以及它们的网络配置； - -子系统，以及它们的接口；子系统，以及它们的接口； - -在体系结构方面具有意义的设计类，例如主动类。在体系结构方面具有意义的设计类，例如主动类。 - -设计机制，它们处理共性需求，例如，在分析期间所捕获设计机制，它们处理共性需求，例如，在分析期间所捕获 的有关分析类、的有关分析类、 use-caseuse-case细化细化分析分析的永久性、分布性的永久性、分布性 以及性能等方面的特殊需求。以及性能等方面的特殊需求。ArchitectUseCasemodelSupplementaryRequirementsArchitectureDescriptionviewoftheAnalysismodelArchitecturalDesign体系结构设计的输入和结果体系结构设计的输入和结果（Theinputandresultofarchitecturaldesign）AnalysismodelSubsystemoutlinedInterfaceoutlinedArchitectureDescriptionviewsofthedesignanddeploymentmodelDeploymentModeloutlinedDesignclassoutlined任务任务1:标识节点和它们的网络配置标识节点和它们的网络配置 标识需要涉及的节点以及它们的能力（处理能力和内存标识需要涉及的节点以及它们的能力（处理能力和内存 规模）；规模）； 标识节点之间的连接（标识节点之间的连接（connectionsconnections）类型）类型, ,以及使用以及使用 的通讯协议；的通讯协议； 标识这些连接和通讯协议的特征，如宽带，可用性和标识这些连接和通讯协议的特征，如宽带，可用性和 质量等；质量等； 标识需要的冗余处理能力、失败模式、移植处理（标识需要的冗余处理能力、失败模式、移植处理（process process migration migration ）以及数据备份等。）以及数据备份等。 以上称为网络配置以上称为网络配置. .-网络配置网络配置经常对软件的体系结构具有很大影响经常对软件的体系结构具有很大影响. .网络配置的基本途径网络配置的基本途径：了解网络配置模式了解网络配置模式 通常使用三元模式：客户端（用户交互）、数据库功能通常使用三元模式：客户端（用户交互）、数据库功能 以及业务以及业务/ /应用逻辑。而应用逻辑。而C/SC/S模式是一种特殊的情况。模式是一种特殊的情况。了解节点以及它们连接的限制和可能性了解节点以及它们连接的限制和可能性, ,而而后就可以考虑使用后就可以考虑使用 有关的技术，例如有关的技术，例如ORBORB（ 对象请求代理）和数据复制服务器对象请求代理）和数据复制服务器 等，来实现系统的分布。其中等，来实现系统的分布。其中, ,在进行网络节点之间的功能在进行网络节点之间的功能 分布时分布时, ,一般会需要一些主动类。一般会需要一些主动类。期间，还可能需要为测试、仿真等来配置网络，这些配置很可期间，还可能需要为测试、仿真等来配置网络，这些配置很可能使我们开始考虑为什么如此在网络节点上来分布系统功能。能使我们开始考虑为什么如此在网络节点上来分布系统功能。任务任务2:标识子系统和它们的接口标识子系统和它们的接口设计子系统设计子系统提供了一种将设计模型组织成一些可管理部提供了一种将设计模型组织成一些可管理部 分（分（piecespieces）的手段。）的手段。. .一般情况下一般情况下:或通过对设计工作的划分或通过对设计工作的划分,来发现子系统；来发现子系统；在或设计模型的不断进化中，通过对其较在或设计模型的不断进化中，通过对其较大大的结构进行分解时来发现子系统。的结构进行分解时来发现子系统。标识子系统的一些指导：标识子系统的一些指导：第一标识可复用资产第一标识可复用资产发现发现组织内组织内可作为可作为子系统使用的的产品子系统使用的的产品 注注: :这一工作有助于思考设计模型中的复用问题。这一工作有助于思考设计模型中的复用问题。第二第二, , 标识应用子系统标识应用子系统 应用子系统可分为二个层次应用子系统可分为二个层次: :application-specificlayersapplication-generallayersMiddlewarelayerSystem-softwarelayer第一步第一步: :基于分析期间存在的分析包结构，发现其中有哪些分基于分析期间存在的分析包结构，发现其中有哪些分 析包可以作为设计模型中的子系统。析包可以作为设计模型中的子系统。BuyersInvoiceManagementanalysispackageAccountManagementanalysispackageBuyersInvoiceManagementdesignsubsystemAccountManagementdesignsubsystemtracetraceAnalysisModelDesignModel例如：基于已有的分析包来发现设计子系统例如：基于已有的分析包来发现设计子系统 特别地特别地, ,应将分析期间所形成的那些服务包，标识为服务子应将分析期间所形成的那些服务包，标识为服务子系统系统, ,以避免破坏提供这些服务的那个以避免破坏提供这些服务的那个/ /些系统的结构。些系统的结构。 对应对应分析模型中的服务包分析模型中的服务包对应的服务子系统对应的服务子系统 一个分析包的一部分（一个分析包的一部分（PartPart）是否可以被其它多个子系统）是否可以被其它多个子系统共享和复用。如果可以的话，就应对该分析包所对应的子系统进共享和复用。如果可以的话，就应对该分析包所对应的子系统进行分解。行分解。 显然这是一个与设计有关的问题显然这是一个与设计有关的问题! ! 第二步第二步: :针对针对以上初始标识的子系统，考虑一些需要处理的与以上初始标识的子系统，考虑一些需要处理的与系统设计、系统设计、 实现以及部署中有关问题，以期对之进行精化。实现以及部署中有关问题，以期对之进行精化。例如例如: : 分析包分析包A设计子系统设计子系统2部分部分A1注解：A1可以被设计子系统2和3共享分析包分析包跟踪精化结果精化结果设计子系统设计子系统1设计子系统设计子系统3共享子系统共享子系统初始标识初始标识的子系统的子系统 分析包中是否存在某些部分分析包中是否存在某些部分, ,它它们可复用已有的可复用已有的软件件产品品, ,例如例如中中间件或其他已有的系件或其他已有的系统/ /软件子系件子系统. .如果存在的如果存在的话, ,就就应把把这些些部分的功能分派部分的功能分派给相相应的的软件件产品品. . 如果分析包的某些部分可由如果分析包的某些部分可由组织的的遗产系系统所替代，那么就所替代，那么就应把把该遗产系系统“封装封装”为一个子系一个子系统，并建立，并建立该包所包所对应的子系的子系统与封装后的那个子系与封装后的那个子系统之之间的依的依赖。如果分析包并不反映一个合适的工作划分，那么就要如果分析包并不反映一个合适的工作划分，那么就要对该包所包所对应的子系的子系统进行行调整，形成一个新的子系整，形成一个新的子系统结构。构。如果以前的分析包没有如果以前的分析包没有给出到出到节点的部署方案，那么，点的部署方案，那么，为了了处理部署理部署问题，就有可能将，就有可能将对应的的设计子系子系统进一步分解成一步分解成为一些一些更小的子系更小的子系统，以此最小化网，以此最小化网络流量等。流量等。第三第三,标识中间件和系统标识中间件和系统/软件子系统软件子系统中间件和产品中间件和产品/ /子系统是一个系统的基础。选择并集成软件产子系统是一个系统的基础。选择并集成软件产品，是初始阶段和精化阶段的品，是初始阶段和精化阶段的2 2个基本问题。其中：个基本问题。其中：应确确认所所选择的的软件件产品是否适合系品是否适合系统体系体系结构；构； 应确确认它它们是否提供了一种成本有效的系是否提供了一种成本有效的系统实现。application-specific layersapplication-general layersMiddlewarelayerSystem-softwarelayer例如例如:Java.appletJava.awtWebBrowserTCP/IPJava.VirtualMachineJava.miMiddlewarelayerSystem-softwarelayer其中：其中：Java中间件层提供了平台无关的、图形化的用户接中间件层提供了平台无关的、图形化的用户接口口(java.awt)，并分布了对象计算，并分布了对象计算(java.rmi).该图没有显示该图没有显示子系统的依赖，但说明了如何将子系统的依赖，但说明了如何将java服务组织为中间件层中服务组织为中间件层中的子系统。的子系统。第四，定义子系统依赖（第四，定义子系统依赖（DefiningSubsystemDependencies）-如果了解子系统的内容如果了解子系统的内容, ,那么就应根据内容来定义子系统那么就应根据内容来定义子系统 之间的依赖。例如之间的依赖。例如: :Java.appletJava.awtWebBrowserTCP/IPJava.VirtualMachineJava.miMiddlewarelayerSystem-softwarelayerBuyersInvoiceManagementPaymentScheduleManagementAccountManagementapplication-specific layersapplication-general layers-如果开始不了解子系统的内容如果开始不了解子系统的内容, ,那么就应分析设计子系统那么就应分析设计子系统 所对应的那些分析包之间的依赖。这些依赖很可能成为所对应的那些分析包之间的依赖。这些依赖很可能成为 设计模型中子系统之间的依赖。设计模型中子系统之间的依赖。 -如果在定义子系统的依赖中如果在定义子系统的依赖中, ,使用了子系统之间的接口，使用了子系统之间的接口， 那么这些依赖就应针对接口而不针对子系统本身。那么这些依赖就应针对接口而不针对子系统本身。设计子系统设计子系统A接接口口依赖依赖设计子系统设计子系统B设计子系统设计子系统C例如例如:Java.appletJava.awtWebBrowserTCP/IPJava.VirtualMachineJava.miMiddlewarelayerSystem-softwarelayerBuyersInvoiceManagementPaymentScheduleManagementAccountManagementapplication-specific layersapplication-general layers第五，标识子系统接口（第五，标识子系统接口（IdentifyingSubsystemInterfaces）由子系统所提供的接口，定义了对外可访问的一些操作。由子系统所提供的接口，定义了对外可访问的一些操作。这些接口或是由该子系统中的类提供的，或是由该子系统中这些接口或是由该子系统中的类提供的，或是由该子系统中其它子系统提供的。其它子系统提供的。 首先首先,要考虑以上发现的那些子系统之间的依赖：要考虑以上发现的那些子系统之间的依赖：一般一般 地地, ,当一个子系统具有一个指向它的依赖，可能就需要当一个子系统具有一个指向它的依赖，可能就需要 提供一个接口；提供一个接口； 其次其次, ,如果一个子系统存在一个所跟踪的分析包，那么如果一个子系统存在一个所跟踪的分析包，那么 就要基于该包对外所引用的任意分析类，来发现该子就要基于该包对外所引用的任意分析类，来发现该子 系统的一些后选的接口。系统的一些后选的接口。例如：例如：Accounts Accounts 服务包包括一个被该包之外引用的分析类服务包包括一个被该包之外引用的分析类 Account TransfersAccount Transfers， 由此就可以标识一个初始接口由此就可以标识一个初始接口 TransfersTransfers，该接口由设计模型中的那个对应的，该接口由设计模型中的那个对应的Accounts Accounts 服务子系统所提服务子系统所提供。供。 AnalysisModelDesignModelAccountTransfersAccountAccounthistoryservicepackageAccountsA class referencingAccountTransfersfrom the outsideservicesubsystemAccountstraceTransfersImpliescandidate使用这一途径，可初始地标识设计模型中上使用这一途径，可初始地标识设计模型中上2 2层的一些接口层的一些接口, ,即即: :设计子系统设计子系统A设计子系统B设计子系统C特定应用层特定应用层一般应用层一般应用层 注注: :对于下二层对于下二层( (中间件层和系统软件层中间件层和系统软件层) )的接口，标识其的接口，标识其接口相对要简单一些。因为在这二个层次上的子系统，封装接口相对要简单一些。因为在这二个层次上的子系统，封装了软件产品，而且这样的产品常常具有某种形式的、事先已了软件产品，而且这样的产品常常具有某种形式的、事先已定义的一些接口。定义的一些接口。通过接口通过接口,可以精化子可以精化子系统间的依赖；系统间的依赖；只标识接口是不充分只标识接口是不充分的，还必须标识每一接的，还必须标识每一接口中需要定义的那些操口中需要定义的那些操作。作。（如何做？参见（如何做？参见designausecase一节）一节）当完成任务当完成任务2 2时，就可形成系统的初始顶层设计时，就可形成系统的初始顶层设计- -系统的子系统系统的子系统结构，如下所示结构，如下所示: : 特定应用层特定应用层一般应用层一般应用层(可可被被特特定定应应用用层层共共享享)中间件层中间件层系统软件层系统软件层任务任务3:标识在体系结构方面具有意义的设计类和它们的接口标识在体系结构方面具有意义的设计类和它们的接口实际工作中，往往是在软件生存周期的早期来标识在体系结实际工作中，往往是在软件生存周期的早期来标识在体系结 构方面有意义的设计类，但是此时没有标识更多的类，也没构方面有意义的设计类，但是此时没有标识更多的类，也没 有探索其更多的细节。有探索其更多的细节。注注:在以后的类设计中在以后的类设计中,应应：标识大多数设计类，并基于标识大多数设计类，并基于use-case设计活动的结果，设计活动的结果，对其进行精化。对其进行精化。为了证明设计类，还要做一些工作，例如要验证一个设为了证明设计类，还要做一些工作，例如要验证一个设计类是否参与了一个计类是否参与了一个use-cases细化，否则这样的设计类就细化，否则这样的设计类就是不必要的。是不必要的。第一第一:标识在体系结构方面有意义的设计类标识在体系结构方面有意义的设计类.根据在体系结构方面具有意义的分析类，可以初始地标识根据在体系结构方面具有意义的分析类，可以初始地标识出这样的一些设计类。例如：出这样的一些设计类。例如：并可以使用这些分析类之间的关系，直接标识出相对应并可以使用这些分析类之间的关系，直接标识出相对应设计类之间的一组关系。设计类之间的一组关系。InvoiceTraceAnalysismodelDesignmodelTheInvoicedesignclassisinitiallyoutlinedfromtheInvoiceentityclass.第二第二: :标识主动类（标识主动类（Identifying Active ClassesIdentifying Active Classes） 主动类的标识主动类的标识 一般应该考虑系统的一些并发需求，例如：一般应该考虑系统的一些并发需求，例如： 关于系统在节点上的分布（关于系统在节点上的分布（ distributiondistribution）需求）需求 为了支持这一分布，处理节点之间的通讯，可能每个节点至为了支持这一分布，处理节点之间的通讯，可能每个节点至少需要一个主动对象少需要一个主动对象 首先，要考虑主动对象的生存周期，考虑主动对象应如何通首先，要考虑主动对象的生存周期，考虑主动对象应如何通讯、同步和共享信息。讯、同步和共享信息。 继之，再将它们分配到部署模型的节点。继之，再将它们分配到部署模型的节点。 其中应考虑节点其中应考虑节点的容量，例如处理器的数目、内存的规模；考虑连接的特征，的容量，例如处理器的数目、内存的规模；考虑连接的特征，例如它们的带宽和可用性。对此，一个基本规则是例如它们的带宽和可用性。对此，一个基本规则是: : 认真控制网络通信量认真控制网络通信量. .因为它对系统所要求的计算资源（包因为它对系统所要求的计算资源（包括软件和硬件）具有重要影响括软件和硬件）具有重要影响. .关于系统启动、终止、激活以及死锁避免、节点再配置等关于系统启动、终止、激活以及死锁避免、节点再配置等需求需求. . 针对以上需求针对以上需求, ,也需要一些主动对象来处理之。也需要一些主动对象来处理之。 主动类的描述主动类的描述-开始时的概括描述开始时的概括描述:以分析结果和部署模型作为输入，然后通过主动类以分析结果和部署模型作为输入，然后通过主动类, ,把分析把分析类（或其部分）所对应的设计映射到节点上类（或其部分）所对应的设计映射到节点上, ,而后才能给出主而后才能给出主动类的概要描述，其中动类的概要描述，其中:可以使用以前标识的子系统，或可以使用以前标识的子系统，或需要对系统分解进行精化。需要对系统分解进行精化。例如例如:使用分析类来概括描述主动类使用分析类来概括描述主动类该例使用分析类来概要描述主动类该例使用分析类来概要描述主动类“支付请求处理支付请求处理”。在对分。在对分析类析类“定单处理定单处理”和和“定单确认定单确认”进行设计时，首先必须考虑进行设计时，首先必须考虑是否将它们主要部分分配到节点是否将它们主要部分分配到节点“采购员服务采购员服务”上（这是一个上（这是一个设计决策问题），而后再考虑是否标识一个主动类设计决策问题），而后再考虑是否标识一个主动类“支付请求支付请求处理处理”，用于封装对这一主要部分的控制线程。，用于封装对这一主要部分的控制线程。:采购者服务采购者服务:支付请求处理支付请求处理定单处理定单处理定单确认定单确认分析分析类outlines 注注意意: :对对于于表表达达一一个个关关键键过过程程的的主主动动类类，是是否否将将其其作作为为一一个个候候选选的的可可执执行行构构件件，这这是是实实现现中中的的任任务务。因因此此，如如果果在在实实现现中中把把这这样样的的主主动动类类作作为为一一个个可可执执行行构构件件，那那么么这这一一步步把把主主动动对对象象分分配配到到一一个个节节点点上上，就就是是实实现现期期间间把把可可执执行行构构件件分分配配到到该该节节点点的一个重要输入。的一个重要输入。注意注意： 其其中中如如果果把把一一个个子子系系统统整整个个分分配配到到一一个个节节点点时时，那那么么该该子子系统的所有约束就应一起分布给该节点上的一个可执行构件。系统的所有约束就应一起分布给该节点上的一个可执行构件。任务任务4:标识处理一般性的设计机制标识处理一般性的设计机制（IdentifyingGeneraldesignmechanism） 首先首先, ,应研究共性需求，例如在分析期间所标识的有关用况细化应研究共性需求，例如在分析期间所标识的有关用况细化 分析分析 中对设计类的特殊需求；中对设计类的特殊需求； 继之，应确定如何处理它们，给出可用的设计和实现技术，从而继之，应确定如何处理它们，给出可用的设计和实现技术，从而就得到一组可处理共性的设计机制。就得到一组可处理共性的设计机制。 这样的控制机制本身可以表现为设计类，表现为协作，甚至可以这样的控制机制本身可以表现为设计类，表现为协作，甚至可以表现为子系统。表现为子系统。 设计机制所处理的共性需求，常常包括：设计机制所处理的共性需求，常常包括： 永久性；永久性；（Persistency） 透明对象的分布；透明对象的分布；（Transparentobjectdistribution） 安全特征；安全特征；（Securityfeatures） 错误检测与揭示；错误检测与揭示；（Errordetectionandrecovery） 事务管理等。事务管理等。 （Transactionmanagement）例例1 1：标识处理透明对象分布的设计机制标识处理透明对象分布的设计机制 在网络银行软件中，在网络银行软件中，“发票发票”显然是一个分布对象为了显然是一个分布对象为了实现该对象的分布，可以把每个需要分布到个节点的类，实现该对象的分布，可以把每个需要分布到个节点的类，作为作为JavaJava抽象类抽象类Java.rmi.UnicastRemoteObjectJava.rmi.UnicastRemoteObject的一个子的一个子类，支持远程消息调用（类，支持远程消息调用（RMIRMI），从而形成了一个处理分），从而形成了一个处理分布对象的设计机制，如下：布对象的设计机制，如下： 显然这一设计机制体现为设计类的一种泛化结构。显然这一设计机制体现为设计类的一种泛化结构。UnicastRemoteObject“a distributed class”设计机制：透明对象的分布设计机制：透明对象的分布例例2：标识事务管理的设计机制：标识事务管理的设计机制为事务管理设计一个相应的机制，一般使用用况细化中一为事务管理设计一个相应的机制，一般使用用况细化中一个具有共性的协作。例如个具有共性的协作。例如:假定在体系结构描述中，使用用况及其它们的关系标识了假定在体系结构描述中，使用用况及其它们的关系标识了参与者创建一个交易对象（例如定单或发票），并将其发送参与者创建一个交易对象（例如定单或发票），并将其发送给另一参与者。给另一参与者。显然显然,可以把这标识为一个具有共性的事务管理，并且该事可以把这标识为一个具有共性的事务管理，并且该事务管理的模式为：务管理的模式为：当采购员决定定货或采购服务时，调用用况当采购员决定定货或采购服务时，调用用况“订购货物或订购货物或服务服务”。该用况允许采购员向销售员来指定并自动发送一个。该用况允许采购员向销售员来指定并自动发送一个定单；定单；当采购员决定将发票送给一个采购员时，调用用况当采购员决定将发票送给一个采购员时，调用用况“采购采购员获取发票员获取发票”,该用况自动地将发票发送给采购员。该用况自动地将发票发送给采购员。对这样一种具有一般性的行为，可以采用如下图所示的协对这样一种具有一般性的行为，可以采用如下图所示的协作，将其设计为一种事务管理设计机制。作，将其设计为一种事务管理设计机制。:TradeObjectCreationUI:SenderProcessing:ReceiverProcessing:TradeObject:TradeObjectPresentationUI1:sendtradeobject2:createTradeObject()4:receiveTradeObject(tradeObjectStub)6:presentTradeObject(tradeObjectStub)3:new()5:getInfo()7:presentTradeObject设计机制：事务管理设计机制：事务管理通过一个通讯图，表明交易对象的创建发送接受通过一个通讯图，表明交易对象的创建发送接受 其中：其中：首先，对象首先，对象“TradeObjectCreationUI”接受来自参与者接受来自参与者“Senderactor”的信息的信息,作为创建交易对象作为创建交易对象“TradeObject”的输的输入；入；接之，对象接之，对象“TradeObjectCreationUI”请求对象请求对象SenderProcessing来创建该交易对象来创建该交易对象TradeObject.而后而后,对象对象SenderProcessing请求创建对应的类请求创建对应的类“TradeObject”来创建一个实例来创建一个实例.接之，对象接之，对象“InvoiceProcessing”向对象向对象“ReceiverProcessing”提交该交易对象的引用提交该交易对象的引用.当需要时，对象当需要时，对象“ReceiverProcessing”可以查询对象可以查询对象“TradeObject”，获取更多的信息，获取更多的信息.对象对象“ReceiverProcessing”向对象向对象“TradeObjectCreationUI”发送具有更多内容的对象发送具有更多内容的对象“TradeObject”.最后最后,将对象将对象TradeObject提交给接受的参与者。提交给接受的参与者。当当然然在在需需要要时时（例例如如，在在细细化化用用况况“Invoice”时时），可可以以通通过过对对参参与与该该一一般般性性协协作作的的每每一一个个抽抽象象类类目目的的子子类类型型化化，形形成成如下的具体类目：如下的具体类目：TradeObjectCreationUISenderProcessingReceiverProcessingTradeObjectTradeObjectPresentationUISenderReceiverInvoicingUIInvoiceprocessingPaymentRequestProcessingInvoiceInvoicePresentationUISellerBuyer抽象类目的子类型化抽象类目的子类型化以上两个例子是通过使用泛化和协作来创建设计机制的，以上两个例子是通过使用泛化和协作来创建设计机制的，除此之外，还可以使用其它方法，例如模式（模式是参数化除此之外，还可以使用其它方法，例如模式（模式是参数化的协作（例如参数化的类），其中可以通过建立具体类的协作（例如参数化的类），其中可以通过建立具体类（concreteclasses）与参数的关联，来创建具有一般性的）与参数的关联，来创建具有一般性的设计机制。设计机制。在有些情况中，随着用况的细化和设计类的揭示，才能发在有些情况中，随着用况的细化和设计类的揭示，才能发现一些必要的设计机制。但在现一些必要的设计机制。但在RUP的精化阶段，应标识并设的精化阶段，应标识并设计大多数具有一般性的机制。计大多数具有一般性的机制。通过一组机制可以解决一些复杂的设计问题，并使构造阶通过一组机制可以解决一些复杂的设计问题，并使构造阶段期间多数情况的细化变得相当简单和直接。段期间多数情况的细化变得相当简单和直接。至此至此,完成了系统体系结构设计，除形成部署模型完成了系统体系结构设计，除形成部署模型概述概述和该和该模型视角下的体系结构描述外，还形成了设计模型中如下形模型视角下的体系结构描述外，还形成了设计模型中如下形式的设计系统，即形成了系统的顶层设计式的设计系统，即形成了系统的顶层设计-子系统结构。子系统结构。特定应用层特定应用层一一般般应应用用层层中间件层中间件层系统软件层系统软件层设计机制设计机制设设计计机机制制活动活动2:UseCase的设计的设计目标目标:Use-caseEngineerUseCaseModelSupplementaryRequirementsDesignauseCaseTheinputandresultofuse-casedesign.Thecorrespondinguse-caserealization-analysisintheanalysismodelisanessentialinputtothisactivity.AnalysisModelUse-caserealization-DesignInterfaceoutlinedSubsystemoutlinedDesignclassoutlinedDesignModelDeploymentModel为了实现以上所示的目标，可以采用以下两种方法。为了实现以上所示的目标，可以采用以下两种方法。（1）第一种方法：）第一种方法：标识参与用况细化的设计类标识参与用况细化的设计类首先首先,基于分析模型，研究相应用况细化基于分析模型，研究相应用况细化分析分析中的分析类，中的分析类，来标识细化分析类所需要的设计类，研究相应用况细化来标识细化分析类所需要的设计类，研究相应用况细化分析分析中的特殊需求，来标识细化这些特殊需求所需要的设计类。中的特殊需求，来标识细化这些特殊需求所需要的设计类。这样标识的参与用况细化这样标识的参与用况细化设计设计的设计类，或在体系结构设计的设计类，或在体系结构设计期间已经发现，或在类设计期间予以创建。期间已经发现，或在类设计期间予以创建。继之继之,基于用况的功能，对每一标识的设计类赋予相应的责基于用况的功能，对每一标识的设计类赋予相应的责任。任。最后最后,为该细化创建一个类图，汇聚参与该用况细化的设计为该细化创建一个类图，汇聚参与该用况细化的设计类，并给出类之间的关系。例如：类，并给出类之间的关系。例如：PaymentRequestUIOrderHandlerPaymentSchedulePaymentRequestProcessingOrderConfirmationInvoicePaymentRequestBuyerInvoiceProcessing注：注：有些设计类已经在任务有些设计类已经在任务1中发现，中发现，例如主动类例如主动类 Payment Request Payment Request Processing Processing 和和 Invoice Processing ,Invoice Processing ,它们在不同节点之间传递它们在不同节点之间传递 tradetrade对象，对象，从发出者到一个接受者，例如对象从发出者到一个接受者，例如对象InvoiceInvoice（发票）从（发票）从sellerseller到到buyerbuyer，使系，使系统统 Interbank Interbank 得以运行。得以运行。描述设计对象交互和接口描述设计对象交互和接口 在概述细化用况所需要的设计类的基础上，就应描述在该在概述细化用况所需要的设计类的基础上，就应描述在该用况中这些设计对象是如何交互的。用况中这些设计对象是如何交互的。 这可使用顺序图，其中包括：参与者实例、设计类的对象、这可使用顺序图，其中包括：参与者实例、设计类的对象、以及它们之间传送的消息。以及它们之间传送的消息。 如果该用况存在一些不同的、有区别的流或子流，那么就如果该用况存在一些不同的、有区别的流或子流，那么就应该为每一流创建一个顺序图，这有益于细化得更清晰，有应该为每一流创建一个顺序图，这有益于细化得更清晰，有益于抽取具有一般性、可复用的交互。益于抽取具有一般性、可复用的交互。 首先，应研究对应的用况细化首先，应研究对应的用况细化 分析分析 ，确定是否为了描述设，确定是否为了描述设计对象之间的交互而需要一些新的设计类。例如，为了描述计对象之间的交互而需要一些新的设计类。例如，为了描述设计类之间要求的消息序列，可能就需要填加一些新的设计设计类之间要求的消息序列，可能就需要填加一些新的设计类；而且在某些情况里，当要把用况细化类；而且在某些情况里，当要把用况细化 分析分析 的一个通讯图的一个通讯图转化为初始的、相对应的一个顺序图，也需要增加这样的设转化为初始的、相对应的一个顺序图，也需要增加这样的设计类。计类。 继之，从该用况的一个流开始，一次遍历一个流，描述该继之，从该用况的一个流开始，一次遍历一个流，描述该用况细化中所要求的设计类实例与参与者实例之间的交互。用况细化中所要求的设计类实例与参与者实例之间的交互。在大多数情况里，可自然地发现对象在交互中的位置。在大多数情况里，可自然地发现对象在交互中的位置。 最后，详细描述交互图。其中在多数情况下可能会发现一最后，详细描述交互图。其中在多数情况下可能会发现一些新的可选路径。这样的路径可以用该交互图的标号或用它些新的可选路径。这样的路径可以用该交互图的标号或用它们自身的交互图予以描述。们自身的交互图予以描述。:PaymentrequestUI:BuyerBrowseinvoices:Paymentrequestprocessing:InvoiceProcessing:Invoice:PaymentScheduler:OrderConfirmation:Paymentrequest:OrderHandlerBrowse()Browseinvoice()Checkinvoice()getBrowseInfo()getConfirmationInfo()getInvoice()getInvoiceInfo()scheduleinvoiceforpaymentschedulePayment(Invoice)schedule(Invoice)setStatusOfInvoice(scheduled)setStatus(scheduled)New()Example:SequenceDiagramforthedesignobjectsthatperformpartofthePayInvoiceUseCaserealization. 另外，当要增加更多的信息时，经常需要讨论一些新的例另外，当要增加更多的信息时，经常需要讨论一些新的例外，这些例外并没有在需求捕获和分析时予以思考，包括：外，这些例外并没有在需求捕获和分析时予以思考，包括： 由于超时而导致节点或连接的的暂停。由于超时而导致节点或连接的的暂停。 人和机器参与者提供的错误输入。人和机器参与者提供的错误输入。 中间件、系统软件或硬件所产生的错误消息等。中间件、系统软件或硬件所产生的错误消息等。 第二种方法：第二种方法：标识参与用况细化的子系统和接口标识参与用况细化的子系统和接口 在自顶向下开发期间，有时在进行子系统和其接口的设计之在自顶向下开发期间，有时在进行子系统和其接口的设计之前，可能需要捕获一些有关子系统和接口的需求；另外，在一前，可能需要捕获一些有关子系统和接口的需求；另外，在一些情况里可能很容易给出子系统的另一设计，以替代一个子系些情况里可能很容易给出子系统的另一设计，以替代一个子系统和它的特定设计。针对以上两种情况，就可能需要在层次体统和它的特定设计。针对以上两种情况，就可能需要在层次体系的不同层上以子系统来描述一个用况细化的设计。例如：系的不同层上以子系统来描述一个用况细化的设计。例如： b a cb a c 使用参与使用参与use caseuse case细化的子系统及其接口对细化的子系统及其接口对use caseuse case的设计的设计 图（图（a a）表示子系统的生命线和它们的消息。图（）表示子系统的生命线和它们的消息。图（b b）和）和（c c）表示子系统的设计，并显示设计中的元素如何接受消息和）表示子系统的设计，并显示设计中的元素如何接受消息和发送消息。图（发送消息。图（a a）可以在图（）可以在图（b b）、（）、（c c）之间设计。）之间设计。 可见，使用参与用况细化的子系统和可见，使用参与用况细化的子系统和/ /或它们的接口可以给出或它们的接口可以给出用况的另一种设计。其中，为了标识在细化用况中所需要的子用况的另一种设计。其中，为了标识在细化用况中所需要的子系统系统: : 应研究对应的用况细化应研究对应的用况细化 分析分析 ， 标识包含这些分析类的标识包含这些分析类的分析包，继之标识可跟踪到这些分析包的设计子系统。分析包，继之标识可跟踪到这些分析包的设计子系统。 应研究对应用况细化应研究对应用况细化 分析分析 的特殊需求，标识细化这些特的特殊需求，标识细化这些特定需求的设计类，继之标识包含这些类的设计子系统。定需求的设计类，继之标识包含这些类的设计子系统。designsubsystemBuyersUIdesignsubsystemPaymentrequestmanagementAclassdiagramthatincludessubsystems,interfaces,andtheirdependencies,involvedinthefirstpartofthePayInvoiceusecase.designsubsystemInvoicemanagementdesignsubsystemPaymentSchedulingmanagementPaymentInvoicePaymentRequest最后，开发一个类图中，汇聚参与该用况细化的子系统，给最后，开发一个类图中，汇聚参与该用况细化的子系统，给出这些子系统之间的依赖，并给出用况细化中所使用的接口。出这些子系统之间的依赖，并给出用况细化中所使用的接口。例如：例如：当当已已经经勾勾画画了了细细化化用用况况所所需需要要的的那那些些子子系系统统之之后后，就就应应描描述述子子系系统统的的交交互互，即即在在系系统统层层上上描描述述所所包包含含的的类类对对象象是是如如何何交交互互的的，其其中中可可以以使使用用顺顺序序图图，包包含含参参与与交交互互的的参参与与者者实实例例、子系统、以及它们之间消息传送。子系统、以及它们之间消息传送。与与描描述述设设计计对对象象交交互互相相比比，在在描描述述子子系系统统的的交交互互图图中中，生生命命线线表表示示的的是是这这时时标标识识的的每每一一子子系系统统，而而不不是是设设计计对对象象；一一个个消消息息指指向向一一个个接接口口的的操操作作，而而不不是是指指向向另另一一个个子子系系统统，以以区区分该消息使用子系统的哪一个接口。分该消息使用子系统的哪一个接口。以以上上是是用用况况设设计计的的另另一一种种方方法法，其其中中使使用用了了参参与与用用况况细细化化的的子系统和接口。子系统和接口。最后最后,还要捕获实现需求还要捕获实现需求（CapturingImplementationRequirements）其中其中, ,应捕获应捕获use-caseuse-case细化中的所有需求，例如在设计中细化中的所有需求，例如在设计中标识的标识的、应该在实现中予以处理的非功能需求。例如：应该在实现中予以处理的非功能需求。例如：an object of the ( active) class Payment Request Processing should be able to handle 10 different buyer clients without a perceivable delay for any individual buyer.活动活动3:类的设计类的设计目标：目标：进行类的设计，使之完成在进行类的设计，使之完成在use-case use-case 细化中的角细化中的角 色，并完成针对它的非功能需求。色，并完成针对它的非功能需求。ComponentengineerDesignaClassTheinputandresultofdesigningaclass.Use-caserealization-DesignInterfaceoutlinedAnalysisClassoutlinedDesignclassoutlinedDesignclasscomplete一个类的设计，包含以下方面：一个类的设计，包含以下方面： 类的操作；类的操作； 类的属性；类的属性； 参与的关系；参与的关系； 类方法；类方法； 类的状态类的状态 对一般设计机制的依赖；对一般设计机制的依赖； 与实现有关的需求；与实现有关的需求； 所提供的那些接口的细化。所提供的那些接口的细化。 任务任务1:概括描述设计类（概括描述设计类（OutliningtheDesignClass）即把分析类和即把分析类和/ /或接口作为给定的输入，来勾画一个或多个设或接口作为给定的输入，来勾画一个或多个设计类。计类。 其中，其中， 当给定的输入是一个接口，那么就可以简单的、直接的当给定的输入是一个接口，那么就可以简单的、直接的指定一个提供该接口的设计类。指定一个提供该接口的设计类。 当给定的输入是一个或多个分析类，那么所使用的方法当给定的输入是一个或多个分析类，那么所使用的方法就要依赖分析类的衍型（就要依赖分析类的衍型（stereotypestereotype）：）：如果输入的是表示永久信息的实体类，其设计经常隐含如果输入的是表示永久信息的实体类，其设计经常隐含地需要使用一种特定的数据地需要使用一种特定的数据库技术；库技术；如果输入的是边界类，其设计需要使用一些特定的接面如果输入的是边界类，其设计需要使用一些特定的接面技术；技术；如果输入的是控制类，其设计是一件很辣手的问题。由于如果输入的是控制类，其设计是一件很辣手的问题。由于控制类有时封装了一些对象的协作，有时封装了业务逻辑，因控制类有时封装了一些对象的协作，有时封装了业务逻辑，因此往往需要考虑以下问题：此往往需要考虑以下问题：-分布问题，即如果控制次序需要在不同节点之间予以分布分布问题，即如果控制次序需要在不同节点之间予以分布和管理，那么为了细化该控制类，就可能需要把一些类分别分和管理，那么为了细化该控制类，就可能需要把一些类分别分布到不同的节点上。布到不同的节点上。-执行问题，即对这样控制类的细化，可能就没有什么理由需执行问题，即对这样控制类的细化，可能就没有什么理由需要给出一些不同的设计类。但是往往需要使用由相关的边界类要给出一些不同的设计类。但是往往需要使用由相关的边界类和和/或实体类所得到的设计类，来细化这一控制类。或实体类所得到的设计类，来细化这一控制类。-事务问题，即这样的控制类经常封装事务，因此对它们的设事务问题，即这样的控制类经常封装事务，因此对它们的设计应结合现在使用的任一事务管理技术。计应结合现在使用的任一事务管理技术。任务任务2 2：标识操作：标识操作 一般应依据分析类来标识设计类所提供的、所需要的操作，一般应依据分析类来标识设计类所提供的、所需要的操作，其中需要使用程序设计语言的语法（其中需要使用程序设计语言的语法（ syntaxsyntax）来描述所标识）来描述所标识的操作。的操作。 分析类的一个责任常常隐含了一个或多个操作。另外，如分析类的一个责任常常隐含了一个或多个操作。另外，如果已经描述了责任的输入和输出，那么就可以使用这些输入和果已经描述了责任的输入和输出，那么就可以使用这些输入和输出，来勾画操作的形式参数和结果值。输出，来勾画操作的形式参数和结果值。 对于分析类的特殊需求，经常可能需要结合设计模型中某对于分析类的特殊需求，经常可能需要结合设计模型中某一具有一般性的设计机制或技术（例如数据库技术）予以处理。一具有一般性的设计机制或技术（例如数据库技术）予以处理。 对于分析类的接口，其中的操作也需要由相应的设计类予对于分析类的接口，其中的操作也需要由相应的设计类予以提供。以提供。 对于参与对于参与use-case use-case 细化细化 设计设计 中的设计类，应通过走查中的设计类，应通过走查用况细化，一是研究在该细化图中和事件流的描述中包含该类用况细化，一是研究在该细化图中和事件流的描述中包含该类和它的对象，二是发现它们的角色。在此基础上，为其设计一和它的对象，二是发现它们的角色。在此基础上，为其设计一些支持该类在不同用况细化中所扮演角色的操作。些支持该类在不同用况细化中所扮演角色的操作。 任务任务3 3：标识属性：标识属性 使用程序设计语言的语法给出属性描述。使用程序设计语言的语法给出属性描述。 一个属性规约了设计类的一个特性，该属性通常由该类的操一个属性规约了设计类的一个特性，该属性通常由该类的操作所隐含的和要求的。作所隐含的和要求的。 在标识分析类的属性中，应：在标识分析类的属性中，应： 考虑设计类所对应的分析类的属性，其中这些分析类的属考虑设计类所对应的分析类的属性，其中这些分析类的属性隐含了该设计类有关属性的需求。性隐含了该设计类有关属性的需求。 通过程序设计语言对可用的属性类型进行约束。其中当选通过程序设计语言对可用的属性类型进行约束。其中当选择类型时，尽量复用已有的一个类型。择类型时，尽量复用已有的一个类型。 一个单一的属性实例，不能被多个设计对象所共享。如果一个单一的属性实例，不能被多个设计对象所共享。如果希望共享的话，就应该把该属性定义为一个设计类。希望共享的话，就应该把该属性定义为一个设计类。 如果设计类的属性理解起来相当困难，那么就应该对其中如果设计类的属性理解起来相当困难，那么就应该对其中的一些属性进行分离，成为该设计类自身拥有的一些类。的一些属性进行分离，成为该设计类自身拥有的一些类。 如果一个类具有很多或复杂的属性，则可以使用一个专门如果一个类具有很多或复杂的属性，则可以使用一个专门类图，显示属性的各个组件以及它们之间的关系。类图，显示属性的各个组件以及它们之间的关系。 任务任务4 4：标识关联和聚合：标识关联和聚合 在标识并精化关联和聚合中，应：在标识并精化关联和聚合中，应： 考虑对应的分析类所具有的关联和聚合。有时，在分析模型考虑对应的分析类所具有的关联和聚合。有时，在分析模型中的这些关系，隐含了所涉及的设计类对关系的需要。中的这些关系，隐含了所涉及的设计类对关系的需要。 在所使用的程序设计语言的支持下，精化关联的多重性、角在所使用的程序设计语言的支持下，精化关联的多重性、角色名、关联类、定序的角色、限定角色以及色名、关联类、定序的角色、限定角色以及N N元关联等。例如：元关联等。例如：在生成代码时，角色名可能成为设计类的属性；或一个关联类在生成代码时，角色名可能成为设计类的属性；或一个关联类可能成为另外两个类之间新的类，因此在可能成为另外两个类之间新的类，因此在“关联类关联类”和另外两和另外两个类之间需要一个新的、具有适当多重性的关联。个类之间需要一个新的、具有适当多重性的关联。 考虑使用该关联的交互图，来精化关联的导航性。另外，设考虑使用该关联的交互图，来精化关联的导航性。另外，设计对象之间消息转送方向，隐含了它们类之间关联的导航性。计对象之间消息转送方向，隐含了它们类之间关联的导航性。 任务任务5 5：标识泛化：标识泛化 基于分析模型中分析类之间的泛化，可以发现设计模型中的基于分析模型中分析类之间的泛化，可以发现设计模型中的很多泛化。例如：很多泛化。例如： 任务任务6 6：描述方法：描述方法 在设计期间，对方法的规约可以使用自然语言，或适当地使在设计期间，对方法的规约可以使用自然语言，或适当地使用伪码。用伪码。TradeObjectOrderInvoice 任务任务7 7：描述状态：描述状态 有些设计对象是受状态控制的，即它们的状态确定了在它们有些设计对象是受状态控制的，即它们的状态确定了在它们接受一个消息时的行为。在这样情况下，使用一个状态图来描接受一个消息时的行为。在这样情况下，使用一个状态图来描述一个对象的不同状态转移是有意义的。例如：类述一个对象的不同状态转移是有意义的。例如：类“发票发票”的的状态可设计为：状态可设计为：CreatedPendingScheduledOverdueClosed+submit()+scheduled()timeout:beyondlastdateofpayment+closed()+closed()AStatechartdiagramfortheInvoiceclass其中：其中： 当一个当一个seller希望希望buyer来支付一个定单（来支付一个定单（order）时，）时，则则invoice为创建状态（为创建状态（created）；）； 接之，当该接之，当该invoice交给交给buyer时，其状态变为时，其状态变为pending； 当当buyer决定支付时，该决定支付时，该invoice的状态又变为的状态又变为scheduled； 接之，如果该接之，如果该invoice予以支付了，则状态变为予以支付了，则状态变为closed。一个状态图对相应设计类的实现来说是一个有价值的输入。一个状态图对相应设计类的实现来说是一个有价值的输入。活动活动: : 子系统设计子系统设计 该活动的目标是：该活动的目标是： 确保子系统尽可能独立于其它子系统或它们的接口。确保子系统尽可能独立于其它子系统或它们的接口。 确保子系统提供正确的接口。确保子系统提供正确的接口。 确保子系统实现了（确保子系统实现了（fulfillsfulfills）它的目标，即给出了该）它的目标，即给出了该 子系统提供的那些接口所定义的操作的细化。子系统提供的那些接口所定义的操作的细化。ComponentengineerDesignaSubsystemTheinputandresultofdesigningasubsystem.ArchitectureDescriptionviewofthedesignmodelInterfaceoutlinedSubsystemoutlinedSubsystemcompleteInterfacecomplete任务任务1：维护子系统依赖：维护子系统依赖-定义其他子系统所包含的元素与该子系统中元素之间的关定义其他子系统所包含的元素与该子系统中元素之间的关-如果一个子系统为其它子系统提供了一些接口，那么就应如果一个子系统为其它子系统提供了一些接口，那么就应当说明这些子系统如何通过接口与该子系统发生依赖。当说明这些子系统如何通过接口与该子系统发生依赖。其中，最好是依赖一个接口，而不依赖一个子系统。因为一其中，最好是依赖一个接口，而不依赖一个子系统。因为一个子系统可能会用另一设计子系统所替代，但不需要替换该个子系统可能会用另一设计子系统所替代，但不需要替换该接口。接口。还要考虑重新安排所包含的、过多依赖其它子系统的类，以还要考虑重新安排所包含的、过多依赖其它子系统的类，以此尽量减少对其它子系统和此尽量减少对其它子系统和/ /或接口的依赖，以实现子系统之或接口的依赖，以实现子系统之间的低耦合。间的低耦合。任务任务2 2：维护子系统所提供的接口：维护子系统所提供的接口 一个子系统一般提供了一些接口，由这些接口所定义的操作一个子系统一般提供了一些接口，由这些接口所定义的操作需要支持该子系统在不同用况细化中所扮演的所有角色。尽管需要支持该子系统在不同用况细化中所扮演的所有角色。尽管这些接口已经予以勾画，但当设计模型演化时和当用况设计时，这些接口已经予以勾画，但当设计模型演化时和当用况设计时，它们也需要予以精化。因为在不同用况细化中，可能要使用一它们也需要予以精化。因为在不同用况细化中，可能要使用一个子系统和它的接口，由此对这些接口提供了进一步的需求。个子系统和它的接口，由此对这些接口提供了进一步的需求。任务任务3 3： 维护子系统内容维护子系统内容 当对一个子系统的接口所定义的操作给出了一个正确的细化，当对一个子系统的接口所定义的操作给出了一个正确的细化，则该子系统就完成了它的目标。尽管该子系统的内容已予勾画，则该子系统就完成了它的目标。尽管该子系统的内容已予勾画，但当设计模型演进时，也可能需要予以精化。与其相关的一般但当设计模型演进时，也可能需要予以精化。与其相关的一般问题有：问题有： 对于由该子系统提供的每一接口，在该子系统中存在一些设对于由该子系统提供的每一接口，在该子系统中存在一些设计类或其它子系统，它们还提供了这一接口。计类或其它子系统，它们还提供了这一接口。 为了说明一个子系统的内部设计怎样细化它的接口或为了说明一个子系统的内部设计怎样细化它的接口或use use cases cases ，可能要使用该子系统包含的元素来创建一些协作，以，可能要使用该子系统包含的元素来创建一些协作，以验证该子系统应当包含那些元素。验证该子系统应当包含那些元素。 RUP RUP设计小结设计小结 1 1）RUPRUP的设计方法，由三部分组成：的设计方法，由三部分组成： 给出用于表达设计模型中基本成分的四个术语，包括：给出用于表达设计模型中基本成分的四个术语，包括： 子系统、设计类、接口和用况细化子系统、设计类、接口和用况细化 设计设计 ； 规约了设计模型的语法，指导模型的表达；规约了设计模型的语法，指导模型的表达； 给出了创建设计模型的过程以及相应的指导。给出了创建设计模型的过程以及相应的指导。2)2)设计的突出特点设计的突出特点: : 使用了一种公共的思想，来思考该设计，并是可视化的。使用了一种公共的思想，来思考该设计，并是可视化的。可以获得对有关子系统、接口和类的需求，为以后的实现可以获得对有关子系统、接口和类的需求，为以后的实现活动创建一个合适的输入活动创建一个合适的输入, ,即为系统的实现，创建一个无缝即为系统的实现，创建一个无缝的抽象，在一定意义上讲，使实现成为设计的一个直接的精的抽象，在一定意义上讲，使实现成为设计的一个直接的精化化- -填加内容，而不改变其结构。这样就可以在设计和实现填加内容，而不改变其结构。这样就可以在设计和实现之间，使用代码生成技术，反复不断地实现之间，使用代码生成技术，反复不断地实现. . 可以对实现工作进行分解，成为一些可由不同开发组尽可能可以对实现工作进行分解，成为一些可由不同开发组尽可能同时处理的、可管理的部分同时处理的、可管理的部分; ;（注：这一分解不可能在需求获取或分析中完成。）（注：这一分解不可能在需求获取或分析中完成。）可以在软件生存周期的早期，捕获子系统之间的主要接口。可以在软件生存周期的早期，捕获子系统之间的主要接口。这有助于不同开发组之间思考有关体系结构问题并合理使用接这有助于不同开发组之间思考有关体系结构问题并合理使用接口，以提高设计质量口，以提高设计质量3 3）设计的主要结果是系统的设计模型，它尽量保持该系统具）设计的主要结果是系统的设计模型，它尽量保持该系统具有分析模型的结构，并作为系统实现的输入。有分析模型的结构，并作为系统实现的输入。 包括以下元素：包括以下元素： 设计子系统和服务子系统，以及它们的依赖、接口和内设计子系统和服务子系统，以及它们的依赖、接口和内容。容。 其中，可以依据分析包来设计上面两层（即特定应用层和一其中，可以依据分析包来设计上面两层（即特定应用层和一般应用层）的设计子系统。有关设计子系统之间的依赖，有些般应用层）的设计子系统。有关设计子系统之间的依赖，有些是基于所对应的分析包的依赖而设计的；有关子系统的接口，是基于所对应的分析包的依赖而设计的；有关子系统的接口，有些是依赖分析类而设计的。有些是依赖分析类而设计的。 设计类（其中包括一些主动类），以及它们具有的操作、设计类（其中包括一些主动类），以及它们具有的操作、属性、关系及其实现需求。属性、关系及其实现需求。 一般地，在进行设计类的设计时，分析类作为它们的规约，一般地，在进行设计类的设计时，分析类作为它们的规约，特别地有些主动类是基于分析类并考虑并发需求而设计的。特别地有些主动类是基于分析类并考虑并发需求而设计的。 用况细化用况细化 设计设计 。 它们描述了用况是如何设计的，其中使用了设计模型中的协它们描述了用况是如何设计的，其中使用了设计模型中的协作。一般地，在进行用况细化作。一般地，在进行用况细化 设计设计 设计时，用况细化设计时，用况细化 分析分析 作为作为它们的规约。它们的规约。 设计模型视觉下的体系结构描述，其中包括对一些在体系设计模型视觉下的体系结构描述，其中包括对一些在体系结构方面有重要意义元素的描述。结构方面有重要意义元素的描述。 如以前指出的，在进行设计模型视觉下体系结构方面具有意如以前指出的，在进行设计模型视觉下体系结构方面具有意义的元素设计时，分析模型视觉下的那些在体系结构方面有意义的元素设计时，分析模型视觉下的那些在体系结构方面有意义的元素作为它们的规约。义的元素作为它们的规约。 4 4）RUPRUP的设计还产生了部署模型，描述了网络配置，系统将分的设计还产生了部署模型，描述了网络配置，系统将分布于这个配置上布于这个配置上 部署模型包括：部署模型包括： 节点节点, , 它们的特征以及连接；它们的特征以及连接； 主动类到节点的初始映射；主动类到节点的初始映射； 部署模型视觉下的体系结构描述，包括对那些在体系结构方部署模型视觉下的体系结构描述，包括对那些在体系结构方面具有重要意义元素的描述。面具有重要意义元素的描述。 5 5）设计模型和分析模型的简要比较）设计模型和分析模型的简要比较分析模型分析模型 设计模型设计模型 概念模型概念模型, , 是对系统的抽象，是对系统的抽象， 软件模型软件模型, , 是对系统的抽是对系统的抽 而不涉及实现细节；而不涉及实现细节； 象象, ,而不涉及实现细节；而不涉及实现细节； 可应用于不同的设计；可应用于不同的设计； 特定于一个实现；特定于一个实现；w使用了三个衍型类：使用了三个衍型类： 控制类、控制类、 使用了多个衍型类，使用了多个衍型类， 实体类和边界类；实体类和边界类； 依赖于实现语言；依赖于实现语言； 几乎不是形式化的；几乎不是形式化的； 是比较形式化的；是比较形式化的；y开发的费用少开发的费用少 开发的费用高开发的费用高 （相对于分析是（相对于分析是1:51:5） （相对于设计是（相对于设计是5:15:1） 层少层少Few layersFew layers； 层多；层多；动态的，但很少关注定序方面；动态的，但很少关注定序方面； 动态的，但更多关注定动态的，但更多关注定 序方面；序方面；概括地给出了系统设计，包括概括地给出了系统设计，包括 表明了系统设计，包括表明了系统设计，包括设系统的体系结构设系统的体系结构; ; 计视觉下的系统体系结构计视觉下的系统体系结构整个软件生存周期中不能予以整个软件生存周期中不能予以 整个软件生存周期整个软件生存周期修改、增加等修改、增加等; ; 中应该予以维护；中应该予以维护；为构建系统包括创建设计模型，为构建系统包括创建设计模型， 构建系统时，尽可能保构建系统时，尽可能保 定义一个结构，是一个基本输入定义一个结构，是一个基本输入 留分析模型所定义的结构留分析模型所定义的结构6)6)设计阶段的活动：设计阶段的活动：序序号号输入输入活动活动执行者执行者输出输出1用用况况模模型型、补补充充需需求求、分分析析模模型型、体体系系结结构构描述描述分析模型角度分析模型角度体体 系系结结 构构设计设计体体系系结结构构设设计计者者子子系系统统概概述述、接接口口概概述述、设设计计类类概概述述、部部署署模模型型概概述述、体体系系结结构构描描述述设计、部署模型角度设计、部署模型角度2用用况况模模型型、补补充充需需求求、分分析析模模型型、设设计模型、部署模型计模型、部署模型设设 计计用况用况用用况况工工程师程师用用况况实实现现-设设计计、设设计计类类概概述述、子子系系统统概述概述、接口、接口概述概述3用用况况实实现现-设设计计、设设计计类类概概述述、接接口口概概述述、分析类分析类完成完成对对 类类设计设计构构件件工工程师程师设计类设计类完成完成4体体系系结结构构描描述述（从从设设计计模模型型角角度度）、子子系系统统概述概述、接口、接口概述概述设设 计计子子 系系统统构构件件工工程师程师子系统子系统完成完成、接口、接口完成完成其其中中：活活动动1 1 把把分分析析模模型型的的分分析析包包变变为为设设计计模模型型的的子子系系统统。活活动动2 2中中的用况里的各个流应该各对应一个顺序图。的用况里的各个流应该各对应一个顺序图。7) 7) 对实现的影响对实现的影响 由于设计模型和部署模型是以后实现和测试活动的基本输入，由于设计模型和部署模型是以后实现和测试活动的基本输入，因此要强调的是：因此要强调的是： 设计子系统和服务子系统是由实现子系统予以实现的，这些设计子系统和服务子系统是由实现子系统予以实现的，这些实现子系统包括一些构件，例如源代码文件、脚本以及二进制、实现子系统包括一些构件，例如源代码文件、脚本以及二进制、可执行的构件等。这些实现子系统可跟踪到设计子系统。可执行的构件等。这些实现子系统可跟踪到设计子系统。 设计类将由文件化构件予以实现的，它们包括源代码。一般设计类将由文件化构件予以实现的，它们包括源代码。一般地，一些不同的设计类在一个单一的文件化构件中实现，尽管地，一些不同的设计类在一个单一的文件化构件中实现，尽管这依赖所使用的程序设计语言。另外，当要寻找可执行的构件这依赖所使用的程序设计语言。另外，当要寻找可执行的构件时，将要使用那些描述时，将要使用那些描述“权重权重”处理的主动类。处理的主动类。 在规划实现工作时，将要使用用况细化在规划实现工作时，将要使用用况细化 设计设计 ，以产生一些，以产生一些“构造构造”（BulidBulid），即系统的一个可执行的版本。每一个构造），即系统的一个可执行的版本。每一个构造将实现一组用况细化或部分用况细化。将实现一组用况细化或部分用况细化。 在节点上部署构件，形成分布系统时，将使用部署模型和网在节点上部署构件，形成分布系统时，将使用部署模型和网络配置。络配置。附：附：下面仅对核心工作流中的实现和测试作简单介绍。下面仅对核心工作流中的实现和测试作简单介绍。1 1、RUPRUP的实现的实现 RUPRUP实现的目标是：基于设计类和子系统，生成构件；对构实现的目标是：基于设计类和子系统，生成构件；对构件进行单元测试，进行集成和连接；并把可执行的构件映射到件进行单元测试，进行集成和连接；并把可执行的构件映射到部署模型。其主要活动以及其输入部署模型。其主要活动以及其输入/ /输出为：输出为：其中其中: : 实现模型实现模型 该模型描述了设计模型中的元素是如何用构件实现的，描该模型描述了设计模型中的元素是如何用构件实现的，描述了构件间的依赖关系，并描述如何按实现环境来组织构件。述了构件间的依赖关系，并描述如何按实现环境来组织构件。可见，构件是设计模型中元素的一种实现，是对这样元素的可见，构件是设计模型中元素的一种实现，是对这样元素的物理封装，要把它映射到部署模型的节点上。物理封装，要把它映射到部署模型的节点上。 实现子系统实现子系统 实现子系统是由构件、接口和其它子系统组成的。其中，实现子系统是由构件、接口和其它子系统组成的。其中，接口用于表示由构件和实现子系统所实现的操作。在这一阶段接口用于表示由构件和实现子系统所实现的操作。在这一阶段可以使用设计时的接口。可以使用设计时的接口。 实现模型视角下的体系结构描述实现模型视角下的体系结构描述 实现模型视角下的体系结构描述，包括对由实现模型分解实现模型视角下的体系结构描述，包括对由实现模型分解的子系统、子系统间的接口、子系统间的依赖以及关键构件的的子系统、子系统间的接口、子系统间的依赖以及关键构件的描述。其中，相应设计子系统中的每个类和每个接口，都要由描述。其中，相应设计子系统中的每个类和每个接口，都要由实现子系统中的构件实现。实现子系统中的构件实现。 实现类实现类该活动对每一个涉及源代码的文件构件，根据相应的设计类该活动对每一个涉及源代码的文件构件，根据相应的设计类来生成其代码，为设计类提供操作的方法，其中应使构件提供来生成其代码，为设计类提供操作的方法，其中应使构件提供的接口与设计类提供的接口相一致。的接口与设计类提供的接口相一致。 在实施在实施RUPRUP的实现中，涉及集成计划的开发问题。在增量开发中，的实现中，涉及集成计划的开发问题。在增量开发中，每一步的结果即为一个构造。在一个迭代中，可能创建一个构造序列，每一步的结果即为一个构造。在一个迭代中，可能创建一个构造序列，即构造集成计划。即构造集成计划。2 2、RUPRUP的测试的测试 RUPRUP的测试包括内部测试、中间测试和最终测试，其主要活的测试包括内部测试、中间测试和最终测试，其主要活动为动为: :特别是，当细化阶段中体系结构基线变为可执行时，当构造阶段中系统特别是，当细化阶段中体系结构基线变为可执行时，当构造阶段中系统变为可执行时，以及当移交阶段中检测到缺陷时，都要进行测试。变为可执行时，以及当移交阶段中检测到缺陷时，都要进行测试。其中：其中： 测试模型测试模型 主要描述系统测试者和集成测试者如何实施对在实现中可执主要描述系统测试者和集成测试者如何实施对在实现中可执行构件的测试，并描述如何测试系统的特殊方面行构件的测试，并描述如何测试系统的特殊方面( (如用户接口、如用户接口、可用性、一致性以及用户手册是否达到目的等可用性、一致性以及用户手册是否达到目的等) )。因此，测试。因此，测试模型是用况测试、过程测试和构件测试的一个集合体。模型是用况测试、过程测试和构件测试的一个集合体。 测试用况描述测试系统的方式。一般描述如何测试用况测试用况描述测试系统的方式。一般描述如何测试用况( (或或部分部分) )，包括输入、输出和条件。，包括输入、输出和条件。 测试过程描述怎样执行一个或几个测试用况，也可以描述测试过程描述怎样执行一个或几个测试用况，也可以描述其中的片段。其中的片段。 测试构件用于测试实现模型中的构件。测试时，要提供测测试构件用于测试实现模型中的构件。测试时，要提供测试输入，并控制和监视被测构件的执行。用脚本语言描述或编试输入，并控制和监视被测构件的执行。用脚本语言描述或编程语言开发测试构件，也可以用一个测试自动工具进行记录，程语言开发测试构件，也可以用一个测试自动工具进行记录，以对一个或多个测试过程或它们片段进行自动化。以对一个或多个测试过程或它们片段进行自动化。 测试计划描述测试策略、资源和时间表。测试策略包括对各测试计划描述测试策略、资源和时间表。测试策略包括对各迭代进行测试的种类、目的、级别、代码覆盖率以及成功的迭代进行测试的种类、目的、级别、代码覆盖率以及成功的准则。准则。 缺陷描述系统的异常现象。缺陷描述系统的异常现象。 评价测试描述在一次迭代中对测试用况覆盖率、代码覆盖评价测试描述在一次迭代中对测试用况覆盖率、代码覆盖率和缺陷情况率和缺陷情况( (可绘制缺陷趋势图可绘制缺陷趋势图) )的评价。其中，为了度量需的评价。其中，为了度量需要把评价结果与目标进行比较。要把评价结果与目标进行比较。其中，在活动其中，在活动2 2中，应对每个建造都要设计相应的集成测试用中，应对每个建造都要设计相应的集成测试用况、系统测试用况和回归测试用况；在活动况、系统测试用况和回归测试用况；在活动4 4中，应对每次迭中，应对每次迭代中的各个建造都要执行集成测试，当集成测试满足当前迭代代中的各个建造都要执行集成测试，当集成测试满足当前迭代计划中的目标时，要进行活动计划中的目标时，要进行活动5 5。 关于关于RUPRUP的结束语的结束语RUP是一种软件开发过程框架，基于面向对象符号体系给是一种软件开发过程框架，基于面向对象符号体系给出了有关软件开发过程组织及实施的指导。该框架体现了三个出了有关软件开发过程组织及实施的指导。该框架体现了三个突出特征，即以用况驱动、以以体系结构为中心以及迭代、增突出特征，即以用况驱动、以以体系结构为中心以及迭代、增量式开发。量式开发。RUP和和UML是一对是一对“姐妹姐妹”，构成了一种特定软件开发方，构成了一种特定软件开发方法学的主体。法学的主体。UML作为一种可视化建模语言，给出了表达对作为一种可视化建模语言，给出了表达对象和对象关系的基本术语，给出了多种模型的表达工具，而象和对象关系的基本术语，给出了多种模型的表达工具，而RUP利用这些术语，定义了需求获取层、系统分析层、设计利用这些术语，定义了需求获取层、系统分析层、设计层、实现层，并给出了实现各层模型之间映射的基本活动以及层、实现层，并给出了实现各层模型之间映射的基本活动以及相关的指导。相关的指导。五五 CMMCMM（theCapabilityMaturityModelforsoftware） CMMCMM是什么是什么? ? CMMCMM的知识结构的知识结构过程是生产产品的机制过程是生产产品的机制.不论是过程改善还不论是过程改善还是能力确定是能力确定,均需要过程评估均需要过程评估,而过程评估通常而过程评估通常基于已提出的一些评估模型基于已提出的一些评估模型.软件开发软件开发本质本质软软件件生生存存周周期期过过程程定义定义软软件件生生存存周周期期模模型型软软件件工工程程生生存存周周期期过过程程支支持持过过程程方方向向(活活动动与与定定序序)的的建建立立形形成成软件开发方法学软件开发方法学结构化方法结构化方法面向对象方法面向对象方法面向数据结构面向数据结构方法方法维也纳开发方维也纳开发方法（法（VDM）给给出出实实现现开开发发过过程程的的途途径径支持支持/管理技术管理技术与方法与方法作用于作用于 在在8080年代中期，美国工业界和政府部门开始认识到：年代中期，美国工业界和政府部门开始认识到：在在软件开发中，关键的问题在于软件开发组织不能很好地定义软件开发中，关键的问题在于软件开发组织不能很好地定义和控制其软件过程。和控制其软件过程。从而使一些好的开发方法和技术都起不从而使一些好的开发方法和技术都起不到所期望的作用。到所期望的作用。 针对这一问题：针对这一问题： 19861986年年1111月月，美美国国卡卡内内基基- -梅梅隆隆大大学学软软件件工工程程研研究究所所（SEISEI）开始开发过程成熟度框架。）开始开发过程成熟度框架。 19871987年年9 9月月，SEISEI发发布布了了过过程程成成熟熟度度框框架架的的简简要要描描述述和和成成熟度调查表。熟度调查表。 19911991年年，SEISEI将将过过程程成成熟熟度度框框架架演演化化为为CMM CMM 1.01.0版版：CMU/SEI-91-TR-24CMU/SEI-91-TR-24、CMU/SEI-91-TR-25CMU/SEI-91-TR-25。 19931993年年，SEISEI根根据据反反馈馈，提提出出CMM CMM 1.11.1版版：CMU/SEI-93-CMU/SEI-93-TR-25TR-25。目前，。目前，已经提出已经提出CMM 2.0CMM 2.0版。版。是什么？是什么？CMM为控制软件过程提供了一种业界认可的评估指标体系，为控制软件过程提供了一种业界认可的评估指标体系，一种软件能力成熟度模型一种软件能力成熟度模型注：没有涉及评估过程的方法注：没有涉及评估过程的方法.过程管理过程管理过程规划过程规划评评估估组织组织过程控制过程控制人员指派人员指派领导领导至少涉及：至少涉及：1）评估模式；）评估模式；2）评估指标体系；）评估指标体系；3）评估方法学；）评估方法学；4）评估技术；等）评估技术；等CMM：支持建立过程能力评估：支持建立过程能力评估的评估指标体系的评估指标体系包括包括 评估指标评估指标 指标体系指标体系2 2 的基本内容的基本内容 ）基本）基本思想思想(Philosophy)支撑软件产品系统质量的三大要素：支撑软件产品系统质量的三大要素：“整个软件任务可以看作是一个过程，该过程可以予以控整个软件任务可以看作是一个过程，该过程可以予以控制、测量和改进制、测量和改进”（“Treattheentiresoftwaretaskasaprocessthatcancontrolled,measured,andimproved.”WattsS.HumphreyABDCPeopleProcessTechnology）基本概念）基本概念:（1）何谓过程？）何谓过程？过程（过程（Process）是一种手段，通过该手段可以把人、规是一种手段，通过该手段可以把人、规程、方法、设备以及工具进行集成，以产生一种所期望的结果。程、方法、设备以及工具进行集成，以产生一种所期望的结果。（themeansbywhichpeople,procedures,method,equipment,andtoolsareintegratedtoproduceadesiredendresult.）(2)过程能力过程能力定义定义：( (开发组织或项目组开发组织或项目组) )通过遵循其软件过通过遵循其软件过 程能够实现预期结果的程度。程能够实现预期结果的程度。range可见：可见：一一个个组组织织的的软软件件过过程程能能力力，是是未未来来项项目目结结果果的的指指示示器器，给给出出了了一一种种预预测测该该组组织织承承担担下下一一个个软软件件项项目目可可能能结结果果的的方方法法。是是不不同等级过程能力的基本指标，同等级过程能力的基本指标，高、低过程能力的基本特征高、低过程能力的基本特征（Characteristics）按以上的图，过程能力有高有低按以上的图，过程能力有高有低低过程能力的基本特征低过程能力的基本特征非常依赖当前的参与人员（非常依赖当前的参与人员（practitioners）；）；什么事情（包括软件过程与管理）均是临时准备；什么事情（包括软件过程与管理）均是临时准备；没有严格的下一步；没有严格的下一步；冒险地使用新技术；冒险地使用新技术；复审和测试常常不足；复审和测试常常不足；产品质量很难预测产品质量很难预测交付的交付的“东西东西”不符合要求；不符合要求；进度延迟和预算超额。进度延迟和预算超额。 高过程能力的特征高过程能力的特征定义了过程，建立了使用技术的基础；定义了过程，建立了使用技术的基础；开发和管理遵循一个确定的途径；开发和管理遵循一个确定的途径；过程得到了很好地控制，并得到各方面（包括测量）过程得到了很好地控制，并得到各方面（包括测量）的支持；的支持；实现了过程制度化，并不断改进实现了过程制度化，并不断改进。-具有成熟过程的组织特征具有成熟过程的组织特征（CharacteristicsofOrganizationswithamatureProcesses）SoftwareSoftwarepoliciespoliciesCommunicationtoemployeesDefined,mandatedpracticesActivitiesfollowprocessesEstimatingsystemSchedulesandbudgetbasedonhistoricalperformanceManagersmonitorcustomersatisfactionManagersmonitorproductqualityandstatusManagersmonitorenforcepoliciesandprocessesStatusreportscustomersatisfactionsurveysSQA(3)过程性能（过程性能（ProcessPerformance）遵循一个过程所达到实际结果的一个测度（遵循一个过程所达到实际结果的一个测度（measure）过程能力和过程性能之间的关系过程能力和过程性能之间的关系CapabilityPerformance 注意注意：软件过程能力软件过程能力与与软件过程性能软件过程性能之间的关系：之间的关系：一个是能够一个是能够实现预期结果的程度，一个是得到的实际结果实现预期结果的程度，一个是得到的实际结果一个一个项目的实际过程性能，可能并不充分反映其所在组织项目的实际过程性能，可能并不充分反映其所在组织 的整个过程能力。（由于该项目的具体属性和执行该项目的整个过程能力。（由于该项目的具体属性和执行该项目 的环境所限）的环境所限）(4)过程成熟度（过程成熟度（ProcessMature）一个特定软件过程被明确和有效地定义、管理、测量和一个特定软件过程被明确和有效地定义、管理、测量和控制的程度。控制的程度。（Definition:ProcessMatureTheextenttowhichaspecificprocessisexplicitly:defined(youknowwhatisdone)，managed(youcancontroltheprocessqualitatively)， measured(youknowhowmuchisdone,andhowwell)，controlled(youcancontroltheprocessquantitatively)，effective(youcanimprovetheprocessrationally)）软件过程成熟度软件过程成熟度指明指明： 一个软件开发组织一个软件开发组织软件过程能力软件过程能力的增长潜力；的增长潜力；-能力提高的能力提高的基础性基础性 表明一个开发组织表明一个开发组织软件过程的丰富多样性软件过程的丰富多样性，-能力提高的能力提高的可能性可能性 在各开发项目中运用在各开发项目中运用软件过程的一致性软件过程的一致性。-能力提高的能力提高的持续性持续性这意味着这意味着：由于开发组织通过运用软件过程，使各项目由于开发组织通过运用软件过程，使各项目执行软件过程的纪律性一致地增强，导致软件生产率和质量执行软件过程的纪律性一致地增强，导致软件生产率和质量可以得到不断地的改进。可以得到不断地的改进。组织成熟度（组织成熟度（OrganizationalMaturity）组织的成熟度是由一组过程的组织的成熟度是由一组过程的组合能力来表达的，其中组合能力来表达的，其中包括支持它们的制度因素（包括支持它们的制度因素（factor）-pertainstosetofprocesses高的组织成熟度，是将组织的一组过程看作为一个整体，高的组织成熟度，是将组织的一组过程看作为一个整体，该整体是高的过程能力。其主要表现为：该整体是高的过程能力。其主要表现为：不论是开发还是管理，均有明确、严格的途径；不论是开发还是管理，均有明确、严格的途径；定义了组织过程并不断改善之；定义了组织过程并不断改善之；得到了管理人员和其他人员的支持；得到了管理人员和其他人员的支持；实施了很好的控制；实施了很好的控制；()能力成熟度等级能力成熟度等级软件开发组织在走向成熟的过程中，几个具有明确定软件开发组织在走向成熟的过程中，几个具有明确定义的、可以表征其软件过程能力成熟程度的义的、可以表征其软件过程能力成熟程度的“平台平台”。该平台（该平台（每一等级）包含一组过程目标。当一个软件开发每一等级）包含一组过程目标。当一个软件开发组织达到其中一个目标时，则表明软件过程的一个组织达到其中一个目标时，则表明软件过程的一个( (或几个或几个) )重重要成分得到了实现，从而导致该组织软件过程能力的增长。要成分得到了实现，从而导致该组织软件过程能力的增长。显然，显然，每一个成熟度等级为达到下一个等级提供了一个基础。每一个成熟度等级为达到下一个等级提供了一个基础。 3）CMM的软件过程成熟度框架的软件过程成熟度框架初始级初始级(1)可重复级可重复级(2)已定义级已定义级(3)已管理级(4)持续优化级持续优化级(5)严格的严格的过程过程标准的一致的标准的一致的过程过程可预言的可预言的过程过程持续改善的持续改善的过程过程(1)成熟度框架成熟度框架在这一框架中，在这一框架中，将将过程能力成熟过程能力成熟度分为五级度分为五级：初始级初始级， 可重复级可重复级，已定义级，已管理级已定义级，已管理级，持续优化级持续优化级。通过成熟度级别通过成熟度级别，定义了定义了在在使软件过程成熟的过程使软件过程成熟的过程中的中的演化状态演化状态。可见可见，过程成熟度框架过程成熟度框架：描述：描述：一条从无序的、混乱的过程达到成熟的、有纪律一条从无序的、混乱的过程达到成熟的、有纪律的软件的软件过程的进化途径过程的进化途径。用途：用途：以软件过程成熟度框架，可以导出过程改进策略，以软件过程成熟度框架，可以导出过程改进策略，为软件过程的不断改进的历程提供了一份导引图：为软件过程的不断改进的历程提供了一份导引图：-指导软件开发组织不断识别出其软件过程的缺陷指导软件开发组织不断识别出其软件过程的缺陷-引导开发组织在各个平台上引导开发组织在各个平台上“做什么做什么”改进（但它改进（但它并不提供并不提供“如仍做如仍做”的具体措施。的具体措施。基础：基础：软件过程成熟度框架的基础是等级内部结构。软件过程成熟度框架的基础是等级内部结构。(2)各等级的基本特征各等级的基本特征l初始级初始级主要特征：主要特征：组织：组织通常没有提供开发和维护软件的稳定的环境。组织：组织通常没有提供开发和维护软件的稳定的环境。项目：当发生危机时，项目通常放弃计划的过程，回复到项目：当发生危机时，项目通常放弃计划的过程，回复到编码和测试。编码和测试。过程能力：不可预测。过程能力：不可预测。(unpredictable)由于：由于： 软件开发无规范；软件开发无规范； 软件过程不确定、无计划、无秩序；软件过程不确定、无计划、无秩序； 过程执行不过程执行不“透明透明”； 需求和进度失控。需求和进度失控。 结果：结果：项目的成败完全取决于个人的能力和努力；项目的成败完全取决于个人的能力和努力； 软软件件性性能能随随个个人人具具有有的的技技能能、知知识识和和动动机机的的不不同同而而变变化，化，并只能通过个人的能力进行预测。并只能通过个人的能力进行预测。可重复级可重复级主要特征主要特征：组织组织：将软件项目的有效管理过程制度化，这使得组织：将软件项目的有效管理过程制度化，这使得组织能够重复以前项目中的成功实践。能够重复以前项目中的成功实践。项目项目：配备了基本的软件管理控制。：配备了基本的软件管理控制。过程能力过程能力：可重复的：可重复的：即对当前项目的需求分析后制定的，能重即对当前项目的需求分析后制定的，能重复以前的成功实践，尽管在具体过程中可能有所不同。复以前的成功实践，尽管在具体过程中可能有所不同。这是该级的这是该级的个显著特征个显著特征基本可控的：基本可控的：即对软件项目的管理过程是制度化的。即对软件项目的管理过程是制度化的。 在项目的规划和服务跟踪过程中规定并设置了监测点；在项目的规划和服务跟踪过程中规定并设置了监测点； 对软件需求和为实现需求所开发的软件产品建立了基对软件需求和为实现需求所开发的软件产品建立了基线；线； 为管理、跟踪软件项目的成本、进度和功能提供了规范；为管理、跟踪软件项目的成本、进度和功能提供了规范； 提供了当不满足约定时的识别方法和纠偏措施。提供了当不满足约定时的识别方法和纠偏措施。软件项目过程基本上是可视的软件项目过程基本上是可视的 过程是有效的：过程是有效的：即对项目建立了实用的、已文档化的、即对项目建立了实用的、已文档化的、已实施的、己培训的、已测量的和能改进的过程。已实施的、己培训的、已测量的和能改进的过程。项目的过程基本是可特征化的项目的过程基本是可特征化的项目是稳定的：项目是稳定的：即对新项目的策划和管理，有明确的管理方即对新项目的策划和管理，有明确的管理方针和确定的标准（包括对分承制方），可使项目的进展稳针和确定的标准（包括对分承制方），可使项目的进展稳定。定。新项目的策划和管理是基于成功项目经验的新项目的策划和管理是基于成功项目经验的 过过程程是是有有纪纪律律的的：即即对对所所建建立立和和实实施施的的方方针针、规规程程，对对软软件件项项目目过过程程而而言言，已已进进化化为为组组织织的的行行为为。从从而而使使软软件件开开发发组组织织能能够够保证准确地执行给定的软件过程。保证准确地执行给定的软件过程。总之，总之，2级的过程是可视的，即可以获取项目运行状态。级的过程是可视的，即可以获取项目运行状态。具备以上过程能力特征的途径：具备以上过程能力特征的途径： 应实现关键过程域应实现关键过程域： 软件配置管理、软件质量保证、软件子合同管理、软件配置管理、软件质量保证、软件子合同管理、 软件项目跟踪和监督、软件项目规划、需求管理。软件项目跟踪和监督、软件项目规划、需求管理。其中：其中：关键过程域：关键过程域：过过程程域域：互互相相关关联联的的若若干干个个软软件件实实践践活活动动和和有有关关基基础础设设施施的集合，即的集合，即软件活动，基础设施软件活动，基础设施。关关键键过过程程域域：对对某某一一成成熟熟度度等等级级将将起起到到至至关关重重要要的的过过程程域域即即它它们们的的实实施施将将对对达达到到该该成成熟熟度度等等级级的的目目标标起起保保证证作作用用，这这些些过过程域被称为关键过程域。程域被称为关键过程域。每一软件过程成熟度等级均包含一组特定的关键过程域。每一软件过程成熟度等级均包含一组特定的关键过程域。l已定义级已定义级 实现了可重复级（实现了可重复级（2 2级）的关键过程域级）的关键过程域： 软件配置管理、软件质量保证、软件子合同管理、软件配置管理、软件质量保证、软件子合同管理、 软件项目跟踪和监督、软件项目规划以及需求管理软件项目跟踪和监督、软件项目规划以及需求管理 实现了关键过程域实现了关键过程域： 组织过程焦点、组织过程定义、培训大纲、集成软组织过程焦点、组织过程定义、培训大纲、集成软 件管理、软件产品工程、组间协调以及同行评审件管理、软件产品工程、组间协调以及同行评审 主要特征主要特征：组织组织：在组织范围内开发和维护软件的标准过程被文档：在组织范围内开发和维护软件的标准过程被文档化，其中包括软件工程过程和管理过程，它们集成化，其中包括软件工程过程和管理过程，它们集成为一个一致的整体。为一个一致的整体。项目项目：对组织的标准软件过程进行裁剪，来开发它们自己：对组织的标准软件过程进行裁剪，来开发它们自己项目的软件过程。项目的软件过程。过程能力过程能力：是标准的和一致的。：是标准的和一致的。(standardandconsistent)建立了建立了“组织的标准软件过程组织的标准软件过程”：即即 关注的焦点转向组关注的焦点转向组织的体系和管理；织的体系和管理； 全组织建立了软件开发和维护的标准过程；全组织建立了软件开发和维护的标准过程； 软件工程过程和软件管理过程，被综合为软件工程过程和软件管理过程，被综合为个有机的整个有机的整体，并且已经体，并且已经文档化文档化。建立了负责组织的软件过程活动的机构：建立了负责组织的软件过程活动的机构：即即在软件组织中存在负责软件过程活动的机构，并具体实在软件组织中存在负责软件过程活动的机构，并具体实施全组织的过程制定、维护和改进。施全组织的过程制定、维护和改进。其中包括全组织的人员培训，使之具备必须的技能和其中包括全组织的人员培训，使之具备必须的技能和知识，能高效地履行其职责。知识，能高效地履行其职责。 项目定义的软件过程：项目定义的软件过程：即即项目能够依据其环境和需求等，通过剪裁组织的标准项目能够依据其环境和需求等，通过剪裁组织的标准 过程，使用组织的过程财富，自定义项目的软件过过程，使用组织的过程财富，自定义项目的软件过 程。其中，允许有一定的自由度，但任务间的不匹配程。其中，允许有一定的自由度，但任务间的不匹配 情况，应在过程规划阶段得到标识，并进行组间协调情况，应在过程规划阶段得到标识，并进行组间协调 和控制。和控制。组织可视项目的进展：组织可视项目的进展：即即由由于于项项目目自自定定义义的的软软件件过过程程将将开开发发活活动动和和管管理理活活功功综综合合为为一一个个协协调调的的、合合理理定定义义的的软软件件过过程程，并并明明确确规规定定了了每每一一活动的输入、输出、标准、规程和验证判据。因此：活动的输入、输出、标准、规程和验证判据。因此：管理者或软件项目负责人能够洞察管理者或软件项目负责人能够洞察 所有项目的技术进展、费用和进度所有项目的技术进展、费用和进度 组织的软件能力均衡、组织的软件能力均衡、致：致：即即由于：由于： 整整个个组组织织范范围围内内的的软软件件开开发发和和维维护护过过程程已已经经标标准准化化， 软软件工程技术活动和软件管理活动都实现文档化的规范管理，件工程技术活动和软件管理活动都实现文档化的规范管理， 组组织织和和项项目目的的软软件件过过程程都都是是稳稳定定的的、和和可可重重复复的的。 这这种种过过程程能能力力是是建建立立在在整整个个组组织织范范围围内内对对已已定定义义过过程程中中的的活活动动、作作用和职责的共同理解基础之上。用和职责的共同理解基础之上。因此：因此： 在整个组织范围内软件能力是均衡、一致的在整个组织范围内软件能力是均衡、一致的综上，可将综上，可将3 3级的过程能力特征表述为：级的过程能力特征表述为：定量管理级定量管理级实现了关键过程域：实现了关键过程域：定量过程管理定量过程管理和和软件质量管理。软件质量管理。主要特征：主要特征：项目项目：项目减小过程性能的变化性，使其进入可接收的：项目减小过程性能的变化性，使其进入可接收的量化边界，从而达到对产品和过程的控制。量化边界，从而达到对产品和过程的控制。组织组织：为软件产品和过程都设定了量化的质量目标。：为软件产品和过程都设定了量化的质量目标。过程能力过程能力：可预言的。：可预言的。(predictable)设置了定量的质量目标：设置了定量的质量目标：即即 组织对软件产品和过程设置了定量的质量目标；组织对软件产品和过程设置了定量的质量目标； 软件过程具有明确定义和一致的测量方法与手段；软件过程具有明确定义和一致的测量方法与手段；可以定量地评价项目的软件过程和产品质量可以定量地评价项目的软件过程和产品质量项目产品质量和过程是受控和稳定的：项目产品质量和过程是受控和稳定的：即即可以将项目的过程性能变化可以将项目的过程性能变化限制在一个定量的、可接受的范围之内。限制在一个定量的、可接受的范围之内。产品质量和过程是受控和稳定的产品质量和过程是受控和稳定的 开发新领域软件的风险是可定量估计的：开发新领域软件的风险是可定量估计的：即即由于组织的软件过程能力是已知的，从而可以利用全组由于组织的软件过程能力是已知的，从而可以利用全组织的软件过程数据库，分析并定量地估计出开发新领域织的软件过程数据库，分析并定量地估计出开发新领域软件的风险。软件的风险。 组织的软件过程能力是可定量预测的：组织的软件过程能力是可定量预测的：即即过程是经测量的并能在可预测的范围内运行，一旦发现过程是经测量的并能在可预测的范围内运行，一旦发现过程和产品质量偏离所限制的范围时，能够立即采取措过程和产品质量偏离所限制的范围时，能够立即采取措施予以纠正。施予以纠正。综上，该级的过程能力特征可表述为：综上，该级的过程能力特征可表述为：.?.?.?.?.?.?l持续优化级持续优化级 实现了关键过程域实现了关键过程域： 缺陷预防、技术变化管理、过程变化管理缺陷预防、技术变化管理、过程变化管理 主要特征主要特征：组织组织：关注于持续的过程改进。：关注于持续的过程改进。项目项目：软件过程被评价，以防止过失重复发生，从中：软件过程被评价，以防止过失重复发生，从中获得的教训散布给其它项目。获得的教训散布给其它项目。过程能力过程能力：持续的改善。：持续的改善。(continuouslyimproving)(1)(1)过程不断改进过程不断改进，即组织注重不断地进行过程改进。，即组织注重不断地进行过程改进。 组织有办法识别出过程的弱点，并及时地予以克服；组织有办法识别出过程的弱点，并及时地予以克服； 能能够够利利用用关关于于软软件件过过程程有有效效性性的的数数据据，识识别别最最佳佳软软件件 工程实践的技术创新，并推广到整个组织。工程实践的技术创新，并推广到整个组织。(2)(2)缺陷能有效预防缺陷能有效预防：即：即 软件项目组能分析并确定缺陷的发生原因，认真评价软件项目组能分析并确定缺陷的发生原因，认真评价软件过程，以防止同类缺陷再现，并且能将经验告知其软件过程，以防止同类缺陷再现，并且能将经验告知其他项目组。他项目组。(3)(3)组织的过程能力不断提高组织的过程能力不断提高：即：即 组织既能在现有过程的基础上以渐进的方式，又能组织既能在现有过程的基础上以渐进的方式，又能以技术创新等手段，不断努力地改善过程性能。以技术创新等手段，不断努力地改善过程性能。综上，该级的过程能力特征可表述为：综上，该级的过程能力特征可表述为：.?.?.?.?关于五个级别的关于五个级别的3点说明点说明从第从第1级提升到第级提升到第2级可能需要几年的时间，在其它级别间级可能需要几年的时间，在其它级别间提升通常依次需要提升通常依次需要2年的时间。年的时间。第第1级级组组织织的的成成功功依依赖赖于于组组织织中中人人员员的的能能力力。对对于于所所有有成成熟熟度度级级别别的的组组织织来来说说，选选择择、雇雇用用、培培养养和和保保持持有有能能力力的的人员都是重要的问题，但这超出了人员都是重要的问题，但这超出了CMM的范围。的范围。 每个级别为以后的级别有效地和有效率地实现过程提供基每个级别为以后的级别有效地和有效率地实现过程提供基础。跳过级别是达不到预期的目标的。础。跳过级别是达不到预期的目标的。 例如例如1 1：第：第1级的组织，如果在建立可重复的过程级的组织，如果在建立可重复的过程(第第2级级)之之前，试图实现定义的过程前，试图实现定义的过程(第第3级级)，通常是不会成功，通常是不会成功，因因为项目管理者被进度和开销压力所淹没为项目管理者被进度和开销压力所淹没。例如例如2 2：组织在没有定义过程的基础时，如果试图实现：组织在没有定义过程的基础时，如果试图实现管理的过程管理的过程(第第4级级)，通常是不会成功的。，通常是不会成功的。因为没有因为没有定义过程，就定义过程，就没有解释度量的共同基础。没有解释度量的共同基础。 例如例如3 3：组织在没有管理过程：组织在没有管理过程(第第4级级)的基础时，如果试的基础时，如果试图实现优化过程图实现优化过程(第第5级级)，通常是会失败的。，通常是会失败的。因为对过程改变的影响缺乏理解。因为对过程改变的影响缺乏理解。注意：注意： 和和 两点，说明了成熟度等级的演化特性。两点，说明了成熟度等级的演化特性。汇总汇总:各等级的关键过程域各等级的关键过程域（共（共18个）个）初始级初始级(1)软件配置管理软件配置管理软件质量保证软件质量保证软件子合同管理软件子合同管理软件项目跟踪和监督软件项目跟踪和监督软件项目规划软件项目规划需求管理需求管理可重复级可重复级(2)对等复审对等复审组间协作组间协作软件产品工程软件产品工程集成的软件管理集成的软件管理培训计划培训计划组织过程定义组织过程定义组织过程焦点组织过程焦点定义级定义级(3)软件质量管理软件质量管理量化的过程管理量化的过程管理管理级管理级(4)过程变化管理过程变化管理技术变化管理技术变化管理缺陷预防缺陷预防优化级优化级(5)4 4） 成熟度等级的内部结构成熟度等级的内部结构CMM的每个等级是通过三个层次加以定义的：的每个等级是通过三个层次加以定义的：关键过程域关键过程域公共特征公共特征关键实践关键实践成熟度等级关键过程区域关键过程区域(KPA)共同特征共同特征关键实践关键实践过程能力目标实现或制度化基础设施或活动包含指示组织达到包含解决描述成熟度等级成熟度等级过程能力过程能力指示其中：其中：成熟度等级成熟度等级(MaturityLevel)5个等级个等级良构定义的过程能力演化平良构定义的过程能力演化平台，作为以后过程改善活动台，作为以后过程改善活动的基础（的基础（foundation）。遵循一个过程所期遵循一个过程所期望的结果程度望的结果程度（Range）。）。Repeatablelevelindicates例如：可重复级例如：可重复级(Repeatablelevel)对项目的成本、进度和要完对项目的成本、进度和要完成的功能，建立了基本的项成的功能，建立了基本的项目管理。目管理。Time/Cost/QualityProbability关键过程域（关键过程域（KeyProcessArea）关键过程域是定义成熟度等级的主要构造块（关键过程域是定义成熟度等级的主要构造块（majorbuildingblocks）。）。每一个关键过程域是一组相关的活动，它们的共同执每一个关键过程域是一组相关的活动，它们的共同执行来达到一组目标。行来达到一组目标。关键过程域标识了为达到一个成熟度级别而必须强调关键过程域标识了为达到一个成熟度级别而必须强调的问题。的问题。MaturityLevel(18KPAsintheCMM.)KeyProcessAreasProcessCapabilityGoalsindicatecontainachieve建立组织过程能力中的主要构造建立组织过程能力中的主要构造块。块。RepeatableLevelProjectPlanningindicatecontain项目规划涉及工作量估算，建立必项目规划涉及工作量估算，建立必要的承诺（要的承诺（commitmentscommitments）, ,并定义并定义工作执行计划。工作执行计划。例如：例如：2级中的关键过程域：项目规划级中的关键过程域：项目规划ProbabilityTime/Cost/QualityMaturityLevelKeyProcessAreasProcessCapabilityGoalsindicatecontainachieve目标目标：表明一个关键过程域的范围、边界和意图。：表明一个关键过程域的范围、边界和意图。 关键过程域的目标（关键过程域的目标（Goals）过程目标（过程目标（objectives）：）：当达到这些目标时，就增当达到这些目标时，就增强了过程能力。强了过程能力。MaturityLevelKeyProcessAreasindicatecontainachieve例如：例如：Goal1:已建立了估算（结果）的文档，以便在已建立了估算（结果）的文档，以便在规划该项目和对项目进行跟踪时使用。规划该项目和对项目进行跟踪时使用。Goal2:Goal3:ProbabilityTime/Cost/QualityMaturityLevelKeyProcessAreasProcessCapabilityGoalsindicatecontainachieve公共特征（公共特征（CommonFeatures）是过程的一些属性，它们确保过程被定义、被理解，并建立是过程的一些属性，它们确保过程被定义、被理解，并建立了有关文档。了有关文档。指示：关键过程域是否是指示：关键过程域是否是有效的、可重复的、持久的有效的、可重复的、持久的实施实施/制度制度CommonFeaturesOrganizedbyaddress确保过程被定义、已建文档和确保过程被定义、已建文档和理解的属性（理解的属性（Attributes）公共特征：用于组织在每一个关键过程域中的关键实践。公共特征：用于组织在每一个关键过程域中的关键实践。包括：包括：制度制度实施实施CommitmenttoPerformActivitiesPerformedAbilitytoPerformMeasurementandAnalysisVerifyingImplementationRepeatableLevelProjectPlanningindicatecontains“依据明文规定的规程，估算依据明文规定的规程，估算工作产品的规模（或改变工作工作产品的规模（或改变工作产品的规模）。产品的规模）。例如：例如：ProbabilityTime/Cost/QualityActivitiesPerformedOrganizedbyActivity9contains已建立了软件估算（结已建立了软件估算（结果）的文档，以便在规果）的文档，以便在规划该项目和对项目进行划该项目和对项目进行跟踪时使用。跟踪时使用。Goal1achieves实施实施addresses有关实施（有关实施（Implementation）的公共特征）的公共特征执行的活动（执行的活动（ActivitiesPerformed）描述了为实现一个关键过程域所需要的角色和规程（描述了为实现一个关键过程域所需要的角色和规程（procedures）。）。通常包括：通常包括：-如何建立计划和规程；如何建立计划和规程；-如何实施该任务；如何实施该任务；-如何跟踪之；如何跟踪之；-必要时所采取的纠正措施。必要时所采取的纠正措施。有关制度（有关制度（Institutionalization）的公共特征）的公共特征对执行的承诺（对执行的承诺（Commitmenttoperform）描述组织必须采取的动作（描述组织必须采取的动作（actions），以便保证过程的），以便保证过程的建立并持久（建立并持久（endure）.通常包括：通常包括：-政策（政策（policies）-高管的地位和任务（高管的地位和任务（seniormanagementsponsorship）-责任的指定（责任的指定（responsibilityassignment）执行能力（执行能力（Abilitytoperform）描述该项目或组织中必须有的前置条件，以便很好地实描述该项目或组织中必须有的前置条件，以便很好地实现该过程。现该过程。通常包括：通常包括：-资源（资源（resources）-组织结构（组织结构（organizationstructure）-委托、授权（委托、授权（delegation）-培训（培训（training）-过程定位（过程定位（orientation）RepeatableLevelProjectPlanningindicatecontains“软件经理在软件估算和规划软件经理在软件估算和规划规程方面已得到培训。规程方面已得到培训。例如：例如：ProbabilityTime/Cost/QualityAbilitytoPerformOrganizedbyAbility4containsSoftwareestimatesaredocumentedforuseinplanningandtrackingtheprojectGoal1achievesinstitutionalizationaddresses测量和分析（测量和分析（MeasurementandAnalysis）描述了测量过程并分析该测量的要求，从而提供了对关描述了测量过程并分析该测量的要求，从而提供了对关键过程域实现情况的观察。键过程域实现情况的观察。通常包括：通常包括：一些测量实例，可以使用这些实例来确定所执行活动一些测量实例，可以使用这些实例来确定所执行活动（ActivitiesPerformed）的有效性。的有效性。实施验证（实施验证（VerifyingImplementation）描述了一些步骤，这些步骤确保活动的执行符合已经描述了一些步骤，这些步骤确保活动的执行符合已经建立的那个过程。建立的那个过程。通常包括：通常包括：由由-高管（高管（seniormanagement）、）、-项目管理人员项目管理人员-质量保证质量保证所进行的复审和审计。所进行的复审和审计。以上提及的以上提及的5 5个公共特征，有助于确保过程的实施和制度建个公共特征，有助于确保过程的实施和制度建设，有助于确保获得坚实的过程质量。设，有助于确保获得坚实的过程质量。为什么要将建立过程的制度：为什么要将建立过程的制度：是我们做事情的方式（是我们做事情的方式（way）建立一个制度，包括围绕该组织，有效的、可用的、建立一个制度，包括围绕该组织，有效的、可用的、一致的来应用过程一致的来应用过程制度的建立，涉及：培训、标准和规程、政策和验证。制度的建立，涉及：培训、标准和规程、政策和验证。制度化的过程确保了以后的人们可以按此来工作。制度化的过程确保了以后的人们可以按此来工作。制度的重要性：制度的重要性：开发组织可以经受人员调离的风险；开发组织可以经受人员调离的风险；组织文化必须传播这些过程，即制度化的过程是组织组织文化必须传播这些过程，即制度化的过程是组织文文化的一个组成部分，化的一个组成部分，管理上必须培育这一文化；管理上必须培育这一文化；通过角色和鼓励，文化予以传播，。通过角色和鼓励，文化予以传播，。 关键实践：关键实践：为一个关键过程域，给出基础性的政策、规程和活动。为一个关键过程域，给出基础性的政策、规程和活动。关于关键实践的关于关键实践的3点说明点说明与关键过程域之间的关系：与关键过程域之间的关系：通过实施一个关键过程域中所通过实施一个关键过程域中所包包含含的的关关键键实实践践（“小小”的的进进化化），才才可可以以达达到到该该关关键键过过程程域中的目标。域中的目标。表表述述问问题题：在在CMM中中，“关关键键实实践践”的的表表述述， 一一般般只只给给出出 “做什么做什么”。 CMM共有共有316个关键实践，被组织为个关键实践，被组织为5个公共特征，支个公共特征，支持相关关键过程域的一个或多个目标。持相关关键过程域的一个或多个目标。RepeatableLevelProjectPlanningindicatecontains“依据明文规定的规程，估算依据明文规定的规程，估算工作产品的规模（或改变工作工作产品的规模（或改变工作产品的规模）。产品的规模）。.”例如：例如：ProbabilityTime/Cost/QualityActivity9contains“已建立了软件估算（结已建立了软件估算（结果）的文档，以便在规果）的文档，以便在规划该项目和对项目进行划该项目和对项目进行跟踪时使用。跟踪时使用。”Goal1achieves关键过程域、目标以及关键实践之间关系的例子关键过程域、目标以及关键实践之间关系的例子：关键过程域关键过程域“软件项目规划软件项目规划”目的：目的：为软件工程的执行和项目管理，建立合理的为软件工程的执行和项目管理，建立合理的（reasonable）计划计划涉及：涉及：-估算要执行的工作；估算要执行的工作；-建立必要的承诺；建立必要的承诺；-定义执行工作的计划。定义执行工作的计划。项目计划的组成：项目计划的组成：可以采用不同的方法予以开发。其中包含：可以采用不同的方法予以开发。其中包含：-开发计划开发计划-质量保证计划质量保证计划-配置管理计划配置管理计划-风险管理计划风险管理计划-测试计划测试计划-项目培训计划项目培训计划例如：开发计划的基本内容：例如：开发计划的基本内容：-该项目选择的系统生存周期该项目选择的系统生存周期-开发的一系列产品开发的一系列产品-进度进度-工作量、成本和人员等的估算工作量、成本和人员等的估算-设施、支持工具以及硬件设施、支持工具以及硬件-项目风险（成本、进度以及关键的风险管理）项目风险（成本、进度以及关键的风险管理）项目规划的目标（项目规划的目标（Goals）：）：3个个目标目标1建立了软件估算的文档，以便在规划和跟踪该软件项建立了软件估算的文档，以便在规划和跟踪该软件项目中使用。目中使用。目标目标2规划了软件项目活动和承诺，并建立了相应的文档。规划了软件项目活动和承诺，并建立了相应的文档。目标目标3相关小组同意了他们对该软件项目的承诺。相关小组同意了他们对该软件项目的承诺。与目标与目标1相关的活动相关的活动目标目标1建立了软件估算的文档，以便在规划和跟踪该软件项目中建立了软件估算的文档，以便在规划和跟踪该软件项目中使用。使用。-活动活动9：依据明文规定的规程，估算软件工作产品规模：依据明文规定的规程，估算软件工作产品规模（size）（或改变软件工作产品的规模）（或改变软件工作产品的规模）-活动活动10：依据明文规定的规程，估算软件项目工作量和成本：依据明文规定的规程，估算软件项目工作量和成本-活动活动11：依据明文规定的规程，估算项目关键的计算机资源：依据明文规定的规程，估算项目关键的计算机资源-活动活动12：依据明文规定的规程，导出软件项目进度。：依据明文规定的规程，导出软件项目进度。-活动活动15：记录软件规划数据。：记录软件规划数据。与目标与目标2相关的活动相关的活动目标目标2规划并建立了软件项目活动和承诺的文档。规划并建立了软件项目活动和承诺的文档。-活动活动3：软件工程组以及相关的小组，参与整个项目生存周：软件工程组以及相关的小组，参与整个项目生存周期中的项目规划工作。期中的项目规划工作。-活动活动5：以可管理的、预先定义的阶段，标识并定义该软件：以可管理的、预先定义的阶段，标识并定义该软件生存周期生存周期-活动活动6：依据明文规定的规程，开发该项目的软件开发计划：依据明文规定的规程，开发该项目的软件开发计划-活动活动7：建立该计划的文档。：建立该计划的文档。-活动活动8：标识为建立并维护控制该软件项目所需要的软件工：标识为建立并维护控制该软件项目所需要的软件工作产品。作产品。-活动活动13：标识并评定该项目在成本、进度和技术方面的风险：标识并评定该项目在成本、进度和技术方面的风险并建立相关的文档。并建立相关的文档。-活动活动15：编制有关该项目的软件工程设施和支持工具的计划：编制有关该项目的软件工程设施和支持工具的计划与目标与目标3相关的活动相关的活动目标目标3有关的小组或个人同意了他们对该软件项目的承诺。有关的小组或个人同意了他们对该软件项目的承诺。-活动活动1：软件工程组参与项目提案组（：软件工程组参与项目提案组（proposalteam）的）的工工作作-活动活动2：软件项目规划在整个项目规划的早期启动，并与之：软件项目规划在整个项目规划的早期启动，并与之并行进行。并行进行。-活动活动4：依据明文规定的规程，与高级管理人员一起复审对：依据明文规定的规程，与高级管理人员一起复审对组织之外的个人或小组所做的软件项目承诺，组织之外的个人或小组所做的软件项目承诺，关于等级内部结构的小结关于等级内部结构的小结每个等级每个等级由几个关键过程域组成，它们共同形成由几个关键过程域组成，它们共同形成定的定的 过程能力。过程能力。每个关键过程域每个关键过程域都有一些特定的目标，为实现这些目标，都有一些特定的目标，为实现这些目标， 将实现目标的关键实践组织为五类关键实践。将实现目标的关键实践组织为五类关键实践。公共特征（关键实践类）公共特征（关键实践类）规定了相应部门或有关责任者应实施的一些关键规定了相应部门或有关责任者应实施的一些关键 实践。当关键过程域的这些关键实践都得到实施实践。当关键过程域的这些关键实践都得到实施 时，就能够实现该关键过程域的目标。时，就能够实现该关键过程域的目标。关键实践关键实践按公共特征组织，按公共特征组织，描述了为有效实施并规范化关键描述了为有效实施并规范化关键过程域，应具备的过程域，应具备的基础设施基础设施和从事的和从事的活动活动。一个关键过程域的关键实践的一个关键过程域的关键实践的实施实施是实现该关键过程域目标的是实现该关键过程域目标的必要条件必要条件。 仅当一个关键过程域的全部目标均已达到时，该关键过仅当一个关键过程域的全部目标均已达到时，该关键过 程域才能实现。程域才能实现。一个成熟度等级的一个成熟度等级的关键过程域的完全实现关键过程域的完全实现是达到该成熟度等级的是达到该成熟度等级的必要条件必要条件； 对于一个组织来说，仅当其所有项目均已达到一个关键对于一个组织来说，仅当其所有项目均已达到一个关键 过程域的目标时，才可以说，该组织己使以该关键过过程域的目标时，才可以说，该组织己使以该关键过 程域为特征的软件过程程域为特征的软件过程( (软件能力软件能力) )规范化了。规范化了。5)关于关于CMM的总结的总结(1)知识点知识点软件能力成熟度等级框架软件能力成熟度等级框架：在这一框架中，在这一框架中，将将过程能力成熟度分为过程能力成熟度分为5 5级级：初始级初始级，可重复级可重复级，已定义级，已管理级已定义级，已管理级，持续优化级持续优化级。 通过成熟度级别通过成熟度级别，定义了定义了在在使软件过程成熟的过程使软件过程成熟的过程中中的的演化状态演化状态。通过通过过程改善过程改善，实现了有关关键过程域的目标，才，实现了有关关键过程域的目标，才能演化为更高的一级，其中不可能能演化为更高的一级，其中不可能“飞跃飞跃”；软件成熟度框架软件成熟度框架基础基础是等级的内部结构。是等级的内部结构。每一等级的内部结构每一等级的内部结构成熟度级别关键过程区域关键过程区域(KPA)共同特征共同特征关键实践关键实践过程能力目标实现或制度化基础设施或活动包含指示组织达到包含解决描述等级、关键过程等级、关键过程域、关键实践之域、关键实践之间的基本关系间的基本关系其中：其中： 关键过程域关键过程域：在框架的某一：在框架的某一“平台平台”上，其实施将对达到上，其实施将对达到下一成熟度等级的目标起保证作用的过程域，被称为关键下一成熟度等级的目标起保证作用的过程域，被称为关键过程域。过程域。各级包含的关键过程域：各级包含的关键过程域： 可重复级：可重复级：软件配置管理，软件质量管理，子产品工程软件配置管理，软件质量管理，子产品工程 项目跟踪和监督，软件项目规划，需求管理项目跟踪和监督，软件项目规划，需求管理 已定义级：已定义级：对等复审，组间协作，软件产品工程，集成对等复审，组间协作，软件产品工程，集成 的软件管理，培训计划，组织过程定义，组的软件管理，培训计划，组织过程定义，组 织过程焦点织过程焦点 已管理级：已管理级：软件质量管理，量化的过程管理软件质量管理，量化的过程管理 持续优化级：持续优化级：过程变化管理，技术变化管理，缺陷预防过程变化管理，技术变化管理，缺陷预防每一关键过程域包含每一关键过程域包含一组关键实践一组关键实践。并按。并按“共同特征共同特征”予以组织。予以组织。公共公共特征特征实施承诺实施承诺(CommitmenttoPerform) 描述为了保证软件过程的建立和持续执行软件开发组织所需描述为了保证软件过程的建立和持续执行软件开发组织所需 采取的活动，包括：采取的活动，包括： 方针政策、方针政策、 高层管理者的保障、其它高层管理者的保障、其它责责 任等任等 实施能力实施能力 描述为了很好地实施软件过程所需的先决条件。包括：描述为了很好地实施软件过程所需的先决条件。包括： 资源、组织结构、培训等资源、组织结构、培训等实施活动实施活动 描述为了实现关键过程域所需的角色及其进行的活动或过程描述为了实现关键过程域所需的角色及其进行的活动或过程度量与分析度量与分析 描述为了度量软件过程和分析度量结果所需的活动描述为了度量软件过程和分析度量结果所需的活动验证实现验证实现 描述为了保证过程的实施情况和所定义的过程完全一致所描述为了保证过程的实施情况和所定义的过程完全一致所 需的验证步骤。需的验证步骤。关键实践关键实践：描述了对关键过程域的实施起关键作用的：描述了对关键过程域的实施起关键作用的方针方针规程、措施、活动规程、措施、活动以及以及相关的基础设施相关的基础设施。在表述中，。在表述中，一一 般般只给出只给出“做什么做什么”，而不规定，而不规定“如何做如何做”通过实施一个关键过程域中所包含的关键实践，才可以通过实施一个关键过程域中所包含的关键实践，才可以达到该关键过程域中的目标。达到该关键过程域中的目标。CMM不涉及的问题不涉及的问题CMM没有强调的没有强调的,但间接但间接隐含涉及的问题：隐含涉及的问题：-特定的工具、方法学和技术；特定的工具、方法学和技术；-并发工程和小组工作（并发工程和小组工作（teamwork）；）；-管理咨询，市场等；管理咨询，市场等；-人力资源；人力资源；-组织行为。组织行为。(2)基本思想基本思想强调过程途径强调过程途径“一个软件系统的质量，取决于所使用的开发过程和维护一个软件系统的质量，取决于所使用的开发过程和维护过程的质量。过程的质量。”“整个软件任务可以看作是一个过程，该过程可以予以控整个软件任务可以看作是一个过程，该过程可以予以控制、测量和改进。制、测量和改进。”产品质量形成于产品生产的全过程：产品质量形成于产品生产的全过程： 应使影响产品质量的全部因素，在生产全过程中始终应使影响产品质量的全部因素，在生产全过程中始终处于受控状态；并且处于受控状态；并且 质量管理应遵循质量管理应遵循PDCA循环（即计划循环（即计划Plan实施实施Do检检查查Check措施措施Action），坚持进行过程质量改善），坚持进行过程质量改善,增强增强过程能力。过程能力。在在HumphreyHumphrey1989的软件过程管理一书中，列出的软件过程管理一书中，列出了软件过程变更的六项原则：了软件过程变更的六项原则：-对软件过程的重要变更，必须由主管领导批准。对软件过程的重要变更，必须由主管领导批准。-项目有关人员都必须介入项目有关人员都必须介入,因为软件工程是一项集体劳动。因为软件工程是一项集体劳动。-有效的变更需要一个目标和过程的当前状态有效的变更需要一个目标和过程的当前状态,因此变更时必因此变更时必须知道自己的须知道自己的”位置位置”。-变化是永恒的。软件过程改善需要不断学习和进步。变化是永恒的。软件过程改善需要不断学习和进步。-软件过程变更不能因为缺乏主观努力和定期监督而停滞不软件过程变更不能因为缺乏主观努力和定期监督而停滞不前。前。-软件过程改善需要投资。改善软件过程需要时间、技能和软件过程改善需要投资。改善软件过程需要时间、技能和资金。资金。理论基础理论基础 费根堡姆的费根堡姆的质量体系概念质量体系概念： “在制造及传递某种合乎特定质量标准的产品时，必须在制造及传递某种合乎特定质量标准的产品时，必须 配合适当的管理及技术作业程序，这些程序所组成的配合适当的管理及技术作业程序，这些程序所组成的 结构，称之为质量体系结构，称之为质量体系”。CMM是（是（依据依据软件过程特点）软件过程特点）质量体系概念的一个实现质量体系概念的一个实现注注:软件质量的定义软件质量的定义ANSI/IEEEStd729-1983：软件质量为软件质量为“与软件产品满足与软件产品满足规定的和隐含的需求能力有关的特征或特性的全体规定的和隐含的需求能力有关的特征或特性的全体”。可见可见,软件质量反映了以下三方面的问题：软件质量反映了以下三方面的问题：软件需求是度量软件质量的基础，不满足需求的软件就软件需求是度量软件质量的基础，不满足需求的软件就不具备质量；不具备质量；不遵循各种标准中定义的开发规则，软件质量就得不到保不遵循各种标准中定义的开发规则，软件质量就得不到保证；证； 只满足明确定义的需求，而没有满足应有的隐含需求，只满足明确定义的需求，而没有满足应有的隐含需求，软软件质量也得不到保证。件质量也得不到保证。(3)使用经验使用经验在已发表的许多文章中，描述了成功使用在已发表的许多文章中，描述了成功使用CMM的案例的案例Paulish&Carleton1994,Grady1996,Lowe&Cox1996。作者指出对成功的软件过程改善而言，其主要需求有作者指出对成功的软件过程改善而言，其主要需求有4：-软件工程师确信需要一个标准过程。软件工程师确信需要一个标准过程。-适当培训是基本的要求。适当培训是基本的要求。-需要一个清晰定义的改善模型。需要一个清晰定义的改善模型。-失败和缺陷分析是重要的。失败和缺陷分析是重要的。他们认为主要益处为：他们认为主要益处为：-增强应对变更的能力。增强应对变更的能力。-可能会减少用在对项目进行考察阶段的时间。可能会减少用在对项目进行考察阶段的时间。-提高成熟度等级，促进已被证明的最佳实践在一个组提高成熟度等级，促进已被证明的最佳实践在一个组织中的传播。织中的传播。(4)受影响的其它模型受影响的其它模型SW-CMM是第一个是第一个“阶梯式阶梯式”(存在多个不同等级存在多个不同等级)过程评过程评估模型。在其启发下开发了许多其它估模型。在其启发下开发了许多其它CMM，包括人员，包括人员CMM、系统工程、系统工程CMM、软件获取、软件获取CMM和集成产品管理的和集成产品管理的CMM等等,每个每个CMM的应用都是为了不同的目的，是对的应用都是为了不同的目的，是对SW-CMM的补充。其中包括的补充。其中包括Humphrey提出了两个新的基于提出了两个新的基于SW-CMM的模型，一个是的模型，一个是”个人软件过程（个人软件过程（Thepersonalsoftwareprocess,PSP）”，它是，它是“一个自改善过程一个自改善过程”，“帮帮助你控制、管理和改善的工作方式助你控制、管理和改善的工作方式”；另一个是；另一个是”小组软件小组软件过程（过程（Theteamsoftwareprocess,TSP）”，是为软件开发，是为软件开发小组设计的，起着与小组设计的，起着与PSP相似的作用。相似的作用。SEI在在SW-CMM2.0版本版本(这个版本并没有发布这个版本并没有发布)形成过程中，形成过程中，又启动了一个新的项目，称为又启动了一个新的项目，称为CMMI，其目标是集成三个重，其目标是集成三个重要的要的CMM，即，即SW-CMM（软件（软件CMM），），SE-CMM（系统（系统工程工程CMM）和）和IPD-CMM（集成产品开发（集成产品开发CMM，IntegratedproductdevelopmentCMM）。）。）。）。按按SchaefferSchaeffer1998的说法，这一决定是根据美国的说法，这一决定是根据美国国防部提出的改革意见做出的，他们要求创建一种更有意义国防部提出的改革意见做出的，他们要求创建一种更有意义的范例，从理性上的范例，从理性上“怎么做怎么做”的途径转移到基于目标和基于的途径转移到基于目标和基于性能需求陈述的途径。而性能需求陈述的途径。而SW-CMM、SE-CMM和和IPD-CMM在配置、质量以及需求管理方面存在的共性，从导致在配置、质量以及需求管理方面存在的共性，从导致了了SW-CMM2.0版本的停止和版本的停止和CMMI项目的建立。项目的建立。起源与应用起源与应用最早使用最早使用ISO9000系列标准是从英国开始的，系列标准是从英国开始的，称为称为BS5750和和EN29000。ISO9000系列标准是独立开发的系列标准是独立开发的,与与SW-CMM相比相比,是一种完是一种完全不同的控制软件过程质量的途径。全不同的控制软件过程质量的途径。这一系列标准广泛用于服务业和制造业。这一系列标准广泛用于服务业和制造业。目前的版本目前的版本ISO9000:2000有以下基本的组成部分：有以下基本的组成部分：ISO9000质量管理系统基本原则和术语质量管理系统基本原则和术语ISO9001质量管理系统需求质量管理系统需求ISO9004质量管理系统性能改善指南质量管理系统性能改善指南ISODIS19011：质量和：质量和/或环境管理系统审计指南或环境管理系统审计指南(5)ISO9000系列标准系列标准一般认为，一般认为，ISO9000系列中最适合用于软件的是系列中最适合用于软件的是ISO9001（等同于（等同于BS5750的第一部分，的第一部分，EN29001-该标准的欧洲版本），该标准的欧洲版本），而且开发出了而且开发出了ISO9001应用于软件的应用指南，即所谓的应用于软件的应用指南，即所谓的ISO9000-3：软件开发和维护的：软件开发和维护的ISO9001应用指南。应用指南。英国对软件组织开展了大量的英国对软件组织开展了大量的TickIT认证认证,以确定是否符合以确定是否符合ISO9001。在世界的其他地区，受。在世界的其他地区，受TickIT认证影响最大的国家认证影响最大的国家是印度、韩国和日本。可见是印度、韩国和日本。可见,TickIT认证在世界各地也会得到认证在世界各地也会得到一定的认可。一定的认可。ISO 9000-3ISO 9000-3与相关与相关标准之间关系标准之间关系ISO9001：质量管理体系：质量管理体系需求需求ISO/IEC12207：信息技术：信息技术软件生存周期过程软件生存周期过程ISO9000-3：质量管理和质量保证标准：质量管理和质量保证标准第第3部分：部分：ISO9001：1994在计算机软件开发、供应、安装和维护中在计算机软件开发、供应、安装和维护中的使用指南的使用指南解释和实施指南解释和实施指南参照参照ISO9000-3主要是给出了软件开发中的质量管理体系框架。主要是给出了软件开发中的质量管理体系框架。其中其中包括：供需双方的责任，供需双方所进行的一些有组织的包括：供需双方的责任，供需双方所进行的一些有组织的质量活动，以及与之相关的规范化（文档化）。而没有规定质质量活动，以及与之相关的规范化（文档化）。而没有规定质量管理以及每一活动所采用的方法和程序。量管理以及每一活动所采用的方法和程序。其要点是：其要点是：软件企业实施软件企业实施ISO9000质量标准，应选择质量标准，应选择ISO9001质量保证模式，需贯彻执行其质量保证模式，需贯彻执行其20个质量体系要素。个质量体系要素。ISO9000-3针对上述针对上述20个要素在软件企业中实施做出了解释。个要素在软件企业中实施做出了解释。 ISO9000-3与与ISO9001标准的文本描述是完全对应的。标准的文本描述是完全对应的。因此可以说，因此可以说，ISO9000-3是是质量体系质量体系这一概念在注重质这一概念在注重质量的软件开发中之应用；目的是：量的软件开发中之应用；目的是：为软件企业实施为软件企业实施ISO9001提供了一个指南。提供了一个指南。谢谢谢谢！