中科院需求工程8D讲)多视点需求工程与矛盾需求处理.ppt

需求工程,金芝中国科学院数学与系统科学研究院zhijin,什么是视点？,理解系统的需求，需要理解：系统提供的服务系统的应用领域系统将处于的环境影响系统的组织问题等等因此，需求工程过程涉及：捕获、分析和决定各种意见,什么是视点？,视点：出自一个特定角度的，关于系统或相关问题、环境和应用领域的一组信息角度：系统的最终用户其它的系统涉及系统开发的工程师任何系统相关者,什么是视点？,假设：针对整个系统而言，每个视点都是不完整的整个系统的需求将通过集成各个视点信息得到由于一般而言视点之间会包含不同的需求，因此特别地要涉及矛盾的归结过程,什么是视点？,“火车自动控制系统”中的可能视点和需求来源：司机：来自火车司机的需求，可能大部分是涉及可用性的非功能性需求轨道设备：来自轨道设备的需求，这些轨道设备将与系统发生交互已有的其它系统：来自已经存在的其它系统的兼容性需求安全工程师：来自于铁路安全工程师的系统安全性需求火车制动装置的特征：从火车制动装置的特性中导出的需求,什么是视点？,视点：需求相关者对问题某个方面的观点，显式区别不同的需求来源视点是分离关注点的一种方法，让参与者仅仅关注他们感兴趣的问题，忽略与他们无关的问题提供组织和结构化这些不同信息的机制提供手段，让需求源或需求相关者标识和检查他们对需求的贡献,第十讲：面向视点的需求方法,结构化分析和设计技术（SADT）控制需求表达（CORE）面向视点的系统工程（VOSE）面向视点的需求定义（VORD）面向视点的需求验证“问题”需求的处理框架,从结构化分析和设计技术（SADT）中谈起,SADT方法,由长方形（表示活动）和不同含义的箭头组成将问题分解为层次图，每层含一组长方形和箭头低层的是高层的精化最上层的是上下文图，表示系统的输入输出控制支撑机制,SADT方法中的视点,没有显式的视点定义，是其建模技术的直观推广由它的数据和来源和去向决定视点,SADT方法中的视点,视点Libraryuser表示检查和未检查的馆藏的来源和目的地,视点Issueclerk表示检查这些馆藏并注明归还日期,视点Itemdatabase表示关于馆藏的信息的来源和要修改的信息,视点Userdatabase表示验证合法用户的信息来源,SADT方法中的视点,视点只是一种直觉,而没有明确的表示没有关注视点定义的专门步骤视点只出现在上下文层没有超出只将视点作为数据的来源和出处的视点分析,控制式需求表达（CORE）,CORE方法概述,英国宇航局，七十年代末期关注功能分解（与SADT相同），但不同的是，它显式地以视点为基础用于欧洲宇航工业界，著名的项目包括：八十年代中旬的实验飞行器计划，CORE用于系统和软件定义最近的欧洲战斗机计划，CORE作为标准的需求分析方法,CORE方法中的视点,分两层考虑视点第一层次：识别与目标系统交互的或者影响目标系统的实体CORE提供识别功能性和非功能性视点的指南第二层次：区别定义视点和边界视点定义视点：系统的子过程，采用自顶向下的方式限界视点：间接地与目标系统发生交互的实体,CORE方法的步骤,迭代式过程视点识别视点结构化表表示的采集数据结构化单视点建模组合视点建模约束分析,举例（图书馆管理）,第一步：识别视点（头脑风暴，识别可能实体）,举例（图书馆管理）,第一步：识别视点（区分定义视点和限界视点）,举例（图书馆管理）,第二步：视点结构化功能子系统层次结构，自顶向下分解限界视点在相同的层次上,举例（图书馆管理）,第三步：表表示法采集视点信息的一种机制包括：执行的行为、这些行为要使用的数据、导出的输出数据、数据的来源、数据的目的地主要侧重在信息流建模，便于视点间数据流冲突的检测，包括数据来源和目的地的一致性等,举例（图书馆管理）,CORE方法的其余步骤,第四步，数据结构化：将数据项分解为其组成部分，创建数据字典第五步和第六步，单视点建模和多视点组合建模：采用活动图为视点活动建模，类似于SADT，说明活动的过程，以及关联到的表集第七步，约束分析：将系统看作一个整体进行分析,CORE方法的问题讨论,任何实体都可以是视点，对什么是视点缺少明确的界定定义视点和限界视点使视点的识别更加复杂限界视点是将与目标系统发生信息交互的外部实体定义视点是目标系统的子过程分析比较薄弱，仅关注于内部视点（定义视点），对限界视点不进行分析，它们只是作为与系统交互的数据来源和目的地,面向视点的系统工程（VOSE）,VOSE概述,九十年代早期，ImperialCollegeLondon基本原理：软件开发涉及许多专家的参与这些专家关注于软件开发和应用领域的不同方面每个专家都只负责或关注他所关心的方面,VOSE视点,使用视点来捕获上述不同的方面，划分和分布参与者的活动和知识捕获参与者在软件开发特定阶段的角色和职责通过参与者的角色来识别视点不同角色的知识封装在一个视点内，VOSE提供了视点的表示风格,什么是视点?,松耦合、局部管理、分布的对象，它封装了关于系统及其领域的：部分表示知识开发过程知识规格说明知识,标准视点框架,描述该视点使用的表示格式,描述该视点的开发行为，过程和策略,标识相对于要开发的整个系统而言该视点的关注点,按style槽规定的，采用workplan槽中描述的策略开发的表示法描述视点,维护视点规格说明的开发状态，通过它可以实现需求的可追踪性，记录一些形式的开发理念。,视点类型,一个视点框架就是一个视点类型，它只包含风格（style）槽工作计划（workplan）槽按照工作计划槽中定义的行为开发视点，得到视点类型的一个实例,主要研究的问题,视点的表示视点内部的交互视点之间的交互冲突消解,视点框架,视点框架是可重用的描述，可以多次实例化，得到多个视点框架的一次实例化过程就是一个视点的开发过程框架不仅刻画视点要表示的需求,还表达了视点的开发方法和开发过程视点拥有者：负责制定该视点的过程模型的人或者智能工具,Style槽,两部分：Object：Object.AttributeRelation：Relation(Object1,Object2).AttributeRelation(Object1,Object2).Object1.Attribute例子Process.NameState.Name.OnTransition(On,Off).Name.Button-press,WorkPlan槽,组装活动视点内检查视点间检查视点触发活动,组装活动,用来采集（构造）该表示框架的规格说明的基本活动实际上是一组基本的编辑活动,视点内检查,检查视点规格说明语法上的局部一致性这些检查规则实际上部分定义了视点表示的语义是方法设计者确定良定规格说明的依据,视点间检查,检查不同视点规格说明间的一致性视点间一致性规则规定在什么情况下出现不一致,视点触发活动,为了创建新视点(实例化视点框架)而必须执行的活动一般作为一个其它开发活动的结果，比如：在agent层次中增加一个agent触发为这个agent创建一个新的视点在功能分解层次中增加一个子过程，触发创建一个表集视点,过程模型,两类视点框架,Agent结构视点表集视点,Agent结构视点,表集视点（一）,表集视点（二）,视点间的关系（一）,视点间的关系（二）,案例（图书馆）,识别信息处理实体，作为Agent，用Agent层次结构将它们组合起来,LibraryWorld视点,案例（图书馆）,针对每个叶子agent，构造刻画信息处理过程的表结构,Borrower视点,其它视点内活动,检查源和目的地的存在性，针对agent的层次结构而言如果出错，隐含：增加新agent重命名不一致的源和目的地,视点集成,视点间关系定义（举例）,表集合图中的每个源必须是agent层次中的一个命名agentSource.Name=VP(AS,Dd):Agent.Name表集合图中的每个目的地必须是agent层次中的一个命名agentDestination.Name=VP(AS,Dd):Agent.Name,视点间关系定义（举例）,来自表集合图的每个输出必须是另一个agent的表集合图的一个输入Connected-to(Output,Destination).Output.Name=VP(TC,Destination.Name):Connected-to(Ds,Input).Input.Name来自表集合图中一个源的每个输入必须由该源agent的表集合图产生Connected-to(Source,Input).Input.Name=VP(TC,Source.Name):Connected-to(Output,Ds).Output.Name,两个视点表集合图间关系,视点间关系定义（举例）,Agent层次上的每个agent必须有一个表集合图与它关联（蕴涵每个agent都是一个信息处理实体）AgentVP(TC,Agent.Name)总之，视点间关系定义视点之间的结构约束,视点间规则的援引,在创建包含该规则的视点类的实例（源视点）时，声明：至少要有一个目的视点，使得它将与源视点维护这个关系可以触发目的视点的创建VPsVPdsuchthatVPsVPd,视点集成（援引）,视点间规则的应用,检查模式：？失败导致不一致性处理变换模式：f(,VPs,VPd)将一个视点中的对象或关系一对一映射到另一个视点的对应对象或关系上（满足关系）,视点集成（应用）,视点集成,视点间不一致性的处理,视点间不一致性的处理,视点间不一致性的处理,利用封闭世界假设，可以推出矛盾：,讨论,基本观点：在处理概念建模问题时，建立多个代表不同视角的片段模型，比试图构造单个模型要好分离地为不同涉众建模，然后再组合起来，会导致对领域的更丰富的理解,视点方法的好处,得到涉众的认可：分离地获取不同涉众的视点，他们可以看到自己的贡献结构化过程：需求制品的并行开发，不受一致性的局限，建模过程可以分派给不同的开发小组延迟承诺：容许问题的不同表示，对哪些需求更重要的问题，他们应该如何建模等，分析员可以推迟做出选择，直到对涉众的视角有更好的理解,其它可能的好处,视点建模改进可追踪性：因为比较和合并是显式地进行的，过程可以记录下来视点建模改进结果模型的可读性：原始涉众对模型的理解能力视点建模改进捕获不同观点和微弱观点的能力：没有视点，有些不符合特定建模原则的事实会被忽略视点建模使小组的建模更容易，因为分解了建模任务,带来的新问题,如何识别视点之间的关系？如何发现和处理不一致性？,通过实验评估这个方法,多伦多大学问题：KidsHelpPhone基本表示框架：I*,实验设计,全局建模组开发包含所有事务的单个I*模型,视点开发组为每个被面谈的涉众开发个体模型，然后合并它们获得整个模型，合并过程由整个开发组共同完成,全局开发组的活动,输入：14个事务概念获取：约950个意图元素，约120个潜在的Actors和RolesSR模型：9个分离的SR模型结果检查：交叉检查、裁剪过合并元素推断9个SR模型之间的策略依赖关系，得出一个完整的组织SD模型,视点开发组的活动,视点划分：14个事务分成3组分别开发：每个模型仅包含本组事务中的信息，排除其它事务的信息模型采用与涉众相同的词汇视点合并选择一个看起来被所有视点共享的元素作为开始点构造一个合并模型，使它包含能与所有视点匹配的元素和只出现在一个视点中出现的元素如果元素表示的详细程度不同，则使用最详细的版本如果同一个术语被用来表示不同的概念，改变其中的一个术语，使能够区别这个不同如果同一个概念在不同的视点中采用了不同方式来表示，就比较麻烦，常常需要开发一个新的结构,一般的结论,两个组都觉得从文本中抽取模型元素比较困难对更大的模型，唯一实际的方法是将它划分成许多分离的视图（注意不是视点）,比较,模型规模是全局开发组的难题从事务中抽取的意图元素太多不好管理，也无法检查相似项难以决定如何将一个大的模型划分为小的视图不得不将大的actor分割成小的roles，否则依赖关系太多模型太大导致图形布局问题，可读性受到影响，检查和验证几乎不可能视点开发组可以克服这些问题,模型的规模,比较,后向可追踪性视点开发组比较容易做到全局开发组比较难，在整个开发过程，他们只查阅了原始事务描述5次它们的模型离原始事务比较远，在建模过程中引入了许多原始事务中没有的概念，意图元素的列表是原始事务和模型之间的中间表示意图元素的列表对选择建模问题的初始分解起到重要作用,比较,视点合并是视点开发组的主要难题，这个组不得不针对所有不同点提出解决方案，经常要回到原始事务描述中，识别某个概念的真正含义，需要所有的建模人员参加不同详细程度不同建模风格不同形式化程度建模过于自由不同术语,比较,模型分析，不同小组开发的模型，采用不同的模型分析技术：全局开发组的模型用目标评估过程视点开发组的模型让涉众检查分析，理解涉众之间观点的不同,“问题”需求的处理框架,软件需求抽取和表达中的困难,相关工作,不一致需求的管理框架,好的需求规格说明,适合需求推理的逻辑工具,超协调逻辑,无合取：A和B不能推出AB无真值关系：A的真值与A的真值无关多值系统：3值或4值逻辑相干逻辑：使用不同的蕴涵操作子弱化证明：限制证明的形式（如QC-LOGIC）,定理证明技术（QC-logic）,不利用封闭世界假设,定理证明技术（QC-logic）,扩展可满足性关系：强可满足+弱可满足,定理证明技术（QC-logic）,“问题”需求的种类,一个合适的逻辑工具,带注释的谓词演算（AnnotatedPredicateCalculus，APC）每一个经典的原子公式（e.g.l）都伴随有一个来自于信任半格（beliefsemilattice，BSL）的值（e.g.r）作为注释。例：Reserve(User,Book)