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

1、12 理解系统的需求，需要理解： 系统提供的服务 系统的应用领域 系统将处于的环境 影响系统的组织问题 等等 因此，需求工程过程涉及： 捕获、分析和决定各种意见3 视点： 出自一个特定角度的，关于系统或相关问题、环境和应用领域的一组信息 角度： 系统的最终用户 其它的系统 涉及系统开发的工程师 任何系统相关者4 假设： 针对整个系统而言，每个视点都是不完整的 整个系统的需求将通过集成各个视点信息得到 由于一般而言视点之间会包含不同的需求，因此特别地要涉及矛盾的归结过程5 “火车自动控制系统”中的可能视点和需求来源： 司机：来自火车司机的需求，可能大部分是涉及可用性的非功能性需求 轨道设备：来自

2、轨道设备的需求，这些轨道设备将与系统发生交互 已有的其它系统：来自已经存在的其它系统的兼容性需求 安全工程师：来自于铁路安全工程师的系统安全性需求 火车制动装置的特征：从火车制动装置的特性中导出的需求6：，显式区别不同的需求来源 视点是分离关注点的一种方法，让参与者仅仅关注他们感兴趣的问题，忽略与他们无关的问题 提供组织和结构化这些不同信息的机制 提供手段，让需求源或需求相关者标识和检查他们对需求的贡献7结构化分析和设计技术（SADT）控制需求表达（CORE）面向视点的系统工程（VOSE）面向视点的需求定义（VORD）面向视点的需求验证“问题”需求的处理框架8910 没有显式的视点定义，是其建

3、模技术的直观推广 由它的数据和来源和去向决定视点1112 视点只是一种直觉,而没有明确的表示 没有关注视点定义的专门步骤 视点只出现在上下文层 没有超出只将视点作为数据的来源和出处的视点分析1314 英国宇航局，七十年代末期 关注功能分解（与SADT相同），但不同的是，它显式地以视点为基础 用于欧洲宇航工业界，著名的项目包括： 八十年代中旬的实验飞行器计划，CORE用于系统和软件定义 最近的欧洲战斗机计划，CORE作为标准的需求分析方法15 分两层考虑视点 第一层次：识别与目标系统交互的或者影响目标系统的实体 CORE提供识别功能性和非功能性视点的指南 第二层次：区别定义视点和边界视点 定义视

4、点：系统的子过程，采用自顶向下的方式 限界视点：间接地与目标系统发生交互的实体16 迭代式过程 视点识别 视点结构化 表表示的采集 数据结构化 单视点建模 组合视点建模 约束分析17 第一步：识别视点（头脑风暴，识别可能实体）18 第一步：识别视点（区分定义视点和限界视点）19 第二步：视点结构化 功能子系统层次结构，自顶向下分解 限界视点在相同的层次上20 第三步：表表示法 采集视点信息的一种机制 包括：执行的行为、这些行为要使用的数据、导出的输出数据、数据的来源、数据的目的地 主要侧重在信息流建模，便于视点间数据流冲突的检测，包括数据来源和目的地的一致性等2122 第四步，数据结构化：将数

5、据项分解为其组成部分，创建数据字典 第五步和第六步，单视点建模和多视点组合建模：采用活动图为视点活动建模，类似于SADT，说明活动的过程，以及关联到的表集 第七步，约束分析：将系统看作一个整体进行分析23 任何实体都可以是视点，对什么是视点缺少明确的界定 定义视点和限界视点使视点的识别更加复杂 限界视点是将与目标系统发生信息交互的外部实体 定义视点是目标系统的子过程 分析比较薄弱，仅关注于内部视点（定义视点），对限界视点不进行分析，它们只是作为与系统交互的数据来源和目的地2425 九十年代早期，Imperial College London 基本原理： 软件开发涉及许多专家的参与 这些专家关注

