基于本體的需求分析和軟件體系結構設計研究

江東宇+康達+周王順

摘要：傳統的軟件開發模式下，從提出需求到完成設計之間跨越的鴻溝是降低開發效率的主要因素。為了輔助設計人員進行高效的軟件開發，文中提出一個基于本體的需求分析和軟件體系結構設計方法。首先建立領域本體模型、需求本體模型和軟件體系結構本體模型；接著在需求分析階段，通過本體映射將用戶需求映射到本體概念上，進行準確地需求質量評估；然后在體系結構設計階段，通過對網上共享的設計文檔進行五種維度的語義標注生成語義索引，實現跨領域的語義搜索，為設計人員提供更全面、更詳細的設計文檔作為參考；最后結合自己項目的特點，逐步構建、完善系統體系結構。本文將本體作為描述需求和體系結構的基礎，實現了需求到設計的平滑過度，減少了設計人員和用戶進行交流的時間開銷，對于整體提高軟件開發效率來說具有一定的幫助。

關鍵字：本體；語義網；語義標注；語義搜索；軟件體系結構設計

中圖法分類號：TP311文獻標識碼： A doi：

Abstract：In the traditional software development mode，the wider gap betweenrequirementanddesign which is the main factor to reduce the development efficiency. In order to assist designers to carry out efficient software development， this paper addressedaframeworkwithontologytechnology. Firstly， theDomainOntologyModel， Requirement OntologyModel and SoftwareArchitectureOntologyModelware built.Then in the requirements analysis phase， userrequirementswaremappedto the ontologynode inorder to moreaccuratelyassessneeds.During the summary design phase， it achieved interdisciplinarysemanticsearch through multidimensional semanticannotationof the design document and provided a more comprehensive and detailed template for designers， then using it to completesystems or subsystemarchitecturedesign.This paperdescribes the ontology as thebasis for the requirementsandarchitecture， not only to achieve a smooth transition from requirements to design， but also reduces the time overhead of the communication between the designer and the user.It is helpful to improve the efficiency of software development.

Keywords：Ontology；Semantic Web；Semantic Annotation； Semantic Search；Software ArchitectureDesign

1. 引言

隨著軟件的普及，用戶對系統提出的需求也在與日俱增，軟件開發過程變得越來越復雜。一個良好的需求規格說明對于成功的軟件開發項目來說是至關重要的。但是需求工程階段是既耗時又容易出錯的，主要表現在如何獲取用戶的真實需求以及如何發現需求中存在的錯誤，這需要開發人員與客戶不斷的溝通交流，并且許多錯誤是在執行或測試階段才被檢測出來，這大大增加了軟件開發周期，降低了整體開發效率[1-4]。在需求分析完成之后，接下來就要進行系統體系結構設計，這一階段要求開發人員從整個系統的角度進行考慮，設計一個從整體到部分的最高層次的劃分[5]。在這過程中，面臨的最困難的問題就是如何滿足用戶需求和常見的體系結構設計目標，如可靠性、安全性、可擴展性、可維護性等。除了提升設計人員自身的知識能力水平之外，另一種辦法就是調研同類產品的情況以及技術特征[6]。通過了解當前世界上對這種產品所能提供的理論支持和技術平臺支持，再結合自己項目的特點，逐步構建完善系統體系結構，但是如何理解設計文檔中的領域詞匯，如何從網上海量的數據中高效的選擇和自己項目類似的文檔，這些都是我們所要解決的問題。

近幾年研究人員探討使用人工智能技術，用以解決這些問題[1][2]。Avgeriou P等人在文獻[1]中將軟件工程定義為一個跨學科的問題，與大量的情景、社會學、心理學、人類學和教育因素等有關，并且分析了其中可能產生的問題，例如需求是不完整的、模糊的、不精確的等。針對這些原因，Hany H Ammar等人在文獻[3]中分析并提出有必要探索一個新的技術和方法，用于整合在軟件工程中積累的理論、技術和資源，提供一個統一的、共享的、公認的知識基礎設施。因此他們將人工智能技術引入軟件工程，具體包括自然語言需求處理（NLR）、知識庫系統（KBS）、本體和智能計算。

