文/蔣丹 劉永吉
敏捷開發是一種以用戶的需求進化為核心,采用迭代、循序漸進的方法進行軟件開發的方法。近年來,敏捷開發方法運用越來越普遍,許多公司(如IBM、Google等)紛紛采用了敏捷開發方法。Ansgar等闡明,敏捷開發方法以其精益開發、簡單可靠、增量快速交付等特征,得到了軟件業界的廣泛關注。同時,在全球大背景下,IT行業軟件開發中由于子系統數量不斷增長、功能模塊增長、邏輯任務增長、子系統耦合度提高等問題,導致軟件開發需要高可讀性和高可復用性,必然需要軟件向基于模型的敏捷架構靠攏。
本文根據敏捷開發理論,研究面向模型的敏捷架構設計方法。從架構設計方法的角度,首先,分析了傳統軟件架構開發中的弊端;其次,分析了基于模型的軟件架構技術;最后,將敏捷開發與基于模型的軟件架構方法結合,提出了一種基于模型的敏捷架構設計方法。

表1:基于文檔的軟件工程與基于模型的軟件工程設計元素對比
傳統的軟件開發一般采用瀑布模型,瀑布模型將開發和交付企業軟件項目的流程分割為相互獨立的階段,每個階段都要完成規定的文檔。架構設計方面,瀑布模型的支持者主張大設計前置(BDUF),這也是眾多計劃驅動軟件開發方法論的普遍做法。如圖1所示。
由于,傳統的軟件架構設計是根據所有的需求文檔設計出的大型架構,使得其傳統系統分析與設計方法都不能很好地適應不斷變化的環境。雖然傳統軟件開發方法已經被軟件界人士所認可,但這也無法掩蓋傳統軟件開發方法存在的問題和弊端,比如,不能保證軟件質量,軟件開發周期長,軟件可靠性、可擴展性和可重用性不能良好體現等。同時,傳統的軟件開發也是一種基于文檔的開發。通過產生的需求文檔、設計說明文檔等,進行代碼的編寫,這種基于文檔的開發,不僅會照成工作量大、人力資源無法保證文檔的維護,而且手工編碼引入了人為錯誤,開發效率低下,設計與現實脫節,無法保證文檔與代碼的一致性,最重要的是,基于文檔的傳統開發中的需求無法進行仿真驗證,錯誤只能放在后期發現,代價極大。最重要的是,容易造成架構的浪費以及不可變。

圖1:軟件開發中軟件架構的一般過程
基于模型的技術是采用面向對象的設計方法,基于系統建模語言SYSML的建模機制對系統的行為和架構進行設計與分析,與軟件工程思想一脈相承。見表1。
如圖2所示,基于模型的軟件開發結構的核心是基于抽象。通過規范化的建模語言和方法消除傳統方法的缺陷。開發人員可以通過建模語言和方法掌握進行模型的建立、并對模型進行驗證。基于模型不等同于基于圖形或者基于工具,它是方法論和思維方式的升華,要行之有效的全面推行,就要使得廣大設計人員正確認識它。從時間占比上,基于模型的開發方法在前期會占用大量的時間,因此,需要整個研制體系、上下游都理解并適應這種方法帶來的影響和改變。
敏捷軟件開發是一種從1990年代開始逐漸引起廣泛關注的一種新型的以人為核心、迭代、循序漸進的開發方法,它的核心思想在于快速、增量式的交付可工作的軟件。在敏捷軟件開發中,軟件項目被分解成多個子項目,各個子項目的成果都經過測試,具備可視、可集成和可運行可使用的特征,經多次迭代來完成,每次迭代都有明確的目標并能快速交付可運行的軟件。
如圖3所示,敏捷開發與傳統軟件開發的不同之處在于,傳統的軟件開發需要將所有的軟件需求進行整合,對所有需求統一進行需求分析,軟件設計,代碼編寫和測設;而敏捷開發的特點在于對當前需求進行需求分析,軟件設計,代碼編寫和測試,按此步驟依次迭代每個需求,直到所有需求均被迭代完畢。

圖2:基于模型的軟件工程

圖3:傳統開發與敏捷開發過程差異