6、于软件开发和应用领域的不同方面 每个专家都只负责或关注他所关心的方面26 使用视点来捕获上述不同的方面，划分和分布参与者的活动和知识 捕获参与者在软件开发特定阶段的角色和职责 通过参与者的角色来识别视点 不同角色的知识封装在一个视点内，VOSE提供了视点的表示风格27 松耦合、局部管理、分布的对象，它封装了关于系统及其领域的：部分表示知识开发过程知识规格说明知识28描述该视点使用的表示格式描述该视点的开发行为，过程和策略标识相对于要开发的整个系统而言该视点的关注点按style槽规定的，采用work plan槽中描述的策略开发的表示法描述视点维护视点规格说明的开发状态，通过它可以实现需求的可追踪

7、性，记录一些形式的开发理念。29 一个视点框架就是一个视点类型，它只包含 风格（style）槽 工作计划（work plan）槽 按照工作计划槽中定义的行为开发视点，得到视点类型的一个实例30 视点的表示 视点内部的交互 视点之间的交互 冲突消解31 视点框架是可重用的描述，可以多次实例化，得到多个视点 框架的一次实例化过程就是一个视点的开发过程 框架不仅刻画视点要表示的需求,还表达了视点的开发方法和开发过程 视点拥有者：负责制定该视点的过程模型的人或者智能工具32 两部分： Object ：Object.Attribute Relation： Relation(Object1,Object2

8、).Attribute Relation(Object1,Object2).Object1.Attribute 例子 Process.Name State.Name.On Transition(On, Off).Name.Button-press33 组装活动 视点内检查 视点间检查 视点触发活动34 用来采集（构造）该表示框架的规格说明的基本活动 实际上是一组基本的编辑活动35 检查视点规格说明语法上的局部一致性 这些检查规则实际上部分定义了视点表示的语义 是方法设计者确定良定规格说明的依据36 检查不同视点规格说明间的一致性 视点间一致性规则规定在什么情况下出现不一致37 为了创建新视点(

9、实例化视点框架)而必须执行的活动 一般作为一个其它开发活动的结果，比如： 在agent层次中增加一个agent触发为这个agent创建一个新的视点 在功能分解层次中增加一个子过程，触发创建一个表集视点3839 Agent结构视点 表集视点404142434445 识别信息处理实体，作为Agent，用Agent层次结构将它们组合起来4647 针对每个叶子agent，构造刻画信息处理过程的表结构4849 检查源和目的地的存在性，针对agent的层次结构而言 如果出错，隐含： 增加新agent 重命名不一致的源和目的地5051 表集合图中的每个源必须是agent层次中的一个命名agentSource

10、.Name=VP(AS,Dd):Agent.Name 表集合图中的每个目的地必须是agent层次中的一个命名agentDestination.Name= VP(AS,Dd):Agent.Name52 来自表集合图的每个输出必须是另一个agent的表集合图的一个输入Connected-to(Output, Destination).Output.Name=VP(TC,Destination.Name): Connected-to(Ds,Input).Input.Name 来自表集合图中一个源的每个输入必须由该源agent的表集合图产生Connected-to(Source, Input).Inp

11、ut.Name=VP(TC,Source.Name): Connected-to(Output, Ds).Output.Name5354 Agent层次上的每个agent必须有一个表集合图与它关联（蕴涵每个agent都是一个信息处理实体） AgentVP(TC,Agent.Name) 总之，视点间关系定义视点之间的结构约束55 在创建包含该规则的视点类的实例（源视点）时，声明： 至少要有一个目的视点，使得它将与源视点维护这个关系 可以触发目的视点的创建VPsVPd such that VPs VPd5657 检查模式：？ 失败导致不一致性处理 变换模式：f(, VPs, VPd) 将一个视点中

12、的对象或关系一对一映射到另一个视点的对应对象或关系上（满足关系 ）58596061(a) Template in CORE(b) Hierarchy of Agents(c) Action table of Agent Borrower(d) Action table of Agent Clerk(e) Action table of Agent Librarian62利用封闭世界假设，可以推出矛盾：63 基本观点： 在处理概念建模问题时，建立多个代表不同视角的片段模型，比试图构造单个模型要好 分离地为不同涉众建模，然后再组合起来，会导致对领域的更丰富的理解64 得到涉众的认可：分离地获取不同

