一種雙論域?qū)哟位浖？蚣芘c實(shí)踐

楊德仁，王曉峰，韓 強(qiáng)，劉建平，周玉璽

（1.寧夏醫(yī)科大學(xué)理學(xué)院，寧夏銀川 750004；2.北方民族大學(xué)計(jì)算機(jī)科學(xué)與工程學(xué)院，寧夏銀川 750021）

0 引言

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

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

2 軟件建模及其論域

為解決軟件本質(zhì)復(fù)雜性問題，軟件過程從程序設(shè)計(jì)逐步向上抽象，歷經(jīng)軟件分析、軟件需求乃至業(yè)務(wù)建模［3-5］。其中，軟件分析域獨(dú)立和業(yè)務(wù)域回歸顯得尤為重要。

2.1 分析域

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

在面向?qū)ο蟮姆椒ㄖ校瑢ο蟀l(fā)現(xiàn)與精化是軟件分析和設(shè)計(jì)難點(diǎn)和主要任務(wù)。早期使用數(shù)據(jù)流圖描述軟件需求。用例技術(shù)問世后，隨即被用來描述軟件需求，隨著在用例中尋找對象的技術(shù)不斷涌現(xiàn)，分析活動從軟件需求中分離出來，并以“魯棒分析”著稱［7］，這體現(xiàn)在面向?qū)ο筌浖こ蹋∣OSE）中。在設(shè)計(jì)層面，用類圖描述軟件靜態(tài)結(jié)構(gòu)，用序列圖描述軟件動態(tài)交互機(jī)制，它們是編碼基礎(chǔ)。軟件工程知識體系（SWEBOK）包括軟件需求、軟件設(shè)計(jì)（含軟件架構(gòu)）、軟件工程過程和軟件工程模型與方法等［8］。

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

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

2.2 業(yè)務(wù)域

20 世紀(jì)90 年代，軟件工程學(xué)科進(jìn)入快速發(fā)展期，若干舉足輕重的軟件方法先后問世。針對軟件本質(zhì)復(fù)雜性問題，學(xué)術(shù)界和業(yè)界先后啟動了業(yè)務(wù)域建模，諸如需求工程、軟件架構(gòu)（體系結(jié)構(gòu)）、域工程、模型驅(qū)動的軟件工程和領(lǐng)域驅(qū)動的設(shè)計(jì)等。

MDA 提倡模型及其轉(zhuǎn)化以形成體系結(jié)構(gòu)，進(jìn)而促進(jìn)模型轉(zhuǎn)化；論域（平臺）及其資源是軟件建模基礎(chǔ)［9］，相關(guān)著名的模型有計(jì)算無關(guān)的模型（CIM）、平臺無關(guān)模型（PIM）和平臺相關(guān)模型（PSM）。Dines［5］的“三段論”把軟件工程分為域工程、需求工程和軟件設(shè)計(jì)，旨在解決軟件需求的無源之困局。領(lǐng)域驅(qū)動的設(shè)計(jì)則認(rèn)為（業(yè)務(wù)）域模型是軟件設(shè)計(jì)前驅(qū)［10］。軟件方法中的業(yè)務(wù)域建模如表2 所示。

Table 2 Business domain modeling in software method表2 軟件方法中的業(yè)務(wù)域建模

業(yè)務(wù)域建模是業(yè)務(wù)過程管理的必備手段，更是軟件域建模基礎(chǔ)，這是學(xué)界和業(yè)界的共識，如國際對象管理組織倡導(dǎo)和規(guī)范了業(yè)務(wù)域建模系列語言［9］。

3 雙論域多層次軟件建模

基于MDA 理念，軟件設(shè)計(jì)指基于論域（平臺）的建模和模型轉(zhuǎn)化過程［9］。論域不同，其元素和關(guān)系（即結(jié)構(gòu)）不同?；谲浖^程模型、軟件方法學(xué)和軟件模型三維視角，軟件建模一般按4 個論域逐級實(shí)施［3］，即業(yè)務(wù)域、軟件需求域、軟件分析域和軟件設(shè)計(jì)域，如表2 所示。但這種四論域尚待細(xì)化，僅籠統(tǒng)地處理業(yè)務(wù)域是不可行的。

3.1 一種雙論域?qū)哟位浖？蚣?/h3>

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

根據(jù)米勒魔數(shù)定律，業(yè)務(wù)過程中的業(yè)務(wù)動作、業(yè)務(wù)對象和信息子等建模單元數(shù)量超出了人類大腦工作區(qū)容量，因此需通過探索業(yè)務(wù)實(shí)施路徑從而抽象化處理。業(yè)務(wù)域建模應(yīng)如同軟件域建模，也歷經(jīng)目標(biāo)、途徑到過程的層次化進(jìn)程。雙論域?qū)哟位浖？蚣埽℉ierarchical Soft?ware Modeling Framework in Di-domain，HSMFD）如圖1 所示。根據(jù)HSMFD 框架，以面向?qū)ο蠓妒綖槔?，分別對軟件設(shè)計(jì)途徑與實(shí)踐集進(jìn)行闡述。

