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

需求工程金芝中国科学院数学与系统科学探讨院zhijin@amss.ac什么是视点？理解系统的需求，须要理解：系统供应的服务系统的应用领域系统将处于的环境影响系统的组织问题等等因此，需求工程过程涉及：捕获、分析和确定——各种看法什么是视点？视点：出自一个特定角度的，关于系统或相关问题、环境和应用领域的一组信息角度：系统的最终用户其它的系统涉及系统开发的工程师任何系统相关者什么是视点？假设：针对整个系统而言，每个视点都是不完整的整个系统的需求将通过集成各个视点信息得到由于一般而言视点之间会包含不同的需求，因此特殊地要涉及冲突的归结过程什么是视点？“火车自动限制系统”中的可能视点和需求来源：司机：来自火车司机的需求，可能大部分是涉及可用性的非功能性需求轨道设备：来自轨道设备的需求，这些轨道设备将与系统发生交互已有的其它系统：来自已经存在的其它系统的兼容性需求平安工程师：来自于铁路平安工程师的系统平安性需求火车制动装置的特征：从火车制动装置的特性中导出的需求什么是视点？视点：需求相关者对问题某个方面的观点，显式区分不同的需求来源视点是分别关注点的一种方法，让参与者仅仅关注他们感爱好的问题，忽视与他们无关的问题供应组织和结构化这些不同信息的机制供应手段，让需求源或需求相关者标识和检查他们对需求的贡献第十讲：面对视点的需求方法结构化分析和设计技术（SADT）限制需求表达（CORE）面对视点的系统工程（VOSE）面对视点的需求定义（VORD）面对视点的需求验证“问题”需求的处理框架从结构化分析和设计技术（SADT）中谈起SADT方法由长方形（表示活动）和不同含义的箭头组成将问题分解为层次图，每层含一组长方形和箭头低层的是高层的精化最上层的是上下文图，表示系统的输入／输出／限制／支撑机制SADT方法中的视点没有显式的视点定义，是其建模技术的直观推广由它的数据和来源和去向确定视点SADT方法中的视点视点Libraryuser表示检查和未检查的馆藏的来源和目的地视点Issueclerk表示检查这些馆藏并注明归还日期视点Itemdatabase表示关于馆藏的信息的来源和要修改的信息视点Userdatabase表示验证合法用户的信息来源SADT方法中的视点视点只是一种直觉,而没有明确的表示没有关凝视点定义的特地步骤视点只出现在上下文层没有超出只将视点作为数据的来源和出处的视点分析限制式需求表达（CORE）CORE方法概述英国宇航局，七十年头末期关注功能分解（与SADT相同），但不同的是，它显式地以视点为基础用于欧洲宇航工业界，著名的项目包括：八十年头中旬的试验飞行器支配，CORE用于系统和软件定义最近的欧洲战斗机支配，CORE作为标准的需求分析方法CORE方法中的视点分两层考虑视点第一层次：识别与目标系统交互的或者影响目标系统的实体CORE供应识别功能性和非功能性视点的指南其次层次：区分定义视点和边界视点定义视点：系统的子过程，接受自顶向下的方式限界视点：间接地与目标系统发生交互的实体CORE方法的步骤迭代式过程视点识别视点结构化表表示的采集数据结构化单视点建模组合视点建模约束分析举例（图书馆管理）第一步：识别视点（头脑风暴，识别可能实体）举例（图书馆管理）第一步：识别视点（区分定义视点和限界视点）举例（图书馆管理）其次步：视点结构化功能子系统层次结构，自顶向下分解限界视点在相同的层次上举例（图书馆管理）第三步：表表示法采集视点信息的一种机制包括：执行的行为、这些行为要运用的数据、导出的输出数据、数据的来源、数据的目的地主要侧重在信息流建模，便于视点间数据流冲突的检测，包括数据来源和目的地的一样性等举例（图书馆管理）SourceInputActionOutputDestinationLibraryuserRequesteditemCheckitemIssueditemLibraryuserErrormessageIssueclerkLibraryuserLibrarycardValidateuserLoandefaultmessageIssueclerkCORE方法的其余步骤第四步，数据结构化：将数据项分解为其组成部分，创建数据字典第五步和第六步，单视点建模和多视点组合建模：接受活动图为视点活动建模，类似于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.`On’Transition(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）扩展可满足性关系：强可满足+弱可满足