本體作為人工智能技術的一種，能夠用于復用、集成、合并數據和知識，構建一個統一的、共享的、公認的知識基礎設施，并且通過推理得到信息中蘊含的隱藏信息或錯誤信息。M. P. S. Bhatia等人在文獻[4]中詳細介紹了軟件工程領域中各個本體的定義和實際應用價值，包括Upper Ontology、Domain Ontology、Architecture and Design Ontologies等，但僅僅是一些概要性描述，沒有給出一個完整的知識體系來實現在整個軟件開發周期中理解和溝通的共享。

針對本體在軟件工程中應用的研究方向，LI Zong-yong等人在文獻[7]中提出一個多本體框架用于輔助設計人員進行需求獲取，并且對框架中提及的多種本體進行了描述，但是該研究只是理論階段，沒有對本體中的概念進行形式化描述，也沒有驗證本體如何對需求進行質量評估。R?ih? O.等人在文獻[8]中提出一種基于基因遺傳算法的軟件體系結構設計，它將設計過程看成是一個搜索問題，即尋找一個應用通用方案的組合，能夠以最優的方式滿足質量要求。通過基因遺傳的啟發式搜索方法，自動生成一個合理的軟件體系結構。但是該方法的出發點是一個已經滿足功能需求的概念體系結構，對于需求與體系結構之間的平滑過度沒有很好地解決。H. Duran-Limon等人將本體引入軟件產品線工程中，在文獻[9]中提出一種基于本體的產品導出方法，用本體作為描述需求模型的基礎，然后利用本體的邏輯推理能力，在需求模型到產品體系結構模型轉換過程中提供推理服務，以此減少手動導出的開銷，但是該方法只考慮了本體對需求模型的重構，沒有考慮質量屬性在產品體系結構推導過程中對結構變化的影響。

本文利用本體作為描述需求和體系結構的基礎，通過建立領域本體模型、需求本體模型和軟件體系結構本體模型，幫助分析人員在需求分析階段更準確的捕獲和評估用戶需求；在體系結構設計階段利用語義標注和語義搜索技術，輔助設計人員從海量的設計文檔庫中選擇具有語義相似的系統體系結構文檔作為參考，對實現需求到設計的平滑過度和提高軟件開發效率來說都起到一定的幫助。

文章其余部分結構如下：第二節概述了我們提出的整個框架以及框架中用到的本體的構建。第三節詳細介紹本體在需求分析和體系結構設計階段是如何發揮作用的。第四節總結我們的工作并討論今后工作的研究方向。

2. 框架概述

2.1 總體框架

軟件開發是一個復雜的、不斷演變的社會活動，涉及了許多層次和方面。為了能夠幫助開發人員更準確地理解整個系統，我們提出了一個基于本體的需求分析和軟件體系結構設計框架。

圖1描述了整個框架，其中可大致分為兩階段，第一階段：根據用戶給出的需求文檔，結合領域本體和需求本體進行語義映射，為其添加語義信息，同時利用這些語義信息進行需求質量評估，用以修改、完善用戶需求。第二階段：通過軟件體系結構本體，對網上共享的軟件設計文檔進行語義標注，建立體系結構本體和領域本體以及需求本體的一種內在語義關聯，再根據系統的功能性和非功能性需求以及架構限制和目標的系統高層架構，通過這種語義關聯進行語義搜索，按照搜索條件返回相應的結果，例如整個設計文檔、文檔中部分段落或者圖表等，用于輔助構建、完善系統的體系結構。

文中提出的方法是針對傳統的瀑布式開發模型，但是在實際開發過程中很少完全采用瀑布模型，因此在接下來的研究中，將進一步探討如何在當前一些流行的開發模型中使用這種本體輔助設計思路，如敏捷開發模型、RUP模型、CMMI模型等。

在框架中一共使用了四個本體：頂層本體、領域本體、需求本體和軟件體系結構本體。前三個本體在文獻[7][10][11]中已經進行了詳細的定義，我們對其只進行簡單的介紹，這里主要對軟件體系結構本體的構建進行詳細描述。

2.2本體構建

2.2.1頂層本體、領域本體和需求本體

首先我們介紹一個頂層本體[10]。頂層本體描述的是通用的基本概念和它們之間的關系，例如object、environment、goal、task等都是獨立于特定的應用程序的基本概念，其他本體中的概念都是頂層本體中的概念的實例。

領域本體描述的是一種靜態的、可重用的領域概念和關系，例如汽車行業領域本體就表示了有關汽車部件的知識[7]。在需求分析階段扮演了一個領域字典的角色。

