敏捷建模對統一過程的改造實踐
NetReptile推薦 [2005-1-28]
出處：51CMM，CCW
作者：金潔羽
1. 緒論 優良的軟件過程可以為開發高質量的軟件提供有效的實踐方案。隨著軟件開發復雜性的日益增強及軟件行業規范化管理經驗的逐漸積累，通過依托某種軟件過程在開發中產生恰當制品、科 學有效地控制開發節奏與步驟，從而合理調配與使用開發資源、滿足開發愿景，已經成為提高軟件生產率、確保如期按質地提交軟件成果的重要途徑，而這一觀念也正被越來越多的軟件開發公司所認同和采用。 當然，系統最終迭代次數的變更結果取決于太原同城系統的實際部署效果和部署后用戶的意見反饋。 ⑶ 根據數據流圖進行數據建模。 項目組為完成該項設計，專門召集了數據建模會議。會議方式是項目經理組織全體項目成員集體討論，集思廣益。最終討論結果以PowerDesigner為數據建模工具當場記錄和修改，主要涉及庫表結構定義、各數據項定義、表間關系定義、主外鍵定義等內容。不論是在當時的建模會議上，還是以后進行修改時，PowerDesigner在對數據建模結果進行快速修正和記錄方面都體現了強大的功能。 3.2.3太原同城系統的簡單化和目標明確化實踐 當然，太原同城系統的開發實踐還注意了“簡化工作過程”與“明確最終目標”這兩項AM精神的貫徹。比如，建造制品時對UML明確定義的部分制品的舍棄、在類圖的制作過程中僅著重核心類的建模、在各階段建模過程中注意點到為止，使制品量與其對開發的指導價值相匹配……等等，都體現了簡單化的用意。而所有這一切，其實都是為完成最終目標――目標軟件本身而服務的。 筆者認為，這兩方面的實踐雖然相對更加哲學化、抽象化一些，但在開發過程控制中依舊要始終加以留意，使之真正起到指導思想的作用。 4. 總結 綜上所述，對于統一過程而言，敏捷建模是在保持統一過程原有基本優點的前提下，加強這一重量級軟件過程敏捷程度的有效途徑。相信，會有越來越多的統一過程軟件開發實踐將受益于對敏捷建模精髓的汲取，而太原同城系統開發的成功實踐就是其中一個很好的例子。
2. 軟件過程和敏捷建模
經典軟件工程理論所闡述的軟件過程，特別是瀑布模型，由于其較強的理想化環境條件假設，所以如果在實際軟件開發項目中采用，往往會與實際情況產生較大脫節，使得實施效果大打折扣，故而往往只以具有理論參考意義的面孔出現。而當前在業界，既有完整理論，又有較強可操作性的軟件過程，則以統一過程（the Unified Process,簡稱UP）和極限編程（the eXtreme Programming,簡稱XP）最為令人矚目。
2.1 統一過程與極限編程及其思想觀念
2.1.1 UP與XP的特征
統一過程作為一種重量級的指導性的軟件過程，其基本特征體現在用例驅動、以架構為中心、迭代和增量開發等幾方面。根據對統一過程生命周期的不同劃分方法，統一過程還分為企業統一過程（EUP）、Rational統一過程（RUP）等不同子類型。而極限編程則不同于統一過程，它在本質上屬于更為敏捷的一種軟件過程，并由一系列簡單卻互為補充的實踐所組成。
2.1.2 統一過程的優勢
雖然比較XP而言，UP更為傳統一些，其過程控制靈活度也相對較弱，但由于這種軟件過程非常適用于復雜、需求多變、開發難度大的情況，同時也可以根據項目特點進行適當裁剪，所以仍然被許多軟件企業所廣泛采用。特別是，對于一些在軟件過程控制方面依據UP原則已經形成較為固定模式、同時又注重以各階段的指定制品控制開發節奏的公司而言，如何在保持UP基本方法的前提下，提高UP項目開發的敏捷性則是一個非�，F實而重要的課題。
2.2 以敏捷建模改造統一過程的可行性
2.1.3 敏捷建模與統一過程在實踐中的內在聯系
事實上，敏捷建模（Agile Modeling，簡稱AM）所倡導的一系列實踐中有許多做法與UP的實踐是不謀而合的，有的還加強或改進了UP的某些實踐。比如：
UP和AM都強調“項目關系人積極參與”的重要意義，甚至允許項目關系人參與建模。
UP和AM都強調“用代碼驗證”、“并行創建多個模型”。即使是UP，在必要情況下也可調整決定同時執行源于不同規程的活動。
UP和AM都遵循“增量建�！钡膶嵺`，但AM通過減小增量的幅度，改善了UP的迭代實踐。
AM“有危害時才更新模型”的實踐改進了UP及時同步各階段不同制品的要求。
AM“使用合適的制品”的實踐改進了UP對UML建模制品的過分依賴。
AM“集體所有”的實踐改進了UP項目中有關配置管理的觀念，通過營造開放、交流的團隊文化，使所有項目成員都能訪問和修改各自想處理的制品，包括模型和文檔。
AM“使用最簡單的工具”的實踐拓展了UP只注重使用CASE工具的局限。
2.1.4 實踐敏捷建模的主要原則
與UP、XP相比，AM本身則是一種基于實踐的、不完整的、有序與混亂并存的軟件過程。通常，軟件的開發可將UP、XP等作為基礎軟件過程，用AM增強這些更加完整的軟件過程。
AM的概念吸收了敏捷開發聯盟（Agile Software Development Alliance）所倡導的若干原則（限于篇幅，這些條款將不在文中詳述），并形成了自己的一系列原則與實踐�？v觀AM論壇發起人Scott W. Ambler所提出的涉及AM的11條核心原則和13條核心實踐，筆者認為，體現AM精髓的原則主要集中在如下幾個方面：
(1）明確最終目標：即軟件本身才是應當確保的工作目標；
(2）快速迭代反饋：明確各階段問題焦點，快速修訂前一階段過程中的制品，并推回后一階段；
(3）多種模型建模：即要勇于突破傳統軟件過程所規定的建模工具的約束，根據效果特點采用適用的建模模型描述軟件；
(4）簡化工作過程：任何階段都要以最簡單的解決方案來達至工作目標，不要追求形式、不要過度構建軟件。
雖然按照Ambler的觀點，必須完全執行所有11條核心原則和13條核心實踐才能算得上是在敏捷建模，但筆者認為，由于AM本身就是一種不完整的軟件過程，況且AM本身必定會在行業實踐中進一步得到充實，所以可以認為，在目前階段，實踐上面總結出來的四條原則即可基本反映出AM的精髓。
3. 太原同城系統開發中的敏捷建模實踐
在上述方針的指導下，可以利用敏捷建模對統一過程施行改造。以下將以山西省太原市人民銀行同城票據清算系統v2.0（以下簡稱“太原同城系統”）為例，說明應用AM原則與實踐在改造一個UP開發項目過程中的一些體會。
3.1太原同城清算系統介紹
3.1.1開發背景
太原同城系統是在金融體制改革的形勢下，由北京市泰通電子技術公司承擔開發的，在太原市轄區范圍內建設的一個連接該市各個商業銀行和與人民銀行清算中心的票據實時清算系統。通過實時處理貸記、借記票據交換業務，可以改變傳統的票據手工交換方式，以電子流代替票據流，使資金可即時抵用，為各商業銀行提供統一、快捷、安全、可靠的資金清算渠道，也為人民銀行提供了監控資金流量與流向的現代化手段。
3.1.2系統體系結構
太原同城系統是一個基于交易中間件、復合平臺、多語言聯合開發的三層C/S結構系統。其三層架構分別為：
(1）數據層：運行在人行結算中心的數據庫服務器上，OS為TurboLinux Enterprise 8.0，DBMS為Oracle9i Enterprise for linux。
(2）中間層：運行在人行結算中心的應用服務器上，OS為TurboLinux Enterprise 8.0，用C++語言實現了核心商業服務，開發工具選用Borland C++BuilderX 1.0 Enterprise。
(3）表示層：運行在各商業銀行的PC前端機（SCO UNIX 5.05平臺，270臺）及人行結算中心的PC前端機（Win2000/RedflagLinux4.0平臺，5臺）上。商行前端程序用C語言實現；人行前端程序用JAVA語言實現，開發工具選用Borland JBuilder 7 Enterprise。
上述三個層次分別安裝了東方通科技公司的消息中間件TongEASY 4.5 for Linux/SCO UNIX/Windows，整個系統的事務處理功能即由它保證。TongEASY作為一個基于三層C/S體系結構的中間件，其構成的交易管理平臺提供了交易管理、負載均衡、應用調度等功能。其包含的通訊管理模塊還提供了可靠的數據傳輸、網絡監控、流量控制等功能。
3.2太原同城系統開發中的敏捷建模實踐
本人作為太原同城系統的項目經理，按照上文所述觀點，將敏捷實踐中“明確最終目標、快速迭代反饋、多種模型建模、簡化工作過程”這四方面的內容與實際開發的過程控制進行了結合。以下是對其中這幾方面實踐內容的總結。
3.2.1太原同城系統的快速迭代與增量式開發實踐
這一實踐體現了“快速迭蠢 鋇木�。太原同掣[低車幕救砑灘捎肦UP。按照Rational公司對UP的定義，軟件開發的生命周期被劃分為初始、細化、構造、交付四個階段，每個階段結束于定義良好的里程碑――即某些關鍵決策必須做出的時間點。為了更好地控制變更、減少開發風險，太原同城系統的開發遵循了RUP所規定的從一個迭代過程到下一個迭代過程的遞增式增長，從而形成了最終系統。具體而言，這些迭代過程包括：
(1）第一次迭代（歷時一個半月）：
跨越UP所定義的初始階段。該次迭代實現的UP規程主要包括：初步業務建模、捕獲業務需求、建立開發環境等。通過該次迭代，完成了架構方案的確定，實現了部分子系統中最關鍵的業務用例的分析設計與編碼、測試――比如票據發送、票據接收、票據文件生成等。同時，通過測試比較，項目組明確了系統的體系結構，即：立足于基于消息中間件的三層C/S結構系統。此外，還根據上述體系結構的特點，確定了開發語言與開發工具。值得一提的是，該次迭代的初衷并非單純針對太原同城系統，但太原同城系統事實上成為了此次迭代過程的第一個受益者。
(2）第二次迭代（歷時兩個半月）：
跨越了UP所定義的細化階段和構造階段。該次迭代實現的UP規程包括業務建模、需求分析、體系結構設計、編碼實現，它所包括的數次小的迭代過程分別側重于分析、設計和編碼實現。首先，通過本次迭代，基本完成了對所有概要級別用例、用戶級別用例及大部分子功能級別用例的分析，同時，還完成了類設計、基本數據靜態結構設計與數據動態流向設計。系統架構的整體搭建也在此階段完成。之后，在上述架構的基礎上實現了相應的編碼工作。
(3）第三次迭代（歷時兩個半月）：
跨越了UP所定義的構造階段和移交階段。該次迭代實現的UP規程包括補充業務建模、補充需求分析、補充編碼實現、系統測試、運行和支持等。通過該次迭代，完成了對各級別用例的修改、補充，補充完善了各功能模塊的代碼，完成了系統測試和部署準備。
同時，系統在進行某一階段的建模工作時，還注意盡量避免在該階段只專注于一個制品的制作。比如，在用例建模階段，還同時進行了用戶界面原型的設計工作；在數據建模階段，還將設計會議包括進來。
3.2.2太原同城系統的多種模型建模實踐
太原同城系統的過程控制實踐很注重改造系統啟動時組織內部因沿襲UP思維方式而可能存在的不符合AM原則的文化障礙。比如，根據AM“多種模型建�！钡木�，太原同城系統的建模過程就沒有受限于UML規定的若干建模制品。
雖然UML定義了一系列的建模制品，但很顯然，完整創建其定義的所有建模制品是沒有必要的。另一方面，UML建模制品至少在分析需求時并不完備，也存在盲點。比如，UML無法滿足用戶界面建模需求、UML的活動圖無法描述一個信息存儲的位置信息等等。因此，在太原同城系統的開發中對UML制品根據需要進行了取舍。針對UML建模制品的不足，還補充了其它一些制品，包括一些UML問世之前就存在了的建模制品（如數據流圖），甚至包括一些有獨創性的建模制品（如數據流向設計）。下面是太原同城系統分析設計過程中一些制品的制作情況描述：
⑴ 編寫有效用例，透徹描述和分解需求規格說明書中提出的各項功能需求。
比如，對于“中心日初始化”這一功能而言，我們需要清楚地說明人行結算中心在每個工作日業務開始時，日初始化功能涉及到的主執行者、目標、前置條件、觸發條件、主要場景、意外情況處理等細節情況。其有效用例主要部分摘要如下：
“中心日初始化”處理用例
n 主執行者：人行結算中心系統管理員
n 語境中的目標：人行結算中心系統能開始處理稅票信息。
n 級別：用戶目標。
n 項目相關人員和利益：
1. 人行結算中心操作員
2. 人行結算中心業務領導
3. 人行結算中心
n 前置條件：人行結算中心操作員、系統管理員或業務領導登錄成功。
n 觸發事件：人行結算中心系統工作人員登錄成功后開設新工作日。
n 成功保證：人行結算中心新工作日開設成功，并且工作狀態進入日間狀態。
n 最小保證：人行結算中心系統工作人員登錄驗證。
n 主成功場景：
1. 人行結算中心前一工作日日終判斷。
2. 人行結算中心本工作日日初注冊：人行結算中心系統獲取新的工作日日期；人行結算中心該工作日由日初狀態進入日間狀態。
n 擴展：
*a. 任意時刻，系統崩潰：（略）
*b. 任意時刻，網絡連通出現故障：（略）
1a. 結算中心前一工作日日終尚未完成：
繼續進行結算中心前一工作日日終處理，直到日終成功。
1b. 結算中心前一工作日日終已經完成。
繼續進行新一工作日的日初處理。
2. 手工輸入的新工作日日期不符合要求：提示修改工作日日期，直到合格。
n 使用頻率：每個工作日一次
太原同城系統中包括上述用例在內所有用例的設計，其設計風格都與Alistair Cockburn在《Writing Effective Use Cases》一書中推薦的風格相同。其中，下橫線部分是準備繼續擴展描述的下一級用例，為省篇幅本文從略。
這里，應當突破UP聲稱的對用例的認識局限，意識到用例并不足以驅動所有事情。事實上，用例只是全部需求，甚至只是全部功能需求的一部分，對諸如用戶界面需求、商務規則、非功能需求的描述，僅靠系統用例是不夠的，有必要以基本界面原型、界面流程圖、CRC卡等加以補充。
⑵ 針對“概要級別用例”、“用戶級別用例”及“子功能級別用例”使用數據流圖進行逐層分析，了解各用例所涉及的數據源點與匯點之間的關系。
通過數據流分析這種傳統的分析手段，我們可以匯總出數據字典，并作為靜態數據結構設計的依據。下面的數據流圖實例就是太原同城系統中針對用戶級別用例――“實時提出”所做的分析。依托數據流圖，“實時提出”功能所涉及到的各個數據存儲、各個數據源點和終點、各個加工都一目了然。 
在UML中，數據模型并沒有很好的建模制品進行表達，但我們有必要提供數據模型制品，并為后面諸如數據庫表靜態結構設計、UML類圖設計等工作做準備。以下展示的，就是人行結算中心數據建模工作的一小部分結果。 
⑷ 參照靜態數據結構、數據流圖、用例描述獲得數據流向設計圖。
這一獨創的制品具有與UML時序圖異曲同工的效果。但如此表達更符合程序員的編碼習慣，更有利于實現從偽代碼到真實代碼的轉化。至于設計范圍，主要依據用例描述來確定。以下是“中心日初始化”這一子功能級別用例的數據流向設計實例：
“中心日初始化”數據流向
查詢系統運行控制表
if 有記錄
{
定位到工作日期最晚的一條記錄
if 工作狀態 <> 0<日終>
{
退出日初始化處理
}
手工選擇工作日期 ××××-××-××
判斷該日的記錄是否已經存在
if 存在
{
提示并退出日初處理
}
判斷該日是否小于庫中的最大日期
if 小于
{
提示并退出日初處理
}
在系統運行控制表寫入一條記錄（手工選擇工作日期 ××××-××-××工作狀態1<日初>；工作場次1；是否平帳0<未清算>）
清空業務庫表：網點日提出票據表、網點日提入票據表、網點日提入錯誤票據表、網點磁盤日待提入票據表、網點磁盤日提入登記表、網點日清算表、清算行日清算表、管轄行日清算表、清算帳戶日清算表
更新網點狀態權限表所有記錄的網點日對帳標記為0<未對帳>，提入流水號為1
更新網點統計監控表所有記錄的提出筆數、清分筆數、提入筆數、出錯筆數為0；場次為1；通信狀態為0<斷開>
行號表是否需更新：
從版本控制表中查詢>當前行號表版本號的記錄，如果有記錄，依次判斷該記錄的生效日期是否到期
if 有到期記錄
{
備份當前行號表到備份行號表
更新行號表
更新網點狀態權限表、網點統計監控表
修改系統運行控制表的當前行號表版本號
}
在系統運行控制表中修改記錄（工作日期 ××××-××-××工作狀態2<日間>；工作場次1；是否平帳0<未清算>）
}
else
{
手工選擇工作日期 ××××-××-××
在系統運行控制表寫入一條記錄（手工選擇工作日期 ××××-××-××工作狀態2<日間>；工作場次1；是否平帳0<未清算>）
}
在數據流向設計中，總的設計方式是參照流程順序和時間順序。其中，橫線部分是此制品涉及到的數據庫表。對相應庫表的重要改動內容也同時記錄在旁邊，狀態字段的內容改動其含義記錄在“< >”中。
可見，通過上述各環節的分析設計工作，系統的制品已大大突破了UML所定義的制品范圍。雖然這其中所完成的基本界面原型設計、界面流程圖等制品尚未加以羅列，事實上其存在與制作對于系統的透徹分析是很有必要的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
