1 概述
面向服務體系機構(Service-Oriented Architecture, SOA)是一個面向服務的組件模型，從建模和設計的角度來說，SOA更多地側重在業務層次上。在業務建模上，業務流程建模標記(Business Process Modeling Notation, BPMN)憑借其圖形化、容易被業務人員理解、支持復雜的業務流程設計并且能夠直接映射到基于XML 的業務流程執行語言等特點，成為業務分析領域的主要流程建模規范之一。
針對SOA系統的規模估算方面，至今還沒有一個有效的解決方案。IFPUG 功能點方法在估算SOA系統規模上也沒有取得良好的效果。全功能點方法是一種逐漸被廣泛采用的規模估算方法。文獻[3]提出使用全功能點方法估算SOA系統的規模，但是它僅從理論上闡述了用全功能點估算SOA系統規模的可行性和定界問題，并沒有給出具體的解決方案。
本文在以上研究成果的基礎上，根據全功能點和BPMN的特點，建立一套從全功能點到BPMN 的映射規則，給出全功能點估算SOA系統規模的步驟，并通過一個實例說明具體的估算過程。
2 軟件規模估算與全功能點方法
功能點方法就是估算軟件功能性用戶需求的大小，是針對代碼行的缺點而提出的一種規模估算方法，獨立于具體的開發技術和平臺，適應軟件開發周期早期。在眾多功能點方法中， IFPUG 功能點(International Function Point UserGroup)和COSMC 全功能點(Common Software MeasurementInternational Consortium)已成為ISO 國際標準，并且是目前被廣泛應用的2 種功能點估算方法。
IFPUG 功能點方法的主要思想是將軟件分解成基本功能組件(內部邏輯文件、外部接口文件、外部輸入、外部輸出、外部查詢)，并對每個基本功能組件計算其復雜度，折算成未調整的功能點個數，求和得到軟件總的未調整功能點數。這種方法的“基本功能組件”很難與SOA中的“服務”建立映射關系，因此不適合估算SOA系統的規模，文獻[3]也闡述了這一點。
全功能點方法的主要思想是將系統分解成層次，每個層次分解成若干對等組件，每個對等組件又分解成若干功能流程。每個功能流程包含若干數據移動，一個數據移動是一個數據組的傳輸，一個數據移動記為一個功能點。如圖1 所示，有4 種類型的數據移動：輸入(Entry)，輸出(Exit)，讀(Read)和寫(Write)。全功能點方法中“層次”、“對等組件”可以與SOA中的“服務”建立映射，而且功能點的“功能流程”可以很容易地與BPMN 中“業務流程”建立映射。基于以上分析，認為全功能點方法最適于估算SOA系統軟件的規模。
圖1 全功能點方法的數據移動
全功能點方法的主要核心元素是與BPMN 映射的關鍵，可參照度量手冊。這些核心元素包含層次、對等組件、功能用戶、邊界、功能流程、事件、數據組、數據移動等。
3 SOA系統與BPMN 建模
在SOA體系結構中，服務是最核心的抽象手段，其中一個簡化的SOA體系結構如圖2 所示。
圖2 簡化的SOA體系結構
從建模和設計的角度講，SOA更多地側重于業務層次上，業務被劃分為一系列粗粒度的業務服務和業務流程。業務服務有多種實現方式，其中最流行的實現技術是Web 服務。Web 服務定義了如何在異構系統之間實現通信的標準化方法，使得服務可以跨平臺和具體語言實現。業務流程被定義為一個由各種不同功能的活動相連的一組有相互關系的任務，它們依照一定的業務邏輯和順序依次執行，業務流程有起點和終點，并且它們都是可重復的，業務流程可以按一定邏輯將“服務”組裝起來，形成功能更豐富的服務，稱為組合服務。
BPMN 通過一套繪圖元素為業務流程建模，既能提供給用戶直觀的模型界面，又能表示復雜的業務流程。其能同時被業務人員和技術人員理解的特點，使之成為溝通業務流程設計和流程實現的橋梁。BPMN 與全功能映射的主要繪圖元素包含事件、活動、網關、序列流、消息流、泳池、泳道，數據對象等完整的繪圖元素可參考BPMN 規范。
4 全功能點與BPMN 的映射關系
4.1 映射規則
映射的主要任務就是把全功能點的核心元素映射到BPMN 的繪圖元素中，目的是估算出以BPMN 圖形表示的業務流程包含的全功能點數，從而估算出SOA系統的規模。通過分析研究，是把全功能點方法的核心元素映射到BPMN 主要繪圖元素中，如表1 所示。
表1 全功能點與BPMN 的映射關系
為了說明表1 的映射關系，補充了如下映射規則。
規則1 全功能點的層次(Layer)是與軟件的體系結構相關的，層次的粒度特別大，通常將整個BPMN 圖形表示的功能流程映射為一個層次。
規則2 全功能點的對等組件(Peer Component)和BPMN中的活動(Activity)的共同點是都完成了一部分的功能性用戶需求，對等組件可以由多個組件組合而成，活動也可以由多個活動組合而成。從概念上講，對等組件是粗粒度的，完成相對獨立的、較復雜的、有價值的功能。活動既可以完成復雜的功能，也可以完成相對簡單的功能，這與業務功能的“粒度”相關。活動分為流程(Process)、子流程(Sub-process)和任務(Task)，通常在任務中引用Web 服務。對等組件和活動能否直接映射，取決于活動能不能提供一個相對獨立的、復雜的、有價值的功能。若某個子流程或任務不滿足這個條件，那么可以將幾個子流程或任務組合起來形成一個更大的流程，使這個流程能完成一部分功能性用戶需求，從而映射為一個對等組件。
BPMN 中的泳池(Pool)主要用于2 個獨立的實體或者參與者之間的物理劃分，泳池內部是一個流程，一般完成較復雜的業務功能。若泳池所代表的實體是系統內的元素，那么這個泳池可以映射為一個對等組件；若泳池所代表的實體是系統以外的用戶或軟硬件設備，則這個泳池所代表的實體可以映射為一個全功能點的功能用戶。
規則3 全功能點的功能用戶(Function User)除了可以映射為BPMN 的泳池或泳道所代表的實體外，也可以映射為系統外任意與系統交互的事物。因此，若某個活動已經被映射為全功能點的對等組件，則任何與該活動交互的事物都可以映射為全功能點的功能用戶(這個事物可以是另一個活動)。
規則4 全功能點的邊界(Boundary)是功能用戶與待估算軟件的交界處，若2 個泳池交互，其中一個泳池為待估算軟件，另一個泳池為功能用戶，則2 個泳池的交界就映射成邊界。若不存在泳池，則整個業務流程中，被估算的業務流程與其他業務流程交互的界限就是邊界。
規則5 全功能點的事件(Event)與BPMN 中的事件都是觸發一個功能流程或任務的執行。全功能點的事件可以與BPMN 中的消息、時鐘、錯誤、取消、補償、信號等各種事件(Event)相映射。另外，一個任務的結束、序列流(SequenceFlow)、消息流(Message Flow)、網關(Gateway)可以觸發一個任務的執行，也可以與全功能點的事件映射。
規則6 與對等組件的概念相似，全功能點的功能流程(Function Process)也是功能性用戶需求的子集，但功能流程的粒度比對等組件小得多，它通常包含在對等組件中。功能流程通常完成較簡單的功能，可以與BPMN 中任務相映射，若任務的粒度較大，則功能流程可以與任務分解出來的流程相映射，這與任務的粒度是相關的。若任務的粒度較小，則功能流程可以與幾個任務相映射。
規則7 全功能點的數據組(Data Group)與BPMN 中的數據對象(Data Object)都屬于交換的信息，可以映射。另外，只要是2 個事物交換的信息，都可以映射為數據組。
規則8 一般來說，全功能點的數據移動都不能與BPMN中的元素直接映射，要通過分析與任務相映射的功能流程才能得到數據移動。
4.2 估算步驟
基于上述映射關系，本文定義了全功能點估算SOA系統規模的估算步驟作為參考，根據SOA中原子服務與組合服務的關系，將SOA中的業務流程組織成一個圖結構。在BMPN中，設置業務流程中的活動為頂點，頂點的類型主要有3 種：收縮的子流程，擴展的子流程和任務。最終，子流程又可以分為任務。通常在任務中調用Web 服務，Web 服務可以自己開發，也可以調用其他組織提供的服務。估算步驟如下：
步驟1 按表2 的映射規則，識別出BPMN 圖形所表示的層次、對等組件、功能用戶和邊界。
步驟2 對于整個BPMN 圖形，確定其中一部分待估算的BPMN 圖形(通常為一個功能組件及相關功能用戶)，建立圖結構。從某頂點開始遍歷整個圖結構，可以按深度優先遍歷。步驟3 對于每一個頂點，判斷其是子流程還是任務，若該頂點是子流程，重復步驟1、步驟2。
若該頂點是任務，按表1 的映射規則，識別出BPMN 圖形所表示的事件、功能流程、數據組和數據移動。然后按全功能點方法提供的估算規則估算功能點數。
若該任務調用了Web 服務，繼續判斷該Web 服務是自己開發還是調用其他組織提供的服務。若是自己開發，對此Web 服務，重復步驟1、步驟2。
步驟4 待估算的BPMN 圖形的功能點數就是此BPMN圖形所有頂點的功能點總和。
步驟5 回到步驟2，繼續確定剩下的待估算的BPMN 圖形，直到整個軟件估算結束。
5 案例分析
以某實驗室開發的一個商品購物服務(eStore)為例，說明如何使用上述方法估算SOA系統的功能點數。
由于篇幅有限，只能對整個過程進行概要描述。如圖3 所示，eStore 組合了一些已發布的原子服務，并添加一些自己開發的Web 服務，形成一個以各大網站提供的服務為基礎的購物組合服務。這些原子服務包括亞馬遜、eBay 等電子商務公司發布的查詢商品、購買商品的原子服務，包括各大銀行為了方便用戶在網上支付購物費用而開發的相應的Web 服務。
圖3 eStore 的業務流程
按照第4 節定義的映射規則和估算步驟，對eStore 的業務流程的具體估算過程如下：
步驟1 在圖3 中，包含2 個泳道Customer 和eStore。Customer 并不是待開發軟件，所以把eStore 映射為一個功能組件，Customer 映射為功能用戶。eStore 和Customer 都處于同一個層次，eStore 的邊界就是泳池的邊界。
步驟2 確定整個BPMN 圖形為待估算的BPMN 圖，建立圖結構，圖的頂點為任務(Task)圖元，如“查找商品”和“返回結果”等任務。于是從圓圈符號(開始事件)開始，遍歷整個圖結構。
步驟3 首先訪問到“查找商品”和“返回結果”任務，這2 個任務一起映射為一個功能流程。Customer 的“查詢請求”任務映射為觸發該功能流程的事件。根據功能點的計算規則得出這個功能流程共有3 個功能點。“查找商品”任務調用了第三方提供的查找商品服務，這個服務不需自己開發，因此，“查找商品”服務本身的功能點數不用估算。
然后用上述方法繼續遍歷后續任務，直到遇到圓圈符號(結束事件)，于是圖中的全部頂點(任務)就都被訪問了。“生成訂單”和“支付費用”任務調用了第三方提供的服務，“發貨”任務調用了組織內部已有的服務。
步驟4 將Customer 的“登錄”任務也算在內，此BPMN圖所代表的功能點數為31 個。
步驟5 因為步驟2 已經確定了整個BPMN 圖形為待估算的BPMN 圖，無剩余圖形，估算結束。
估算結果表明，開發整個eStore 的業務流程需要的功能點數為31 個，可見，SOA體系結構的采用減小了整個軟件項目的開發規模和工作量。
6 結束語
本文在研究全功能點方法及BPMN 的基礎上，應用了全功能點方法估算SOA系統的規模，從而為SOA系統的規模估算提供一種新的思路。本文不僅定義了全功能點方法到BPMN 的映射規則，給出了全功能點方法估算SOA系統規模的步驟，并且通過一個實例說明這種方法的使用。實踐證明，該方法在SOA系統規模的估算上起到了良好的效果。通過更多的實踐繼續研究全功能點方法及BPMN 的映射關系，從而能夠更精確地估算SOA系統規模，為整個SOA項目估算奠定堅實的基礎。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：全功能點在SOA系統規模估算中的應用
相關文章