僅僅使用領域本體無法很好地表達出用戶指定的系統功能需求和非功能需求，因為在領域本體中無法對用戶的業務目標、質量屬性等進行語義描述，因此還需要構建一個需求本體，也可以叫做系統行為本體[4][11]。需求可以分為兩種類型：功能需求和非功能需求，功能需求可以描述為系統執行的操作序列，非功能需求表達了系統質量相關的方面。系統行為本體是對軟件系統的行為進行建模，例如在特定情況下系統將要執行什么操作，它還定義了在一個操作執行之前需要滿足的條件，以及操作執行時系統的狀態等。

2.2.2軟件體系結構本體

為了能夠對網上共享的設計文檔進行語義標注，我們需要建立一個軟件體系結構本體[12][13]。圖2中描述了該本體的高層視圖。我們使用UML圖表示該本體的結構，包含的類有：SoftwareArchitecturePattern，SoftwareArchitectureVocabulary，SoftwareArchitectureStyle，Problem。

我們使用本體開發工具Protégé來構建該本體。首先根據《Software Modeling& Design》[14]書中介紹，將軟件體系結構模式分為三類：結構模式、通信式和事務模式，將每一個類別中包含的模式概念作為SoftwareArchitecturePattern的子類進行描述，然后以一些常用的軟件體系結構風格為基礎，例如B/S風格、管道和過濾器風格、面向對象風格、倉庫風格等，進行歸納總結，作為SoftwareArchitectureStyle的子類。我們將每種風格中包含的 構件、連接件和拓補結構作為SoftwareArchitectureVocabulary的子類，并且與SoftwareArchitectureStyle的關系是isPartOf。對于每一種軟件體系結構模式或架構風格來說，都是一些經過實踐證實的解決方案，可用于解決領域中的某些核心問題，因此我們將這些問題描述為Problem類，與SoftwareArchitecturePattern和SoftwareArchitectureStyle的關系是isSolutionTo，圖3表示Protégé中的軟件體系結構本體類和對象關系。

為了更全面地描述該本體包含的內容，這里我們使用了一個本體可視化插件OntoGraf，圖4表示了軟件體系結構本體可視化結果。

3. 基于本體的需求和設計方法

3.1基于本體的需求獲取和評估

當拿到用戶需求文檔之后，分析人員首先要做的就是挖掘用戶的真實需求，這是由于人與人之間的交流溝通無法達到100%，因此這一步也是最重要的。對于分析人員來說，要想挖掘出真實的需求，就要求對業務和技術都有所了解，這往往也是最難的，借助本體的輔助或許能夠解決這方面問題。

借助領域本體和需求本體的輔助，可以從用戶的角度來進行需求獲取，用戶參與需求分析主要有兩種方法：一是在領域本體的指導下填寫問卷調查，意味著通過問題解決法來表達用戶的真實需求。二是借助CASE工具，使用領域本體和需求本體中的領域知識進行需求建模?？梢钥闯鲱I域本體和需求本體的作用不僅是指導用戶快速的提出需求，而且還能夠保證最終的需求模型沒有違反領域標準和規范。

除此之外，通過領域本體和需求本體的結合使用，還能夠對用戶需求的準確性、完整性、一致性、無二義性進行評估分析。為了能夠分析出這些用戶需求的質量屬性，必須先建立需求和本體之間的一種映射關系。首先對于用戶提供的非結構化需求文檔進行文字預處理，針對每個需求進行實體和關系的抽取，然后將其映射到領域本體和需求本體的概念上，如圖5所示。

完成映射后，也就意味著將用戶的需求描述轉換為用本體中的概念和關系進行表示，即為需求文檔中的用戶需求添加了語義信息。在假定映射正確的情況下，接下來可以利用這些語義信息進行需求質量的評估，并且反饋給用戶和分析人員執行不同的解決措施。

（1）準確性檢測：當一個需求條目能夠被映射到本體元素上時，我們認為它是針對一個問題域的準確的需求。對于無法映射到本體的需求，反饋給用戶詢問其是否是有必要的，若是由于其中包含的概念是該領域的新型詞匯，那么就交由技術人員對本體進行添加修改，再重新進行需求的準確性檢測。