13、涉众的视点，他们可以看到自己的贡献 结构化过程：需求制品的并行开发，不受一致性的局限，建模过程可以分派给不同的开发小组 延迟承诺：容许问题的不同表示，对哪些需求更重要的问题，他们应该如何建模等，分析员可以推迟做出选择，直到对涉众的视角有更好的理解65 视点建模改进可追踪性：因为比较和合并是显式地进行的，过程可以记录下来 视点建模改进结果模型的可读性：原始涉众对模型的理解能力 视点建模改进捕获不同观点和微弱观点的能力：没有视点，有些不符合特定建模原则的事实会被忽略 视点建模使小组的建模更容易，因为分解了建模任务66 如何识别视点之间的关系？ 如何发现和处理不一致性？67 多伦多大学 问题：Kid

14、s Help Phone 基本表示框架：I*68全局建模组开发包含所有事务的单个I*模型 视点开发组为每个被面谈的涉众开发个体模型，然后合并它们获得整个模型，合并过程由整个开发组共同完成 69 输入：14个事务 概念获取：约950个意图元素，约120个潜在的Actors和Roles SR模型：9个分离的SR模型 结果检查：交叉检查、裁剪过合并元素 推断9个SR模型之间的策略依赖关系，得出一个完整的组织SD模型70 视点划分：14个事务分成3组 分别开发： 每个模型仅包含本组事务中的信息，排除其它事务的信息 模型采用与涉众相同的词汇 视点合并 选择一个看起来被所有视点共享的元素作为开始点 构造一

15、个合并模型，使它包含能与所有视点匹配的元素和只出现在一个视点中出现的元素 如果元素表示的详细程度不同，则使用最详细的版本 如果同一个术语被用来表示不同的概念，改变其中的一个术语，使能够区别这个不同 如果同一个概念在不同的视点中采用了不同方式来表示，就比较麻烦，常常需要开发一个新的结构71 两个组都觉得从文本中抽取模型元素比较困难 对更大的模型，唯一实际的方法是将它划分成许多分离的视图（注意不是视点）72 模型规模是全局开发组的难题 从事务中抽取的意图元素太多不好管理，也无法检查相似项 难以决定如何将一个大的模型划分为小的视图 不得不将大的actor分割成小的roles，否则依赖关系太多 模型太

16、大导致图形布局问题，可读性受到影响，检查和验证几乎不可能 视点开发组可以克服这些问题7374 后向可追踪性 视点开发组比较容易做到 全局开发组比较难，在整个开发过程，他们只查阅了原始事务描述5次 它们的模型离原始事务比较远， 在建模过程中引入了许多原始事务中没有的概念， 意图元素的列表是原始事务和模型之间的中间表示 意图元素的列表对选择建模问题的初始分解起到重要作用75 视点合并是视点开发组的主要难题，这个组不得不针对所有不同点提出解决方案，经常要回到原始事务描述中，识别某个概念的真正含义，需要所有的建模人员参加 不同详细程度 不同建模风格 不同形式化程度 建模过于自由 不同术语76 模型分析

17、，不同小组开发的模型，采用不同的模型分析技术： 全局开发组的模型用目标评估过程 视点开发组的模型让涉众检查分析，理解涉众之间观点的不同7778798081828384 无合取：A和B不能推出AB 无真值关系：A的真值与A的真值无关 多值系统：3值或4值逻辑 相干逻辑：使用不同的蕴涵操作子 弱化证明：限制证明的形式（如QC-LOGIC）85 不利用封闭世界假设86 扩展可满足性关系：强可满足+弱可满足878889 带注释的谓词演算（Annotated Predicate Calculus，APC） 每一个经典的原子公式（e.g. l）都伴随有一个来自于信任半格（belief semilattice，BSL）的值（e.g. r）作为注释。 例： Reserve(User, Book): tBorrow(User, Book): tp 90 非规范软件需求统一管理框架需求规格说明应用场景输入I,期望响应E自然语言描