Fig.1 Hierarchical software modeling framework in di-domain圖1 基于雙論域的層次化軟件建?？蚣?/p>

3.2 業(yè)務(wù)域建模機(jī)制與實(shí)踐集

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

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

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

3.3 軟件域建模機(jī)制與實(shí)踐集

3.3.1 建模機(jī)制

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

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

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

（3）在軟件設(shè)計(jì)層，基于上述程序執(zhí)行順序原型，用UML 順序圖為業(yè)務(wù)對象確定方法［13］，優(yōu)化上述靜態(tài)模型。除此外，還需用流程圖為類的方法建模，用實(shí)體聯(lián)系圖（ERD）為數(shù)據(jù)建模［14-15］。

3.3.2 實(shí)踐集

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

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

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

數(shù)據(jù)庫表模式設(shè)計(jì)則基于上述的軟件靜態(tài)模型，用實(shí)體聯(lián)系圖（ERD），其中實(shí)體源于靜態(tài)模型中的業(yè)務(wù)對象，聯(lián)系則是業(yè)務(wù)對象之間的關(guān)系和信息子。

3.4 兩種域建模比較

業(yè)務(wù)域模型是軟件域模型基礎(chǔ)，其建模機(jī)制相似而粒度不同，可從3 方面進(jìn)行比較：

①層次不同性：軟件域位于業(yè)務(wù)域中的業(yè)務(wù)過程層次，旨在支持業(yè)務(wù)過程；②機(jī)制相似性：兩者均具有3 個層次，即目標(biāo)層、途徑層和實(shí)施過程層；③運(yùn)行相關(guān)性：以信息子處理為紐帶，業(yè)務(wù)域建模是基礎(chǔ)，軟件域建模是對業(yè)務(wù)的支持。

3.5 軟件復(fù)雜性問題解決機(jī)制

軟件本質(zhì)上服務(wù)于業(yè)務(wù)，業(yè)務(wù)域建模是軟件域建模的基礎(chǔ)。如前文所述，軟件的本質(zhì)復(fù)雜性源于業(yè)務(wù)過程的復(fù)雜性，它是不可避免的，需通過推遲實(shí)施得以解決［2］。

業(yè)務(wù)域不同于軟件域，但其邏輯實(shí)施又相似于軟件域，即從業(yè)務(wù)目標(biāo)到業(yè)務(wù)實(shí)施（即業(yè)務(wù)過程）也不可一蹴而就。換而言之，業(yè)務(wù)也具有偶然復(fù)雜性。

基于軟件四論域（即業(yè)務(wù)域、需求域、分析與和設(shè)計(jì)域）建模實(shí)踐框架［4，6］，本文提出的HSMFD 框架進(jìn)一步區(qū)分了業(yè)務(wù)域和軟件域，同時(shí)也對業(yè)務(wù)域?qū)嵤哟位！?/p>

借助于MDA 模型及其轉(zhuǎn)化理念［9］，通過分論域?qū)哟位C(jī)制，可有效避免業(yè)務(wù)本質(zhì)復(fù)雜性和軟件本質(zhì)復(fù)雜性過早顯現(xiàn)的問題［2］；借助于MDA 模型及其轉(zhuǎn)化理念［9］，通過分論域?qū)哟位＜捌錂C(jī)制和實(shí)踐集，有效規(guī)范了業(yè)務(wù)建模過程和軟件建模過程，從而可解決因影響因素繁多而導(dǎo)致的業(yè)務(wù)偶然復(fù)雜性問題與軟件偶然復(fù)雜性問題［4］。

4 結(jié)語

軟件需求是軟件開發(fā)的基礎(chǔ)，但用戶對軟件的需求往往多變，難以確定，加上市場競爭因素影響，軟件需求變化性是業(yè)界常態(tài)。

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

目前，知名的IT 國際咨詢公司都在進(jìn)行敏捷與傳統(tǒng)方法融合實(shí)踐的探索和推廣。面向?qū)ο蠹夹g(shù)先驅(qū)Ivar Jacob?son 及其雅各布森國際為客戶提供基于用例的敏捷教練、敏捷咨詢和敏捷訓(xùn)練等企業(yè)級軟件開發(fā)融合實(shí)踐指導(dǎo)［16］。責(zé)任驅(qū)動設(shè)計(jì)發(fā)明者Rebecca 及其Wirfs Brock 協(xié)會也在推廣基于責(zé)任驅(qū)動設(shè)計(jì)的敏捷架構(gòu)、設(shè)計(jì)啟發(fā)和實(shí)用性軟件設(shè)計(jì)技術(shù)。軟件開發(fā)傳統(tǒng)過程與敏捷框架的融合之道是值得深入探索的研究方向。