（2）一致性檢測：如果在兩個需求條目映射的本體元素之間，存在“矛盾”約束屬性，例如兩個類是互斥類（Disjoint classes），那么我們認為這兩個需求是不一致的。通過在映射的本體元素中搜索“矛盾”關系來發現不一致性的需求條目，根據需求的優先關系來幫助用戶和分析人員進行刪改。

（3）完整性檢測：在理想狀態下，對于所有相關聯的本體中的元素，都應該出現在映射的需求條目中，例如一個用戶管理系統的需求“Userscanchange the phonenumber for the binding”映射到本體中的元素為{change， phonenumber}，而在需求本體中這些元素與{Add， phone}和{Unbind，phonenumber}存在Complementary（互補的）關系，這意味著和功能也應該出現在這個需求條目中，如果沒有則可以認為該需求是不完整的，需要向其添加新的概念元素。

（4）無二義性檢測：如果一個需求條目被映射為若干個沒有語義關系的概念，那么可以認為該需求存在歧義，擁有多重含義。針對這種情況需要將存在歧義的需求進行修改、移除或者分解成多個需求，以此消除歧義。

3.2 基于本體的軟件體系結構設計

軟件體系結構對于軟件開發有著舉足輕重的作用，只要需求和體系結構確定之后，這個軟件就基本上可以定型了。這就好比骨骼確定了，這個人的體形就不會有很大的變化。

但是在實際項目開發中，很少有團隊會注重系統體系結構設計，甚至會忽略這一過程，主要原因是需求是從用戶角度看待系統，體系結構是從設計角度看待系統，因此在需求和設計之間存在著巨大的鴻溝，這對設計人員來說不僅要有豐富的軟件開發經驗，還需要擁有一定的領域知識。這里我們希望通過本體將需求和設計進行抽象化，在抽象出的需求模型和設計模型之間建立語義關聯來縮小這個鴻溝。

在前一節中介紹了如何將需求映射到本體中的概念和關系上，這也意味著我們已經將用戶需求抽象為一個需求模型。接下來我們將探討如何利用語義標注[15]技術來對體系結構進行抽象。

3.2.1使用軟件體系結構本體的語義標注

如果說本體的構建主要是關于領域知識的抽象表示，那么語義標注可以看作是豐富本體的過程，即添加、擴展本體實例。因此語義標注所要做的工作就是將現實應用中涉及的實例和抽象的本體概念聯系在一起。

這里我們使用的是GATEdeveloper，一個應用于自然語言處理領域，尤其是信息標注與抽取環節的開放源碼架構。根據前面建立的軟件體系結構本體，對匹配的概念、實例等元素進行語義標注，其流程如圖6所示：

執行該流程，為資源文本添加語義信息，這里我們提出可以按照表1中幾個維度進行語義標注：

內容類型

例如我們按照文檔結構維度，即標題、段落和句子三個方面進行語義標注，對標題進行標注的內容主要是關于系統或子系統使用的體系結構風格，對段落進行標注時主要注重整段內容語義的索引，對句子進行標注時主要注重相關概念的提取。其中語義索引包含的內容為本體中出現的概念，索引的鍵是概念及概念的屬性，索引的值是文檔的位置、文檔的內容、文檔的語義信息。這種標注方法適用于結構化的設計文檔，對于無結構化的文檔需要先根據經驗對文檔進行理解、總結，再按照上面介紹的三個方面進行標注。

利用本體直接標注資源的優勢在于標注方式靈活，并且能夠確保語義標注準確率，進而充分挖掘資源語義，增強語義標注效果。經上述過程完成的語義標注結果是形成設計文檔的語義索引，語義索引主要保存了一個文檔的三個主要信息：1.文本的層次級別（篇章、段落、句子）。2.文本段落的內容。3.文本段落的語義。標注后應將文本的索引結構以一定的形式保存起來，以供下一節的語義搜索使用。我們將標注信息以可視化方式顯示在文檔資源中，如下圖所示：

我們希望能夠對每個文檔都按照上面五種維度進行標注，但是這樣一來標注過程就變得十分繁瑣，下一步我們將參考近幾年提出的一些新的語義標注方法對其進行改進，例如Rajput等人提出的一種基于貝葉斯網絡的語義標注框架[16]；Nguyen等人提出一種基于樸素貝葉斯和關聯規則，并結合本體結構圖和交互網絡的語義標注方法[17]等。

