一種雙論域層次化軟件建模框架與實踐

楊德仁，王曉峰，韓 強，劉建平，周玉璽

（1.寧夏醫科大學理學院，寧夏銀川 750004；2.北方民族大學計算機科學與工程學院，寧夏銀川 750021）

0 引言

在軟件開發早期，應用場景簡單，身兼軟件用戶的軟件開發者熟悉業務，因此軟件開發難度較低，主要涉及編碼和調試。隨著應用范圍的拓展，軟件走向商業化和復雜化發展趨勢，軟件工程學科隨即問世，標志著軟件成為社會生產的基本角色。軟件開發逐漸獨立于業務，導致軟件開發者與軟件用戶隔閡，造成難以逾越的開發鴻溝。開發者往往狹隘地關注軟件開發，難以與待建軟件目的完全契合。軟件工程的問世旨在解決軟件復雜性導致的軟件危機問題，但在軟件工程問世50 年之際，諸如軟件本質復雜性［1］等困擾已久的難題仍未解決。

隨著信息技術的普及，軟件涉及的業務及其運營環境越來越復雜，使軟件本質復雜性不斷加強。軟件本質復雜性源于業務過程復雜性，它是不可避免的，需通過推遲實施得以解決［2］，其機制是在軟件過程中的層次化建模［3］。隨著軟件方法和技術的進步，軟件方法學呈現多樣化趨勢，這引起軟件過程中的“被復雜化”問題，相關過程性建模也需進一步規范以便實踐［3］。正如軟件設計大師Booch［4］所言，“軟件工程歷史就是提升抽象層次的歷史”。

2 軟件建模及其論域

為解決軟件本質復雜性問題，軟件過程從程序設計逐步向上抽象，歷經軟件分析、軟件需求乃至業務建模［3-5］。其中，軟件分析域獨立和業務域回歸顯得尤為重要。

2.1 分析域

軟件過程本質需求是實施軟件建模。后者源于結構化編程設計并與編程語言范式密切相關［6］。在結構化方法中，采用程序流程圖描述算法；概要設計旨在描述軟件功能結構層次；結構化分析旨在通過分解業務域中的數據及其處理過程，找出最小數據處理單元與相關輸入數據和輸出數據，得到數據流模型，再把數據流模型中的“處理”單元映射到軟件各功能層次結構上。

在面向對象的方法中，對象發現與精化是軟件分析和設計難點和主要任務。早期使用數據流圖描述軟件需求。用例技術問世后，隨即被用來描述軟件需求，隨著在用例中尋找對象的技術不斷涌現，分析活動從軟件需求中分離出來，并以“魯棒分析”著稱［7］，這體現在面向對象軟件工程（OOSE）中。在設計層面，用類圖描述軟件靜態結構，用序列圖描述軟件動態交互機制，它們是編碼基礎。軟件工程知識體系（SWEBOK）包括軟件需求、軟件設計（含軟件架構）、軟件工程過程和軟件工程模型與方法等［8］。

這種軟件過程范式以抽象和建模為核心理念，但因沒有顧及和利用業務域知識，容易導致“設計麻痹”問題。軟件分析演化歷程如表1 所示。

Table 1 Evolution of software analysis表1 軟件分析演化歷程

2.2 業務域

20 世紀90 年代，軟件工程學科進入快速發展期，若干舉足輕重的軟件方法先后問世。針對軟件本質復雜性問題，學術界和業界先后啟動了業務域建模，諸如需求工程、軟件架構（體系結構）、域工程、模型驅動的軟件工程和領域驅動的設計等。

MDA 提倡模型及其轉化以形成體系結構，進而促進模型轉化；論域（平臺）及其資源是軟件建模基礎［9］，相關著名的模型有計算無關的模型（CIM）、平臺無關模型（PIM）和平臺相關模型（PSM）。Dines［5］的“三段論”把軟件工程分為域工程、需求工程和軟件設計，旨在解決軟件需求的無源之困局。領域驅動的設計則認為（業務）域模型是軟件設計前驅［10］。軟件方法中的業務域建模如表2 所示。