圖4:敏捷開發前和敏捷開發后的架構設計方法
在傳統軟件開發中,需求分析階段規劃好大量的功能需求和非功能需求,架構師針對這些需求進行整合后進行架構設計。架構設計是同時完成分析和設計兩項工作。而在敏捷開發中,需求是迭代式進行收集,每次迭代進行設計時,僅僅對當前的需求進行建模,會隨著每次迭代的進行,逐步調整架構設計。所以,可以看出傳統軟件架構和敏捷方法之間的緊張關系(沿著最后可能的時刻留下架構決策)與預期(提前規劃)之間的緊張關系。
同時沃特曼,諾貝爾和艾倫探討了在設計前期架構時花費太少時間,增加風險和花費太多時間,對客戶價值交付產生負面影響之間的緊張關系。他們確定了可能影響敏捷架構的六種力量:需求不穩定性,技術風險,早期價值,團隊文化,客戶敏捷性和經驗。這些力量可以通過六種策略來解決:響應變化,解決風險,新興架構,預先設計大型設計以及使用框架和模板架構。敏捷架構原則通過協作,緊急設計,有意架構,設計簡單性以及可測試性,可部署性和可釋放性設計來支持精益敏捷開發。快速原型設計,領域建模和分散式創新進一步支持了它。軟件架構設計描述的是事物本身,而敏捷開發描述的是創建這個事物的過程;敏捷開發中架構設計的方式,指什么時候進行架構設計,并以什么樣的方式進行架構設計。
圖4中,敏捷開發后軟件架構設計的方式產生了變化;敏捷開發把原先軟件過程前期的架構設計,分散到了整個敏捷開發軟件過程中。
看到敏捷開發中分散化的架構設計,想起公司財務中的“馬克威茨資產組合理論”,用馬克威茨資這個諾貝爾大師的理論來解釋敏捷開發中的分散架構形式,也行得通。“馬克威茨資資產組合理論”中說道:可以通過分散投資使收益率不變而方差(風險)減少。通俗一點講也就是不要把雞蛋放在一個籃子里。
如果按照資產組合理論,下面這些就是軟件架構設計中的組合,把一次性軟件過程前期30%(甚至更多)的架構設計,換成如下的軟件組合:
(1)引入新需求后的架構。每次迭代中,新需求引入前,都可以進行構思和架構;
(2)重構產生架構。先讓軟件運行,再重構其代碼。那么軟件的架構隨著重構自然而然的在軟件過程中產生;
(3)開發過程中的設計:以前是設計完后開發,現在是邊設計邊開發;
(4)所以敏捷開發不是輕架構設計,而是依然注重架構設計。只不過架構的方式變化了,變得更加有效且風險更小。

圖5:敏捷開發中迭代式架構設計過程
在數字化轉型的大趨勢下,基于模型是走向設計的技術保證,而選擇敏捷結構設計方法是追求速度與質量平衡。在基于模型的開發工程中,傳遞的是模型而不再是文檔,基于模型在軟件實現前可以而且應該更好地與客戶溝通、確認需求。同時,大量的模型驗證工作在軟件實現前可以而且應該得以展開。
重構是敏捷開發的重要技術,就是在不改變軟件現有功能的基礎上,通過調整程序代碼改善軟件的質量、性能,使其程序的設計模式和架構更趨合理,提高軟件的擴展性和維護性。本文將利用重構技術來進行架構設計,如圖5所示描述了敏捷開發中迭代式架構設計過程。敏捷開發中進行架構設計的核心思想是進化式設計。進化式的設計是指在敏捷開發的整個生命周期中,通過每一次迭代來充實、修改和優化設計方案,以使其最大限度地符合客戶對系統的需求。它是不傷害到現有架構的能力和已經實現的功能,同時對其他部分的影響盡可能小。
在基于模型的敏捷架構設計中,每一次迭代的架構設計過程大概分為八個步驟:
(1)需求分析階段,通過周期性收集用戶的業務需求,使用Doors工具進行軟件需求分析與管理,生成軟件高層需求文檔,形成Product Backlog列表;
(2)在Visual Studio2010(或其他工具)中,將Product Backlog列表分解成一個個用戶故事(對單一功能實現的描述),用戶故事有三個參照值:Stack Rank(優先級)、Story Point(實現難度、工作量)、Risk(風險);
(3)團隊一起將每一個用戶故事進行細化成一個個Task。團隊成員領取Task進行開發;
(4)在整個項目開發生命周期內,需要對需求訂單進行不斷維護,同時也要對需求變更進行管理與跟蹤。
(5)采用SCADE Suite、SCADE Display進行軟件設計,開發軟件低層需求,建立高層需求與低層需求的追蹤關系;
(6)根據需求模型,軟件詳細設計階段采用SCADE Suite、SCADE Display進行軟件控制邏輯和人機交互設計,并通過需求追蹤管理工具建立模型與需求之間的追蹤關系。形成當前迭代的Architecture Backlog,確定項目系統中某模塊的架構樣式,明確每層需要的技術;
(7)每次迭代根據Architecture Backlog實現的功能,通過使用IBM rational rhapsody工具畫時序圖等;
團隊開發成員、架構師、產品負責人以及測試組相關成員參加架構設計評審,評審通過后進入開發階段,以正確的起到指引、框定的作用,使得開發朝著正確的方向進行。
基于模型的敏捷架構是一種精益敏捷方法,可以解決構建企業解決方案的復雜性。反過來,基于模型的敏捷架構設計方法支持當前用戶的需求,同時改進系統以滿足近期的未來需求。這種方法允許系統架構(甚至是大型解決方案)隨著時間的推移而發展,同時支持當前用戶的需求。 這避免了與啟動 - 停止 - 啟動性質相關的開銷和固有的重新設計。借助敏捷架構,系統始終運行,支持更持續的價值流。同時,能夠避免系統過載,該模型構成經濟框架的一部分并幫助分散決策,這兩者對于快速,可持續的價值流動至關重要。
對于傳統開發中不能很好的適應不斷變化的環境,架構的可擴展性和可重用性不良好,以及隨著應用程序的擴展和時間的推移,內核的體量往往會開始成為沉重負擔,本文提出了一種基于模型的敏捷架構設計方法,該方法不僅開發節約了時間成本,并且提了軟件產品質量。在未來的相關研究中,我們會將面向模型的敏捷架構等方面推廣到更大的項目中,并進一步完善該方法。