在標注完成后，將新的實例信息抽取到本體，即保存在本體類的實例信息中作為新的個體，在下次加載本體時應用，通過這種信息抽取也可以促進本體進化。最后將含有語義標注信息的文本資源解析為XML文件格式存儲，形成語義標注庫，代碼片段如下：

……

ontology

http：//www.semanticweb.org/pc-jdy/ontologies/2016/3/SoftwareArchitecture.owl

class

http：//www.semanticweb.org/pc-jdy/ontologies/2016/3/SoftwareArchitecture.owl#安全性

……

3.2.2設計文檔的語義搜索

在執行完語義標注和信息抽取之后，下一步便根據標注生成的語義索引以及前面抽象出的需求模型進行設計文檔搜索，我們將上一節描述的標注對象作為搜索條件，根據不同的搜索條件返回相應的搜索結果。例如需要搜索使用了某個體系結構風格的整個項目設計文檔，便可以通過計算文檔與查詢實例的語義相關度，以及查詢實例與文檔的相似度后，得到各個文檔的排序得分，按得分高低將排好序的搜索結果返回給用戶。

這里我們主要探討如何在需求模型和設計文檔之間建立一種語義關聯，實現跨領域的語義搜索。關于搜索步驟、使用何種搜索算法、如何計算文檔的排序得分、搜索返回的相關文檔的數量有多少、正確率有多少以及如何評估返回的結果等問題是接下來我們研究的重點，可以參考第二節中介紹的基因遺傳算法的使用，以及[18]中介紹的一種設計模式的匹配搜索。

為了建立這種語義關聯，我們需要找到需求本體和軟件體系結構本體之間的關系。在第三節中，我們構建軟件體系結構本體時，將每一種體系結構模式或架構風格所能夠解決的某些方面的問題歸納總結為Problem類，而這些問題是從設計人員角度來進行描述的。如果從客戶的角度來看待這些問題，那么Problem類描述的其實就是用戶希望系統能夠實現的功能。因此可以將體系結構本體和需求本體，通過對系統行為的不同角度的描述來建立一種關聯，從而使本體映射后的語義需求模型和語義標注后的軟件體系結構設計文檔之間產生關系，為實現跨領域的語義搜索提供條件。

3.2.3 系統體系結構設計過程

接下來我們將利用搜索出的軟件設計文檔，結合自己項目的特點，逐步構建、完善系統體系結構，具體步驟如下：

第一步建立系統體系結構元模型。由于設計文檔中的概念是跨領域跨平臺的，所以先從中抽象出一個領域無關、平臺無關的系統體系結構元模型是有必要的。這里我們參考OMG組織提出的MOF四層模型結構[19]，所建立的系統體系結構元模型不僅僅是為了描述系統或子系統的體系結構，更重要的是它是從軟件設計文檔庫中抽象而來的，這意味著我們可以將它看作一個“設計藍圖”，更有效、更直觀的指導設計人員理解、構建系統體系結構。

關于如何構建以及構建什么樣的元模型將是我們接下來要解決的問題，可以借鑒一些相關的研究思路，例如[20]中介紹的通過構建系統特征模型來完成概念體系結構設計的方法以及[21]中提出的一種基于本體模型的架構知識管理框架等。

第二步建立系統體系結構模型。從系統的整體角度出發，結合用戶需求進行體系結構設計，這里主要考慮的是系統的非功能需求。

第三步建立子系統（子模塊）體系結構模型。這里可以根據用戶對子系統的功能需求，有針對性的再次進行語義搜索，然后對子系統進行元模型建模，進而完成子系統體系結構的構建。

4. 結束語

對于大多數系統的體系結構設計，我們都可以從現有的項目尋找共同點。鑒于此，本文從本體技術入手，先利用本體在領域知識表達方面的優勢，幫助用戶提出更加標準化和規范化的需求。再利用本體內在的邏輯推理能力，通過本體映射進行需求質量評估，快速的找到存在錯誤的需求，減少和用戶交流的時間開銷。然后利用本體在知識統一和共享方面的優勢，對網上共享的設計文檔進行語義標注，實現跨領域的語義搜索，從而更好地理解和構建系統（子系統）體系結構，縮短需求與設計之間的鴻溝。