Table 2 Business domain modeling in software method表2 軟件方法中的業務域建模

業務域建模是業務過程管理的必備手段，更是軟件域建模基礎，這是學界和業界的共識，如國際對象管理組織倡導和規范了業務域建模系列語言［9］。

3 雙論域多層次軟件建模

基于MDA 理念，軟件設計指基于論域（平臺）的建模和模型轉化過程［9］。論域不同，其元素和關系（即結構）不同。基于軟件過程模型、軟件方法學和軟件模型三維視角，軟件建模一般按4 個論域逐級實施［3］，即業務域、軟件需求域、軟件分析域和軟件設計域，如表2 所示。但這種四論域尚待細化，僅籠統地處理業務域是不可行的。

3.1 一種雙論域層次化軟件建模框架

業務過程痕跡用業務信息單據（即信息子）記錄。而軟件旨在支持業務運行，以處理業務域信息子為主。因此，設計軟件需基于并滿足業務域中的信息子處理要求。

根據米勒魔數定律，業務過程中的業務動作、業務對象和信息子等建模單元數量超出了人類大腦工作區容量，因此需通過探索業務實施路徑從而抽象化處理。業務域建模應如同軟件域建模，也歷經目標、途徑到過程的層次化進程。雙論域層次化軟件建模框架（Hierarchical Soft?ware Modeling Framework in Di-domain，HSMFD）如圖1 所示。根據HSMFD 框架，以面向對象范式為例，分別對軟件設計途徑與實踐集進行闡述。

Fig.1 Hierarchical software modeling framework in di-domain圖1 基于雙論域的層次化軟件建模框架

3.2 業務域建模機制與實踐集

在業務域中，業務是為客戶服務的，滿足客戶需求和提高客戶滿意度是業務服務提供者首要目標。因此，業務域建模首當其沖，這需要設計和提供業務服務機制，即業務過程。其建模機制包括：①業務過程實施需要人力和其它資源，諸如業務對象和信息子；②在業務目標層，客戶若有需求，業務服務提供者即有響應，用UML 用例圖為其建模；③在業務途徑層，用抽象的UML 活動圖為業務實施途徑建模。業務實施途徑可通過業務參與者所做的事務確定［11］；④在業務過程層，用UML 活動圖為業務過程中的業務動作、業務對象和信息子及其順序建模，并提取該模型中的參與者、業務對象和信息子形成業務對象模型，用UML 類圖表示，以備在軟件域建模中重用［11］；⑤業務域建模實踐集包括客戶參與、業務途徑探索和業務過程建模［6］。

信息子演變歷程包括：①基于客戶需求，探索滿足該需求的各種實施途徑即業務actor 的業務事務；②分解業務事務以得到業務動作；③明確各業務動作輸入信息子和輸出信息子［11］；④得到業務信息子模型。

業務對象演變歷程類似于信息子演變歷程［11］，各業務動作也有輸入對象和輸出對象，從而得到業務對象模型。

3.3 軟件域建模機制與實踐集

3.3.1 建模機制

軟件需求基于業務域的信息子處理，即軟件功能需求或用戶需求。用戶需求是宏觀的，與設計層次軟件基本單元（類）及其對象的交互尚有距離，需探索和橋接這種差距，可借助于用例規約和魯棒圖實施［7］。其建模機制如下：

（1）在軟件需求層，分別用UML 用例圖表示用戶信息子處理即功能需求模型，用Axure 建立GUI 原型以獲取業務對象的屬性，用UML 類圖表示靜態模型原型。

（2）在軟件分析層，分解上述功能需求模型，找出另一個軟件對象即控制對象，按照用例規約和UML 魯棒圖分別為程序執行順序和類圖原型建模［12］，并通過添加控制對象優化靜態模型。

