第12章 面向多视点的需求工程

1第12章面向多视点的需求工程

2023/2/42第12章面向多视点的需求工程

对于大型、复杂软件系统的开发，不可避免地涉及到众多项目相关人员，由于各自背景、知识和职责等的不同，不同项目相关人员对目标软件系统可能具有不同的看法和要求。

20世纪90年代，A.Finkelstein和I.Sommerville等人正式提出了面向多视点的需求工程，采用视点的方式获取和组织不同用户的需求，并根据视点间的关系分析和处理需求的一致性问题，以确保用户需求的完整性和一致性。2023/2/43第12章面向多视点的需求工程12.1什么是视点12.2多视点与需求工程12.3多视点需求工程的过程模型12.4实例说明2023/2/4412.1什么是视点各种不同角度的视点定义视点是信息处理的实体，同时这一实体可能是另一视点的信息来源或信息流向。视点是服务的接收者，这些服务可被看作系统的需求。视点与某特定问题域相关，是一个由表示知识、开发知识和规约知识等构成的松散耦合、局部管理的对象。2023/2/4512.1什么是视点视点包含问题和问题解决过程的部分信息，它是与问题、问题域及问题解决过程相关的一个特定和部分的方法或视图。视点是一个形式化的部分规格说明。视点代表了系统相关人员的观点和看法，并且是对来源于某特殊角度的部分需求信息的封装。2023/2/4612.2多视点与需求工程多视点 多视点就是在客观分析若干视点的内、外部关系的基础上对其进行有机的整理和综合。面向多视点的需求工程 希望在不同的高度和层次上，对计算机软件系统进行预期的客观刻画和规划，进而指导开发行为并得到一个符合要求的目标系统。2023/2/4712.2多视点与需求工程多视点需求模型2023/2/4812.2多视点与需求工程面向多视点的需求工程方法的优势复杂系统的本质特性与多视点思想吻合，利用多视点需求工程方法可以有效地减少某些重要需求被遗漏的可能性，从而保证了需求规约的完备性；每个视点只需关心它自己感兴趣的内容，不需或较少地考虑其它因素的影响，从而有效地降低了需求获取和描述的难度，有利于提高整个需求工程的质量；2023/2/4912.2多视点与需求工程视点的形式使软件系统以一种更加结构化的形式被描述，从而为自动化的完备性和一致性检查提供了可能性；多视点为封装软件系统的不同描述模型提供了一个强而有力的手段；通过把需求和表达需求的视点关联起来，可增强需求的可追踪性。2023/2/41012.3多视点需求工程的过程模型多视点需求工程的需求分析过程2023/2/41112.3多视点需求工程的过程模型视点标识（1）I．Sommerville给出了标识视点的一般方法：从视点类层次图中删除那些与待开发软件系统不相关的视点；考虑目标系统的各类相关人员，若某些类型的项目相关人员不是组织视点类的一部分，则增加该类型的视点；使用一个系统体系结构模型标识子系统的视点；2023/2/41212.3多视点需求工程的过程模型标识以不同方式和频率使用系统的各类操作员，分别对应不同的视点；对每个已标识出的间接视点类，考虑与其相关的主要人员的角色，在需要的情况下使不同的角色对应不同的视点。（2）RM-ODP方法从静态的角度定义了五类视点：企业视点，信息视点，计算视点，工程视点和技术视点。2023/2/41312.3多视点需求工程的过程模型视点的表示A.Finkelstien采用模板的形式表示每个视点的内容及与其它视点的关系。I.Sommerville在其VORD方法中以框架结构的形式来表示视点。RM-ODP中除声明了五种类型的视点外，也对描述每种类型视点的语言应具有什么样的特征进行了定义。概念图、Z、LOTOS、一阶逻辑等。2023/2/41412.3多视点需求工程的过程模型视点的分析视点一致性定义基于规则型基于逻辑型基于可实现型2023/2/41512.3多视点需求工程的过程模型相关的一致性处理基于规则型:基于预先定义好的视点内部和视点间的一致性规则，以及一致性检查过程模型，这些规则和过程模型由视点模板的设计者根据该模板的用途进行定义。基于逻辑型:用一阶逻辑作为不同规约语言的语义域模型，然后从逻辑的角度定义和检查视点内部及视点间的一致性。基于可实现型:以变换系统作为不同视点规格说明的公共语义模型，由于该变换系统包括静态结构、动态行为及体系结构等多方面的内容，故可作为多种不同类型规约语言的公共语义模型，克服了采用一阶逻辑作为公共语义模型的不足。2023/2/41612.3多视点需求工程的过程模型不一致性的管理 忽略、暂时回避、采取措施缓解不一致的程度、完全消除不一致。2023/2/41712.3多视点需求工程的过程模型视点的集成 视点的集成是多视点需求工程过程的最后一个阶段。在多视点需求工程方法中，由于采用的视点的方式分散地获取和表示与不同用户相关的需求信息，为生成一份统一的需求规格说明或需求模型，最终必须将各个视点中的需求信息集成为一个统一的整体，以作为后阶段系统开发及系统测试和验收的依据。2023/2/41812.4实例说明问题描述：列车保护控制系统TCS（TrainControlSystem） 列车是由司机控制的，且司机应遵守一些有效操作规则。TCS是一个安全系统，其工作就是当检测到不安全状态时，对列车进行干预和控制，此外，如果司机不遵守时，TCS将采取正确的措施。此处的有效操作规则包括速度限制和传递信号的协议，其中有些规则是不变的，有些可能随现场情况而发生变化。TCS从轨道两旁的设备实时收集数据，以监控列车速度和检测信号。如果司机让列车开得太快，或者非法越过停车线时，TCS将进行紧急刹车。TCS必须与已有的运行环境和列车上其它系统集成，并通过硬件系统接口模块HIS（HardwareSystemInterface）与其它所有硬件接口进行通信。这些接口为：

·允许调用紧急刹车功能。

·允许TCS查询列车速度和离停车线的距离等数据。2023/2/41912.4实例说明PREView方法的过程2023/2/42012.4实例说明视点的标识2023/2/42112.4实例说明TCS视点层次2023/2/42212.4实例说明视点的表示安全状态保证的视点2023/2/42312.4实例说明错误状态恢复视点2023/2/42412.4实例说明视点的分析 视点的分析工作分为两个方面，一方面是视点内的需求与所涉及的具体问题是否一致，另一方面是分析视点内需求与外部需求是否一致。2023/2/42512.4实例说明检查满足关注的交互矩阵为了确保一致性的交叉检查视点2023/2/42612.4实例说明视点的集成规定需求规格说明文档的规范，将其分为几个主要部分，如系统概况，系统约束，功能需求，性能需求和接口需求等；建立需求规格说明文档必须满足的特征和质量等，并将其构造成表格形式（检查表），并通过此表