DOORS是汽车、军工等行业普遍使用的需求管理工具，第三方系统与DOORS集成以打通需求与其他生命周期工件的链路，一般来说具有比较高的业务价值。DOORS对OSLC的支持为集成人员提供了便捷的集成实现方式，同时，也为终端用户提供良好的用户体验。
DOORS功能简介
DOORS是使用非常普遍的需求管理工具。其核心功能包括：
- 需求条目化管理
- 需求的最小粒度：需求条目
- 强大的自定义属性功能
- 需求状态管理
- 灵活定义不同的需求状态属性
- 需求版本管理
- 需求条目级：WHO WHEN WHAT
- 需求基线：单模块基线和多模块复合基线机制
- 需求追踪：分层结构追踪和链接关系追踪
- 视图功能
- 灵活的权限控制：基于角色和用户对视图的访问权限进行控制
- 便捷的数据检索过滤功能以支持对不同视图的定义
DOORS工具组件
DOORS是基于C/S模式的桌面应用软件，其核心组件是服务器端软件和客户端软件，以及提供许可证验证服务的软件（独立的）。
- 服务端软件：部署并运行在服务器上，以服务的形式运行
- 客户端软件：部署并运行在用户个人PC
DWA是DOORS Web Access的简称，该组件独立安装并进行一定的配置后，可以为DOORS提供基于浏览器的访问功能。DWA所提供的功能是DOORS客户端功能的子集，并不具备完全的客户端所有的功能。
浏览器端比较适合数据的查看。因为其不需要客户端在PC上安装客户端软件，就可以方便的浏览DOORS中的数据
系统集成的价值
企业在信息化过程中，很难完全基于统一的平台涵盖所有的领域，工具往往具有多元化的特征。各个领域工具形成的信息孤岛阻断了不同领域工具间的数据流。实现数据的交互是不同工具集成的最为典型和直观的形式，除此之外，还有一个非常重要的商业价值就是：通过系统集成的方式，最大限度的实现已有资产复用。另外，一些行业标准也对与需求相关的关联性提出了一定要求。比如汽车行业的ASPICE对追踪性和一致性的做了整体性的要求：
从追踪性和一致性的角度考虑，为了实现领域工具内的工件与需求间的基于双向链接关系的追踪，实现与需求管理工具的DOORS的集成则具有较高的业务价值。通过创建并维护与DOORS中需求的链接关系，来满足实际业务或标准中的追踪要求。
从工具集成的角度，典型的可能在如下领域工具与DOORS间存在集成的必要性，如下图所示：
- 需求管理系统与测试管理系统的集成，以实现需求与测试用例间的双向追踪。
- 需求管理系统与问题管理工件的集成，以实现需求条目与问题项的双向追踪。
- 需求管理系统与模型工件的集成，以实现需求条目与模型或模型组件间的双向追踪
- 需求与架构设计工件的集成，以实现需求与架构元素间的双向追踪。
- 需求与配置管理工具间的集成，以实现需求与配置库变更集间的双向追踪。
- 需求与变更管理工具间的集成，以实现需求与变更请求间的关联。
当然，与需求管理系统的集成存在诸多的应用场景，可能包括但不限于如上领域的集成。
可选集成方式：基于DXL的集成
DXL是DOORS工具的扩展语言，类C的脚本语言，主要用来对DOORS工具进行功能扩展。基于DXL开发的插件需要在DOORS工具的上下文环境中运行。功能扩展大致可以分为两种类别：
- DOORS软件自身功能的增强：自动化脚本、UI扩展等
- 与第三方工具的集成
基于IPC方式，以DXL脚本的形式在DOORS Server端运行服务，负责实时接收客户端发送的请求，并做相应业务逻辑处理后将结果返回到客户端。基于DXL方式集成的关键是规划好的客户端和服务端交互的数据协议，例如交互格式、内容结构、异常机制等等。
基于DXL的集成方式比较适合纯的数据形式的集成，例如在第三方工具中获取DOORS项目列表、获取模块的视图列表、获取需求列表等等，客户端在获取返回数据后再基于已约定好的协议进行解析，然后再做相应处理。
可选集成方式：基于OSLC的集成
DOORS提供的OSLC UI 能力
- 需求条目的Selection Dialog
- 需求条目的Creation Dialog
- 视图的Selection Dialog
- 需求的UI Preview
- 视图的UI Preview
DOORS提供的OSLC操作：
典型的集成拓扑结构
OSLC是系统集成的一套标准，其包含了核心规范和不同的领域规范，对系统集成的相关技术以及标准进行了统一的规范性的定义。根据领域工具的不同类型，基于OSLC的形式与DOORS集成大致分为三类，如下图所示：
- 全新工具：直接在工具代码级别实现对OSLC Server的访问
- 提供了扩展机制的已有工具：用户已插件的形式对原有工具进行扩展，并领用OSLC RM API与DOORS实现集成
- 无扩展机制的已有工具：可以开发独立的代理程序，负责已有工具与DOORS的桥接。
基于链接形式的集成
典型的，基于链接形式的系统集成场景：
- 基于已有资源创建链接关系
- 用户选择DOORS中已有的需求，并建立与第三方工具间的链接关系
- 基于新建资源创建链接关系
- 用户在第三方工具中动态创建需求并需求建立链接关系
对于需求管理系统DOORS而言，第一种链接形式更为常见，也固有更高的业务价值。当然，除了如上集成形式之外，可能还需要如下辅助的集成场景：
- 链接关系的移除
- 可疑链接关系的检测：当双向链接关系两端的资源失效后，要对当前链接关系的有效性进行检测，以便用户及时发现并处理这种无效链接。
基于已有资源创建链接关系
- S1: 在第三方工具选择待关联的本地工件
- S2: 获取DOORS中的资源列表
- S3: 选择DOORS中的待关联的目标需求
- S4: 更新DOORS资源，将链接关系写入DOORS
- S5: 更新本地资源，将链接关系写入第三方工具
基于新建资源创建链接关系
- S1: 在第三方工具选择待关联的本地工件
- S2: 加载DOORS的需求创建表单界面
- S3: 输入DOORS需求表单数据
- S4: 创建DOORS需求，并获得新建的需求URI
- S5: 更新DOORS需求，并写入链接关系
- S6: 更新第三方工具资源，并写入链接关系
集成中需要解决的关键问题（OSLC相关）
OSLC服务发现
DOORS支持OSLC RM 规范，其提供的服务支持OSLC规范要求的寻址方式，如下图所示：
正常的基于OSLC的集成方式，客户端代码要基于OSLC的服务发现机制逐层获取所需要的服务地址，这是最为理想和健壮的实现方式。DOORS/DWA对外提供了跟服务入口是：
<code>https://server:port/dwa/public/rootservices/<code>
OSLC服务的HTTP请求头设置
<code>Accept: application/rdf+xmlOSLC-Core-Version: 2.0/<code>
实现方式上可以采用最原生的HTTP请求-响应，然后基于返回的数据解析XML数据。也可以采用OSLC相关的类库，比如OSLC4J库。
OSLC Delegated UI 的加载
OSLC “Delegated UI” 为系统集成提供了良好的用户体验，基于这种方式，跨领域工具的工件选择和创建都是无缝的，客户端程序的实现不需要构建与目标工具一致的UI，只需要对目标工具提供的 "Delegated UI" 进行加载并展示。通过这种集成机制，在当前工具中能够提供与目标工具一致的用户界面，极大的提高用户体验。如果您是在Web系统中集成DOORS，则通过HTML的IFRAME直接加载DOORS的OSLC UI 地址即可。如果是在非WEB系统中，则要选择相应的HTML加载控件即可。如下是在桌面客户端中加载DOORS的需求选择界面的示例：
如何获取选择或创建后的需求数据？
基于OSLC Delegated UI机制加载界面并选择或创建资源后，第三方应用需要获取选择或创建的资源URI和标签。实现方式如下图所示：
选择数据后通过H5的POST MESSAGE机制进行跨域数据传递，因此，在上层应用中，需要通过事件监听机制获取Post的数据。以Web系统为例，则需要在页面中注册如下事件监听：
<code>window.addEventListener("message", function (event) { var message = event.data; // TODO: Handle the message }, false);/<code>Message内容结构如下：
<code>{ oslc-response:{ oslc:message: "oslc.select", oslc:results:[ { "rdf:resource": "https://clm-pc:9443/rm/resources/_K40n0TpwEemxhdDGwPP8YA", "rdf:type":"https://clm-pc:9443/rm/types/_iDi60TNFEemOcdPKSpXMaQ", "oslc:label":"2：demo" } ] }}/<code>最后
与需求管理系统的集成，在实际的研发生命周期中具有较高的业务价值。建议与DOORS集成时首选采用OSLC方式进行集成，特别是涉及到链接这种情况时，OSLC提供的Delegated UI机制具有更好的用户体验。另外，本篇粗略描述基于OSLC形式与DOORS进行集成的几个方面。对于支持OSLC规范的工具来说，集成形式大同小异。比如，RTC、DNG、RQM等工具都支持OSLC规范，如果与这些工具进行集成，则要参考相应的领域规范以及工具对OSLC的支持能力了。
閱讀更多 瘋狂架構 的文章