（3）在軟件設計層，基于上述程序執行順序原型，用UML 順序圖為業務對象確定方法［13］，優化上述靜態模型。除此外，還需用流程圖為類的方法建模，用實體聯系圖（ERD）為數據建模［14-15］。

3.3.2 實踐集

軟件域建模實踐集有信息子處理及其整合、用戶與軟件交互路徑探索、類的優化、算法設計和數據建模等［6］。

軟件對象交互模型變歷程包括：基于用戶的信息子處理需求，在軟件分析域以用例規約中的“事件流”探索人機交互序列；在軟件設計域基于對象交互即發送和相應“消息”用序列圖將軟件的二級控制對象轉換為目標對象的方法。

軟件類的演變歷程如下：基于業務對象，在軟件需求域探索人機交互界面（GUI）以找出業務對象的屬性；得到靜態模型原型；在軟件分析域找出軟件的一級控制對象和二級控制對象，更新靜態模型；在軟件設計域用序列圖將上述二級控制對象轉換為相關業務對象的方法，更新靜態模型便得到軟件的靜態模型。

數據庫表模式設計則基于上述的軟件靜態模型，用實體聯系圖（ERD），其中實體源于靜態模型中的業務對象，聯系則是業務對象之間的關系和信息子。

3.4 兩種域建模比較

業務域模型是軟件域模型基礎，其建模機制相似而粒度不同，可從3 方面進行比較：

①層次不同性：軟件域位于業務域中的業務過程層次，旨在支持業務過程；②機制相似性：兩者均具有3 個層次，即目標層、途徑層和實施過程層；③運行相關性：以信息子處理為紐帶，業務域建模是基礎，軟件域建模是對業務的支持。

3.5 軟件復雜性問題解決機制

軟件本質上服務于業務，業務域建模是軟件域建模的基礎。如前文所述，軟件的本質復雜性源于業務過程的復雜性，它是不可避免的，需通過推遲實施得以解決［2］。

業務域不同于軟件域，但其邏輯實施又相似于軟件域，即從業務目標到業務實施（即業務過程）也不可一蹴而就。換而言之，業務也具有偶然復雜性。

基于軟件四論域（即業務域、需求域、分析與和設計域）建模實踐框架［4，6］，本文提出的HSMFD 框架進一步區分了業務域和軟件域，同時也對業務域實施層次化建模。

借助于MDA 模型及其轉化理念［9］，通過分論域層次化建模機制，可有效避免業務本質復雜性和軟件本質復雜性過早顯現的問題［2］；借助于MDA 模型及其轉化理念［9］，通過分論域層次化建模及其機制和實踐集，有效規范了業務建模過程和軟件建模過程，從而可解決因影響因素繁多而導致的業務偶然復雜性問題與軟件偶然復雜性問題［4］。

4 結語

軟件需求是軟件開發的基礎，但用戶對軟件的需求往往多變，難以確定，加上市場競爭因素影響，軟件需求變化性是業界常態。

在迭代開發基礎上，敏捷開發旨在組建業務（用戶）代表全程參與的敏捷團隊以擁抱需求變化，敏捷框架已成為軟件開發主流技術，旨在為用戶提供最大價值。而敏捷實踐存在模型層次不明晰或縮水現象，混淆了不同論域的元素，超越了人類理解問題和解決問題的極限，違背了抽象和層次化設計原理，增加了軟件過程中的人為隱患性，難免陷入“大泥球”風險。

目前，知名的IT 國際咨詢公司都在進行敏捷與傳統方法融合實踐的探索和推廣。面向對象技術先驅Ivar Jacob?son 及其雅各布森國際為客戶提供基于用例的敏捷教練、敏捷咨詢和敏捷訓練等企業級軟件開發融合實踐指導［16］。責任驅動設計發明者Rebecca 及其Wirfs Brock 協會也在推廣基于責任驅動設計的敏捷架構、設計啟發和實用性軟件設計技術。軟件開發傳統過程與敏捷框架的融合之道是值得深入探索的研究方向。