在接下來的研究中，我們將進一步細化框架中的每個細節，對多個本體進行完善修改。針對設計文檔的語義搜索方面，改進多維度的語義標注方法，研究智能搜索算法的應用，設計并開發支持該框架的軟件平臺。

參考文獻：

[1] Avgeriou P， Grundy J， Lago P， et al. Relating Software Requirements and Architectures[J]. IEE Proceedings Software， 2005， 152（4）：141-142.

[2] Falbo R A， Guizzardi G， et al. Towards semantic software engineering environments[C]// 14th inter1national conference on Software engineering & knowledge engineering， 2002：477-478.

[3] Ammar H H， Abdelmoez W， Hamdi M S. Software Engineering Using Artificial Intelligence Techniques： Current State and Open Problems[C]//Proceedings of the First Taibah University International Conference on Computing and Information Technology， Al-Madinah Al-Munawwarah， Saudi Arabia. 2012：52.

[4] Bhatia M P S， Kumar A， Beniwal R. Ontologies for Software Engineering： Past， Present and Future[J]. Indian Journal of Science & Technology， 2016， 9（9）.

[5] Outi， Koskimies K， Kinen E. Multi-objective genetic synthesis of software architecture[C]//Conference Companion on Genetic and Evolutionary Computation. ACM， 2011：249-250.

[6] R?ih? O， Kai K， M?kinen E. Scenario-Based Genetic Synthesis of Software Architecture[C]// International Conference on Software Engineering Advances， Icsea 2009， 20-25 September 2009， Porto， Portugal. 2009：437-445.

[7] Zong-Yong L， Zhi-Xue W， Ying-Ying Y， et al. Towards a Multiple Ontology Framework for Requirements Elicitation and Reuse[C]// International Computer Software & Applications Conference. IEEE Computer Society， 2007：189-195.

[8] R?ih? O， Kundi H， Kai K， et al. Synthesizing Architecture from Requirements： A Genetic Approach[M]// Relating Software Requirements and Architectures. Springer Berlin Heidelberg， 2011：307-331.

[9] Duranlimon H， Garciarios C， Castillobarrera F， et al. An Ontology-based Product Architecture Derivation Approach[J]. IEEE Transactions on Software Engineering， 2015， 41（12）：1-1.

[10] Kaiya， H， Saeki， M. Using Domain Ontology as Domain Knowledge for Requirements Elicitation[C]// 14th IEEE International Conference on Requirements Engineering， 2006：189-198.

[11] Jiang H， Yang X. Performance requirement elicitation for financial information system based on ontology[C]//Tencon IEEE Region 10 Conference， 2009， 30（3）：1 - 5.

[12] De Graaf K A， Liang P， Tang A， et al. An exploratory study on ontology engineering for software architecture documentation[J]. Computers in Industry， 2014， 65（7）：1053-1064.

[13] Akerman A， Tyree J. Using ontology to support development of software architectures[J].IBM Systems Journal， 2006， 45（4）：813-825.

[14] 戈馬 H. 軟件建模與設計[M].彭鑫，吳毅堅，趙文耘，等譯.北京：機械工業出版社，2015.

[15] Fernández M， Cantador I， López V， et al. Semantically enhanced Information Retrieval： An ontology-based approach[J]. Web Semantics Science Services & Agents on the World Wide Web， 2011， 9（4）：434-452.

[16] Rajput Q， Haider S. BNOSA： A Bayesian network and ontology based semantic annotation framework[J]. Web Semantics Science Services & Agents on the World Wide Web， 2011， 9（2）：99-112.

[17] Cao D N， Gardiner K J， Cios K J. Protein annotation from protein interaction networks and Gene Ontology[J]. Journal of Biomedical Informatics， 2011， 44（44）：824-9.

[18] Harb D， Bouhours C， Leblanc H. Using an Ontology to Suggest Software Design Patterns Integration[M]// Models in Software Engineering. Springer Berlin Heidelberg， 2009：318-331.

[19] Tang W. Meta object facility[M].Encyclopedia of Database Systems. Springer US， 2009： 1722-1723.

[20] 彭鑫，趙文耘， 劉奕明. 基于特征模型和構件語義的概念體系結構設計[J]，軟件學報， 2006， 17（6）：1307-1317.

[21] 張純， 張敬周， 宋俊典. 基于本體的軟件密集型系統架構知識管理研究[J]. 計算機工程與設計， 2011， 32（6）：2050-2053.