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的支持能力了。
閱讀更多 瘋狂架構 的文章
