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

需求工程金芝中国科学院数学与系统科学研究院[e-mail]什么是视点？•理解系统的需求，需要理解：–系统提供的服务–系统的应用领域–系统将处于的环境–影响系统的组织问题–等等•因此，需求工程过程涉及：–捕获、分析和决定——各种意见什么是视点？•视点：–出自一个特定角度的，关于系统或相关问题、环境和应用领域的一组信息–角度：•系统的最终用户•其它的系统•涉及系统开发的工程师•任何系统相关者什么是视点？•假设：–针对整个系统而言，每个视点都是不完整的–整个系统的需求将通过集成各个视点信息得到–由于一般而言视点之间会包含不同的需求，因此特别地要涉及矛盾的归结过程什么是视点？•“火车自动控制系统”中的可能视点和需求来源：–司机：来自火车司机的需求，可能大部分是涉及可用性的非功能性需求–轨道设备：来自轨道设备的需求，这些轨道设备将与系统发生交互–已有的其它系统：来自已经存在的其它系统的兼容性需求–安全工程师：来自于铁路安全工程师的系统安全性需求–火车制动装置的特征：从火车制动装置的特性中导出的需求什么是视点？•视点：需求相关者对问题某个方面的观点，显式区别不同的需求来源•视点是分离关注点的一种方法，让参与者仅仅关注他们感兴趣的问题，忽略与他们无关的问题•提供组织和结构化这些不同信息的机制•提供手段，让需求源或需求相关者标识和检查他们对需求的贡献第十讲：面向视点的需求方法•结构化分析和设计技术（SADT）•控制需求表达（CORE）•面向视点的系统工程（VOSE）•面向视点的需求定义（VORD）•面向视点的需求验证•“问题”需求的处理框架从结构化分析和设计技术（SADT）中谈起SADT方法ActivityInputControlOutputMechanism•由长方形（表示活动）和不同含义的箭头组成•将问题分解为层次图，每层含一组长方形和箭头•低层的是高层的精化•最上层的是上下文图，表示系统的输入／输出／控制／支撑机制SADT方法中的视点•没有显式的视点定义，是其建模技术的直观推广•由它的数据和来源和去向决定视点SADT方法中的视点IssuelibraryItem(01)LibrarycardValidmemberIssueditemReturndateRequesteditem[Libraryuser][Libraryuser][Issueclerk][Libraryuser]ItemavailabilityUserdatabaseItemdatabase•视点Libraryuser表示检查和未检查的馆藏的来源和目的地•视点Issueclerk表示检查这些馆藏并注明归还日期•视点Itemdatabase表示关于馆藏的信息的来源和要修改的信息•视点Userdatabase表示验证合法用户的信息来源SADT方法中的视点•视点只是一种直觉,而没有明确的表示•没有关注视点定义的专门步骤•视点只出现在上下文层•没有超出只将视点作为数据的来源和出处的视点分析控制式需求表达（CORE）CORE方法概述•英国宇航局，七十年代末期•关注功能分解（与SADT相同），但不同的是，它显式地以视点为基础•用于欧洲宇航工业界，著名的项目包括：–八十年代中旬的实验飞行器计划，CORE用于系统和软件定义–最近的欧洲战斗机计划，CORE作为标准的需求分析方法CORE方法中的视点•分两层考虑视点–第一层次：识别与目标系统交互的或者影响目标系统的实体–CORE提供识别功能性和非功能性视点的指南–第二层次：区别定义视点和边界视点–定义视点：系统的子过程，采用自顶向下的方式–限界视点：间接地与目标系统发生交互的实体CORE方法的步骤•迭代式过程–视点识别–视点结构化–表表示的采集–数据结构化–单视点建模–组合视点建模–约束分析举例（图书馆管理）•第一步：识别视点（头脑风暴，识别可能实体）LibraryuserCatalogueOrderitemVideoIssueitemLibrarycardReturnitemValidateuserUserdatabaseBookIssueclerkBooksupplierItemdatabaseRegisteruserUpdateitemdatabase举例（图书馆管理）•第一步：识别视点（区分定义视点和限界视点）LibraryuserCatalogueOrderitemIssueitemReturnitemValidateuserUserdatabaseIssueclerkBooksupplierItemdatabaseRegisteruserUpdateitemdatabase限界视点定义视点举例（图书馆管理）•第二步：视点结构化–功能子系统层次结构，自顶向下分解–限界视点在相同的层次上LibraryworldLibraryworldLibraryworldLibraryworldLibraryworldLibraryworldOrderUpdateIssueRegister举例（图书馆管理）•第三步：表表示法–采集视点信息的一种机制–包括：执行的行为、这些行为要使用的数据、导出的输出数据、数据的来源、数据的目的地–主要侧重在信息流建模，便于视点间数据流冲突的检测，包括数据来源和目的地的一致性等举例（图书馆管理）SourceInputActionOutputDestinationLibraryuserRequesteditemCheckitemIssueditemLibraryuserErrormessageIssueclerkLibraryuserLibrarycardValidateuserLoandefaultmessageIssueclerkCORE方法的其余步骤•第四步，数据结构化：将数据项分解为其组成部分，创建数据字典•第五步和第六步，单视点建模和多视点组合建模：采用活动图为视点活动建模，类似于SADT，说明活动的过程，以及关联到的表集•第七步，约束分析：将系统看作一个整体进行分析CORE方法的问题讨论•任何实体都可以是视点，对什么是视点缺少明确的界定•定义视点和限界视点使视点的识别更加复杂–限界视点是将与目标系统发生信息交互的外部实体–定义视点是目标系统的子过程•分析比较薄弱，仅关注于内部视点（定义视点），对限界视点不进行分析，它们只是作为与系统交互的数据来源和目的地面向视点的系统工程（VOSE）VOSE概述•九十年代早期，ImperialCollegeLondon•基本原理：–软件开发涉及许多专家的参与–这些专家关注于软件开发和应用领域的不同方面–每个专家都只负责或关注他所关心的方面VOSE视点•使用视点来捕获上述不同的方面，划分和分布参与者的活动和知识•捕获参与者在软件开发特定阶段的角色和职责•通过参与者的角色来识别视点•不同角色的知识封装在一个视点内，VOSE提供了视点的表示风格什么是视点?•松耦合、局部管理、分布的对象，它封装了关于系统及其领域的：–部分表示知识–开发过程知识–规格说明知识标准视点框架描述该视点使用的表示格式描述该视点的开发行为，过程和策略标识相对于要开发的整个系统而言该视点的关注点按style槽规定的，采用workplan槽中描述的策略开发的表示法描述视点维护视点规格说明的开发状态，通过它可以实现需求的可追踪性，记录一些形式的开发理念。视点类型•一个视点框架就是一个视点类型，它只包含–风格（style）槽–工作计划（workplan）槽•按照工作计划槽中定义的行为开发视点，得到视点类型的一个实例主要研究的问题•视点的表示•视点内部的交互•视点之间的交互•冲突消解视点框架•视点框架是可重用的描述，可以多次实例化，得到多个视点•框架的一次实例化过程就是一个视点的开发过程•框架不仅刻画视点要表示的需求,还表达了视点的开发方法和开发过程•视点拥有者：负责制定该视点的过程模型的人或者智能工具Style槽•两部分：–Object：Object.Attribute–Relation：•Relation(Object1,Object2).Attribute•Relation(Object1,Object2).Object1.Attribute•例子–Process.Name–State.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都是一个信息处理实体）AgentVP(TC,Agent.Name)•总之，视点间关系定义视点之间的结构约束视点间规则的援引•在创建包含该规则的视点类的实例（源视点）时，声明：–至少要有一个目的视点，使得它将与源视点维护这个关系–可以触发目的视点的创建VPsVPdsuchthatVPsVPd视点集成（援引）视点间规则的应用•检查模式：？–失败导致不一致性处理•变换模式：f(,VPs,VPd)–将一个视点中的对象或关系一对一映射到另一个视点的对应对象或关系上（满足关系）视点集成（应用）视点集成视点间不一致性的处理视点间不一致性的处理(a)TemplateinCORE(b)HierarchyofAgents(c)ActiontableofAgentBorrower(d)ActiontableofAgentClerk(e)ActiontableofAgentLibrarian视点间不一致性的处理利用封闭世界假设，可以推出矛盾：讨论•基本观点：–在处理概念建模问题时，建立多个代表不同视角的片段模型，比试图构造单个模型要好–分离地为不同涉众建模，然后再组合起来，会导致对领域的更丰富的理解视点方法的好处•得到涉众的认可：分离