需求不一致管理

Vol.16, No.7 ©2005 Journal of Software 软 件 学 报 1000-9825/2005/16(07)1221 关于软件需求中的不一致性管理* 朱雪峰 1,2+, 金 芝 1,3 1(中国科学院 计算技术研究所,北京 100080) 2(中国科学院 研究生院,北京 100049) 3(中国科学院 数学与系统科学研究院,北京 100080) Managing the Inconsistency of Software Requirements ZHU Xue-Feng1,2+, JIN Zhi1,3 1(Institute of Computing Technology, The Chinese Academy of Sciences, Beijing 100080, China) 2(Graduate School, The Chinese Academy of Sciences, Beijing 100080, China) 3(Academy of Mathematics and System Sciences, The Chinese Academy of Sciences, Beijing 100080, China) + Corresponding author: Phn: +86-10-62565533 ext 5668, E-mail: zhuxuefeng@ict.ac.cn, http://knowledge_science.ict.ac.cn Received 2004-10-10; Accepted 2005-02-03 Zhu XF, Jin Z. Managing the inconsistency of software requirements. Journal of Software , 2005,16(7): 1221- 1231. DOI: 10.1360/jos161221 Abstract: Analyzing and handling the inconsistency in requirements is critical to the development of complex software systems. How to solve this problem directly influences the quality of requirements specification, as well as the final software production. Based on a common-recognized management framework of requirements inconsistency, this paper summarizes representative researches on this topic. The main aim is to get a comprehensive understanding of the current techniques and methods of inconsistency management. Finally, the paper also identifies some issues which are still open to further research. Key words: requirements engineering; requirements specification; management of requirements inconsistency 摘 要: 复杂软件系统开发的一个关键问题是分析和处理可能存在的不一致的需求描述.这个问题解决得好 坏直接影响到需求规格说明的质量,进而影响到最终软件产品的质量.在目前公认的一个不一致需求管理框架 的基础上,就需求不一致性管理方面的有代表性的工作,进行了较为系统的分析,以期建立对当前需求中,关 于不一致的需求管理方法和技术的全面认识.最后,对需求不一致性管理方面的研究进行了展望. 关键词: 需求工程;需求描述;需求不一致性的管理 中图法分类号: TP18 文献标识码: A * Supported by the National Natural Science Key Foundation of China under Grant No.60233010 (国家自然科学重点基金); the Grand Project of the National Natural Science Foundation of China under Grant No.60496324 (国家自然科学基金重大项目); the National Grand Fundamental Research 973 Program of China under Grant No.2002CB312004 (国家重点基础研究发展 (973)); the Knowledge Innovation Program of the Chinese Academy of Sciences (中国科学院知识创新工程项目) 作者简介: 朱雪峰 (1973 ),男,河南雎县人,博士生,主要研究领域为需求工程;金芝 (1962 ),女,博士,研究员,博士生导师,CCF 高级会员,主要研究领域为人工智能,需求工程,基于知识的软件工程. 万方数据 1222 Journal of Software 软件学报 2005,16(7) 在人类社会中 ,知识和信息的不一致性是普遍存在的 .而软件系统的需求来自于人类对现实社会的知识和 期望[1] ,从有可能不一致的知识或期望中归结出来的软件需求也不可避免地存在不一致的可能性.不一致需求 是普遍存在的这个观点目前已经得到广泛的共识[2 -4].另一方面,人类社会允许矛盾的知识和信息以不同的形 式出现在不同的人 甚至同一个人的身上 ,而不需要事先进行特别的处理,一般都是在矛盾发生时才予以考虑. 但软件系统就其本质而言是一个形式系统 ,一旦确定后,机器只会照章办事,因此必须事先确保软件系统的需求 描述是完备 确定和无矛盾的,否则会导致软件系统运行时错误,直接影响系统的安全性和可靠性.如何管理需 求中的不一致性,已经成为软件工程,特别是需求工程中的一个重要问题. 目前,已经存在一些关于需求不一致性管理方面的工作,综合起来看,可以分为两大类.第 1 类是讨论一般意 义上的需求不一致性管理框架,包括一般的管理原则和主要活动.第 2 类则结合具体的需求建模方法 ,讨论具体 的需求不一致性分析和处理策略. 本文首先介绍一般意义上的需求不一致性管理框架,然后再结合具体的需求建模方法分析不同的需求不 一致分析和处理策略,由于需求不一致产生的根本原因之一,是需求描述元素的指称域之间存在隐含的重叠关 系,因此本文还在第 3 节讨论了当前关于描述元素指称域重叠的检测的工作.最后,文章分析了一些代表性方法 的特征和优缺点,并探讨了需求不一致性管理的发展趋势. 1 不一致的需求管理框架 对需求不一致性的管理 ,还没有公认为系统性的解决方案.就目前的研究现状来看,Nuseibeh 等人的工作[5] 可以说是具有代表性的 ,也是最为全面的 .他们提出了一个需求不一致性的管理模式,如图 1 所示 ,其基本思路 为,任何需求建模方法都隐含了一组维护其一致性的规则 ,当所获取的需求中包含了不满足这组一致性规则约 束的命题时,即可认为出现了不一致性,需要进行进一步的处理. 在这个框架中,一致性规则[6]起到了至关重要的作用,因为是否出现了需求不一致性完全是相对于这些规 则而言的.那么,什么可以作为一致性规则呢?这个管理框架并没有明确.采用什么作为一致性规则 ,完全依 赖于系统分析员当前的关注点.例如文献[7]曾列举如下的一些可能的一致性规则: 1. 良构性规则:语言的合法性,即需求的表示要符合所采用的描述语言的语法; 2. 描述同一性规则:要求需求描述中完全重叠的不同描述元素必须是同一的; 3. 应用领域规则:说明在该软件的应用领域中个体之间应满足的关系; 4. 开发兼容性规则:要求软件开发不同阶段的模型要遵循相同的约束; 5. 开发过程柔性规则:项目所遵循的特定的软件工程实践或的模型具有柔性. 在上述规则实例中,有些是可以进行自动处理的 ,如规则 1 和规则 2;有些是不能进行自动处理的,如规则 4 和规则 5;而如规则 3这样的规则是否能够进行自动处理,依赖于需求描述和一致性规则的形式化程度. 这个不一致性管理框架还明确指出了需求不一致性管理中的任务,主要包括: (1) 需求不一致性的检测和诊断,包括不一致性的识别 定位和分类; (2) 需求不一致性的处理,处理策略包括立即消除 暂时容忍和完全忽略; (3) 需求不一致性的度量以及对需求不一致性的影响和风险评估. 这个框架可以说是普适的.但是它只给出了一个总体的结构和过程 ,其对不一致需求处理的能力 ,比如说能 够管理哪种形式(如语法上或语义上)的不一致性以及管理到何种程度 (如自动化程度等),则完全依赖于所预定 的一致性规则以及需求的表示形式及其形式化程度. 另一类相关研究工作是多视点需求建模的不一致性管理[8] ,多视点方法从不同视点对系统进行了划分,它 将系统整体需求划分为多个相互独立的局部视图 ,并使用不同的手段对多个视点分别进行建模,以期获得尽可 能完备的系统需求 .需求不一致性管理在多视点需求建模方法中格外重要,这是因为多视点方法用视点划分实 现了系统的分解 ,要求从多个视点进行系统建模,在最后进行系统视点集成的时候 ,分别建模的多个视点模型之 间常常蕴涵不一致的信息,必须考虑这些不一致信息的管理问题.多视点需求建模中的不一致性管理主要考虑 的也是上述几个方面的问题. 万方数据 朱雪峰 等:关于软件需求中的不一致性管理 1223 Manage inconsistency M on ito r f or in co ns is te nc y Diagnose Locate Identify Classify Measure inconsistency In co ns ist en cy d et ec te d In co ns ist en cy ch ar ac te riz ed Ignore Handle Tolerate Resolve Consistency checking rules Apply rules Apply rules R ef in e ru le s A pp ly ru le s M on ito r c on se qu en ce s o f h an dl in g a ct io n (s ) Defer Circumvent Ameliorate Analyze impact & risk A pp ly ru le s R ef in e ru le s In co ns is te nc y ha nd le d Fig.1 Rule-Based management framework of requirements inconsistency [5] 图 1 基于一致性规则的需求不一致性管理框架[5] 2 需求不一致性处理的主要方法 自动(或半自动 )的需求不一致性分析和处理方法 ,与需求建模的原则和需求模型的表示形式密切相关.目 前有代表性的研究工作可分为 3 类,第 1 类 ,采用经典逻辑或准经典逻辑作为需求表示形式,并利用定理证明技 术进行需求不一致性的处理;第 2 类,采用状态变迁作为需求建模原则,并利用模型检验技术进行需求不一致性 的处理;第 3 类,以系统目标这个元概念作为需求建模原则,并利用目标的语义模式和关于目标的启发式规则进 行需求不一致性的处理. 2.1 基于定理证明的方法 此类方法的主要特征是 :假设任何需求描述都可以表示为逻辑断言,采用经典逻辑 时态逻辑或其他非经 典逻辑等作为需求描述的形式化表示形式 ,利用定理证明的手段,采用标准逻辑推理规则,如归结 联结 否定 消除 全称量词的实例化,以及其他一些类似于封闭世界假设这样的规则,找出需求描述中蕴涵的矛盾.若检测 出矛盾 ,即表明存在不一致的需求描述.这种方法的优点是能够支持自动的需求不一致性检测,并具有良定的检 测过程和语义.但是定理证明在计算上的低效率妨碍了技术本身的可行性,此外,一阶逻辑的半可判定性也限制 了这种技术的实用性. 按处理能力来分,这种方法又可以进一步分为基于经典逻辑的方法和基于准经典逻辑的方法两种. 2.1.1 基于经典逻辑的方法 早期采用经典逻辑进行需求不一致性检测的工作[9,10],典型的是以 CORE[11]作为需求获取框架的.在 CORE 框架中,需求分为两个部分:AS(Agent structuring)阶段产生的全局Agent 层次(如文献[9]中的图 6)以及 TC(table collection)阶段产生的活动表(如文献[9]中的图 4)的集合. 万方数据 1224 Journal of Software 软件学报 2005,16(7) 在进行需求不一致性检测之前,首先需要为 CORE框架定义一组一致性规则,例如: · 视点内一致性规则:活动表中的任何“源(source)”和“目的地(destination)”都必须在 Agent 层次上作为一 个叶子 Agent 出现. · 视点间一致性规则:由 Agent(X)的一个活动表产生的到目的地 (Y)的输出(Z),必须作为(Y)的某个活动表 的来自源(X)的输入(Z). 具体处理过程是,首先将 CORE活动表所表示的活动定义为如下形式的事实公式: table(Source,Input,Action,Output,Destination) 构成活动事实库 ,再将所规定的一致性规则表示为对应的逻辑蕴涵式.然后,利用带封闭世界假设的经典逻辑定 理证明器,来验证这组逻辑公式集合的一致性.若出现矛盾的推论,则表明这组需求描述中蕴涵矛盾 .由于经典 逻辑在出现不一致的情况下就无法再进行推理,因此需求一致性检测工作到此即结束了.对所存在的不一致需 求的定位 诊断和处理都需要依靠人工完成. 2.1.2 基于带标记的准经典逻辑的方法 由于在存在矛盾的断言集中,经典逻辑会产生毫无意义的结论.因此,一旦检测到存在不一致的需求,不一 致性的处理工作就无法继续进行下去.而越来越多的实践表明,很多情况下要求(暂时)容忍不一致的需求描 述[5].为了能够暂时容忍不一致的需求描述,并跟踪不一致性产生的根源 ,文献[12]提出用带标记的准经典逻辑 (labeled quasi-classical logic)来进行需求不一致的检测. 就表示形式而言 ,准经典逻辑与经典逻辑的区别,在于准经典逻辑严格区分了正原子公式和负原子公式,从 而在推理过程中能够容忍经典逻辑意义下的矛盾 .带标记的准经典逻辑与准经典逻辑具有同样的表达能力 ,其 不同之处在于 ,带标记的准经典逻辑子句集中的每个子句前面都附带了一个标号的集合 ,即,若a为一个准经典 逻辑的子句,而x为一原子符号集合(例如字母表),如果 iÎx,则 i:a为一个带标记的准经典逻辑子句. 就推理能力而言,带标记的准经典逻辑与经典逻辑的主要区别在于: (1) 不利用封闭世界假设,只推断在原子公式集中直接包含的原子公式 ,并允许同一原子公式的正负形式 同时出现在一个模型中,阻止对形为aÙØa的公式进行推理,即禁止所有的平凡推理; (2) 扩展可满足性关系,分别定义强可满足性和弱可满足性,其中强可满足性阻止在析取推理中引入无意 义的原子公式; (3) 对每个子句附加标号的集合,同一标号集合下子句的归结保持标号集合不变 ,不同标号的子句归结,除 进行子句的归结以外尚需进行标号集合的合并. 以上 3 点措施使带标记的准经典逻辑不会产生无意义的结论,从而能够容忍经典逻辑意义下的矛盾 (由上 述(1)和(2)),同时,子句所带标号的集合记录了产生矛盾的根源(由(3)). 文献[12]进一步提出了对不一致的需求描述进行处理的方法 .当检测到存在不一致的需求描述时 ,可以进 行 3类不产生变化的行为: (1) 确定不一致的性质 :从全体需求描述出发,构造最大一致断言集的集合,根据每个断言和最大一致断言 集之间的关系,将断言划分为 3类,即存在推断 全称推断和自由推断*; (2) 识别不一致性的来源:由于需求描述采用带标记的逻辑公式 ,推理过程采用的也是带标记的准经典逻 辑推理规则,推理过程中的任何结论都存在标记的集合作为该结论的标记,标记的集合即记录了需求不一致性 的来源; (3) 定义一些元级规则来给出需求不一致性处理的建议 :如 ,不一致的需求出现在全称推断中必须要去除, 出现在存在推断中则必须谨慎处理. *由一个最大一致断言集推出的断言称为存在断言,由所有最大一致断言集推出的断言称为全称推断,由最大一致断言集的交集 推出的断言称为自由断言. 万方数据 朱雪峰 等:关于软件需求中的不一致性管理 1225 2.2 基于模型检验的方法 模型检验是一种验证有限状态并发系统的形式化方法[13],这种系统由一组系统状态变量来刻画,这组系统 状态变量的不同取值表示系统的一个可能的状态 .系统的需求则表示为随着系统的执行,系统的可能状态之间 的变迁关系. 形式化地说,一个状态变迁系统áQ,R,Iñ由一组状态 Q 状态变迁关系 RÍQ´Q 以及初始状态集 IÍQ 组成. 路径是状态的无限序列,使得每个相邻状态对都属于 R.状态集合 Q 一般由一组状态变量编码,使得 Q到变量值 的映射是一对一的.目前最为常见的模型检测工具是 SMV[14]和 SPIN[15]. 文献[16]是最早研究模型检验在检测需求规格说明中与应用相关的错误的工作,文献[17]则描述了一个形 式分析技术,称为一致性检查技术,使用模型检验技术自动检测需求描述中的错误 .文献[18]中给出了一个基于 模型检验技术的需求不一致性处理框架,如图 2 所示.采用模型检验进行需求不一致检测的主要特征是 :需要将 系统的需求表示为特定的面向状态的语言 ,然后用面向这种语言的状态计算工具来验证各种性质 .其优点是 ,具 有与基于定理证明一样的良定的检测过程和语义 ;缺点是 ,可能会由于状态空间的指数性增长而影响算法的效 率,同时只能检测出某些特定类型的不一致性. Specification (TCAS II SRS in RSML ) A model of the specification (Model of TCAS II SRS in the SMV language) Property (CTL formula) Internal representations of initial states and transition relation (BDDs) Internal representations of properties (BDDs) Model checking algorithm True or false with a counterexample Analyst’s feedback Model checker (SMV) Fig.2 Inconsistency handling framework of requirements based on model checking[18] 图 2 基于模型检验技术的需求不一致性处理框架[18] 2.2.1 SCR中的需求不一致性处理 这个方面的一个典型工作是 SCR(software cost reduction)方法[19],其主要思想是软件系统的四变量模型,即 软件系统的行为可以由 4 个变量(即监测变量 控制变量 输入数据和输出数据)之间的一组关系精确刻画,其 中监测变量和控制变量分别是影响系统行为的环境变量和系统所控制的环境变量.用两个关系集 REQ 和 NAT 描述环境,其中 NAT 包含关于监测变量和控制变量之间的约束 ;而 REQ 则定义要建立的系统的其他约束,即针 对监测变量和控制变量 ,系统所必须维护的关系.另外还有两个关系集 IN 和 OUT,用来描述环境与系统的交 互,IN是从监测变量到输入数据的映射,而 OUT是从输出数据到控制回来的变量的映射. 在上述思想的基础上,文献[17]建立了形式化需求模型,将软件系统定义为四元组áEm,S ,S0,Tñ ,其中 Em 为一 组输入事件,S为可能的系统状态集,S0为初始状态,T为形为 Em´S®S的部分函数,表示系统状态变迁. 在进行模型检验之前,首先需要将 SCR描述转换为相应的工具(如 SMV)所使用的语言,SMV计算出系统在 任何状态下其变量值的合法组合(状态不变性),以及在状态变迁后变量值的合法变化(变迁不变性).可以检测出 的需求不一致性包括:SCR描述的语法和类型正确性 SCR 描述的无循环和无不确定性等,这都可以通过定义 依赖于表示结构的过程来完成. 万方数据 1226 Journal of Software 软件学报 2005,16(7) 2.2.2 RSML中的需求不一致性处理 另一类使用模型检验技术进行需求不一致性检测的工作 ,则以 RSML[20](requirements state machine language)作为其需求描述语言.RSML 是一种基于状态图的状态机语言,这种语言是传统状态图的一个扩展,它 一方面建立了状态的层次,另一方面允许状态之间的广播式变迁. 文献[18]的工作就是使用RSML作为其需求描述语言的.它在进行模型检验之前同样需要将RSML的需求 描述成 SMV的表示.使用 SMV检测的特性包括: (1) 绝大多数 RSML规格说明中应该成立的特性:包括需求描述中是否出现不确定性变迁 功能定义是否 一致 状态机的终止性等; (2) 应用领域的特性 :如应用领域对某些状态变量的取值范围约束或者带条件的约束是否满足,多个与现 实相关的显示信息之间的对应性是否得到满足等. 2.3 基于目标的方法 与上述仅依赖需求表示形式的方法不同,KAOS 方法[21,22]的不一致需求管理策略依赖于其需求建模理念 “目标”的语义.KAOS 方法认为任何软件系统都是用来实现或达到一个或一组系统目标的,其需求抽取过程表 现为,首先确定一个目标,再通过目标的抽象 泛化和分解 求精,开发出一个目标的层次结构,然后以这个目标 的层次结构为基础,通过一个元模型,关联上需要获取的其他概念 ,如任务 Agent 资源对象等,以及这些概念间 的关联和约束.由于 KAOS方法的需求建模元语(即目标)具有自身的语义,因此,对矛盾的处理更具语义特征. 2.3.1 矛盾的分类[21,22] 首先,KAOS区分了需求不一致的 4种程度,其中包括: · 矛盾.在一个领域 Dom中,一组断言 A1,¼,An之间出现矛盾,当且仅当下列条件成立: (1) {Dom,Ù1£i£n Ai} ?False(逻辑不一致) (2) 对任意的 i:{Dom,Ùj¹i Aj} ?False(最小性) · 分歧.在一个领域 Dom中,一组断言 A1,¼,An之间出现分歧,当且仅当存在边界条件 B,使得: (1) {Dom,B,Ù1£i£n Ai} ?False(逻辑不一致) (2) 对任意的 i:{Dom,B,Ùj¹i Aj} ?False(最小性) (3) 存在一个场景 S和时间点 i使得:(S,i)╞B(可行性) · 竞争.竞争是单个目标中分歧的一种特殊情况,由下列条件来刻画: (1) 目标由形为("x:X)A[x]的断言表示 (2) {Dom,B,ÙiÎI A[xi]} ?False(对某个 I) (3) {Dom,B,ÙiÎJ A[xi]} ?False(对任意 JÌI) (4) 存在一个场景 S和时间点 i使得:(S,i)╞B · 障碍.障碍是在只涉及单个断言时分歧的一种边界情况: (1) {Dom,B,A} ?False (2) {Dom,B} ?False (3) 存在一个场景 S和时间点 i使得:(S,i)╞B 不难看出,在 KAOS 方法中,目标之间可能存在的不一致性是分歧.矛盾是分歧在 B=True 时的一种特殊情 况,而竞争和障碍则又是分歧的另外两种特殊情况,其中,障碍是在一般的分歧情况下取 n=1时的情况. 2.3.2 分歧检测技术 KAOS方法根据目标的语义定义了 4种目标模式,其中采用了一些时态算子*: Achieve: QP àÞ ; Cease: QP àØÞ ; Maintain: QP Þ W R ; Avoid: QP ØÞ W R . KAOS方法的目标分歧检测是找出使分歧出现的边界条件,有 3种分歧检测技术 :反向推理技术 基于分歧 *采用的时态算子包括:�(下一个状态) �(前一个状态 ) �(将来某个时刻) �(过去某个时刻 ) �(将来总是) �(过去总是 ) W(除非¼,则将来总是) U(直到¼,则将来总是)等. 万方数据 朱雪峰 等:关于软件需求中的不一致性管理 1227 模式的技术以及基于启发式规则的技术,其中前两种为形式化技术,而第 3种属于人工合作检测技术. · 反向推理技术:假设系统目标和领域描述均采用形为 AÞC的子句来表示,检测过程为 (1) 取 B:=ØAi; (2) 令 AÞC为所选择的规则,其中 C与 B中某个子公式 L相匹配; 则有m:=mgu(L,C)*,B:=B[L/A.m]; · 基于分歧模式的技术 (1) 定义目标模式,如前所示 4种模式; (2) 定义分歧模式,例如,Achieve-Avoid分歧模式:由{PÞàQ,RÞÿØS,QÞS}得到边界条件为à(PÙR); (3) 通过目标实例和分歧模式的匹配,得到分歧出现的边界条件. · 人工合作检测技术 :KAOS 方法还定义了目标的语义分类,包括 SatisfactionGoal,InformationGoal, SecurityGoal,SafetyGoal,AccuracyGoal等,同时提供了一组启发式规则来识别分歧,包括: (1) 若 SatisfactionGoal目标与 SafetyGoal目标涉及同一对象,则应考虑其间出现分歧的可能性. (2) 若 ConfidentialityGoal目标和 InformationGoal目标涉及同一对象,则应考虑其间出现分歧的可能性. (3) 若两个 OptimizeGoal目标干预了同一个对象的属性,则应考虑其关注事件之间出现分歧的可能性. (4) 若同一个 SatisfactionGoal目标有关于多个 Agent 的实例,则应考虑出现竞争分歧的可能性. 2.3.3 分歧处理方法 对于检测出来的分歧,KAOS方法提供相应的技术和启发式进行处理,主要策略包括: (1) 避免边界条件 :由于出现不一致的原因是边界条件的出现,因此最直接的策略是防止边界条件的出现, 可以通过引入一个新目标 ÞP ðØB即可达到此目的,其中 B为要阻止的边界条件. (2) 目标修补 :当边界条件无法避免时则引入一个新的目标,表示如果边界条件 B 出现的话,有分歧的目标 断言 Ai在某个合理的将来就为真,即 inid AB £££ ÙàÞ 1 . (3) 矛盾预测 :当发现存在一些持久条件 P,使得在某个上下文 C中 ,如果 P存留太久 ,则以后将会不可避免 地陷入矛盾,即 ÙC ð£dP d£àÛ Ø i ni A ££ Ù 1 ,则引入新目标避免预计的矛盾: PPC d ØàÞÙ £ . (4) 目标弱化:通过弱化出现分歧的目标形式以使分歧消失,可使用下列目标弱化模式: (i) 时态放松:如,弱化 Ad£à 为 Ac£à (其中 c>d) 弱化ð£d A为ð£c A(其中 c