馮 毅 天津市信息中心應(yīng)用開發(fā)處 300040

OSGI規(guī)范對(duì)增量式開發(fā)模型的支持探究

馮 毅 天津市信息中心應(yīng)用開發(fā)處 300040

OSGI（Open Services Gateway Initiative）提供了規(guī)范化的模塊劃分，低耦合的模塊間關(guān)系，統(tǒng)一的模塊開發(fā)方式，可動(dòng)態(tài)插拔的模塊管理環(huán)境。這些特性都適合搭建需求復(fù)雜多變的應(yīng)用系統(tǒng)架構(gòu)。本文在對(duì)幾種增量式開發(fā)模型進(jìn)行分析的基礎(chǔ)上，從OSGI規(guī)范對(duì)增量式開發(fā)模型的支持展開探討。

OSGI；增量式開發(fā)；服務(wù)

1 前言

隨著信息系統(tǒng)應(yīng)用領(lǐng)域的發(fā)展，應(yīng)用環(huán)境日趨復(fù)雜，應(yīng)用模式變化迅速。為了解決復(fù)雜多變環(huán)境中，軟件開發(fā)跟不上需求變化的問題，需要設(shè)計(jì)一套既適合復(fù)雜應(yīng)用環(huán)境又具有良好擴(kuò)展能力的軟件框架。OSGI帶來了什么？從需求實(shí)現(xiàn)方面，OSGI為動(dòng)態(tài)擴(kuò)充、修改系統(tǒng)功能和改變系統(tǒng)行為提供了支撐，而在傳統(tǒng)的開發(fā)方式下，要實(shí)現(xiàn)系統(tǒng)的動(dòng)態(tài)擴(kuò)充、修改以及改變是一件很麻煩的事；從技術(shù)角度方面，OSGI帶來了規(guī)范化的模塊組織以及統(tǒng)一的開發(fā)方式，這為傳統(tǒng)的模塊的組織、模塊開發(fā)以及模塊積累提供了一種全新的指導(dǎo)以及支撐。

2 傳統(tǒng)開發(fā)模型

軟件工程是研究軟件系統(tǒng)構(gòu)造的計(jì)算機(jī)科學(xué)領(lǐng)域。我們可以將軟件工程定義為“工程在軟件中的應(yīng)用”。更精確地講，IEEE標(biāo)準(zhǔn)610-1990的軟件工程的標(biāo)準(zhǔn)術(shù)語表將軟件工程定義為：系統(tǒng)的、規(guī)范的、定量的方法在軟件的開發(fā)、操作和維護(hù)中的應(yīng)用。

在傳統(tǒng)的軟件生存期模型中，每個(gè)階段都有良好定義的起點(diǎn)和終點(diǎn)，并明確地指明下一階段可以交付使用的內(nèi)容。以瀑布型生存期模型為例(見圖2-1)，它包含需求分析和規(guī)范、系統(tǒng)設(shè)計(jì)和規(guī)范、編碼和模塊測(cè)試、集成和系統(tǒng)測(cè)試、交付和維護(hù)五個(gè)階段。

這種經(jīng)典的軟件開發(fā)過程的最大問題是，它將風(fēng)險(xiǎn)留到后面的階段，并且依次傳遞。例如，如果任何測(cè)試揭示出系統(tǒng)存在的故障，我們至少必須返回到編碼階段，也許要回到設(shè)計(jì)階段以糾正某些錯(cuò)誤。因此清除早期階段引入的錯(cuò)誤要付出巨大的代價(jià),甚至是項(xiàng)目的失敗。

3 幾種增量式開發(fā)模型

3.1 Rational統(tǒng)一過程(RUP)

RUP是一種軟件工程過程。它提供了如何在開發(fā)組織中嚴(yán)格分配任務(wù)和職責(zé)的方法。它的目標(biāo)是：按照預(yù)先制定的時(shí)間計(jì)劃和經(jīng)費(fèi)預(yù)算，開發(fā)高質(zhì)量的軟件產(chǎn)品以滿足最終用戶的需求。

RUP以一種大多數(shù)項(xiàng)目和開發(fā)組織都能適應(yīng)的形式，捕獲了很多現(xiàn)代軟件開發(fā)中的最佳的實(shí)踐。這些實(shí)踐活動(dòng)主要包含六個(gè)方面：

迭代地開發(fā)軟件。

管理需求。

應(yīng)用基于構(gòu)件的構(gòu)架。

為軟件建立可視化的模型。

不斷地驗(yàn)證軟件質(zhì)量。

控制軟件的變更。

其中，迭代開發(fā)是(RUP)推薦的方法。

3.2 極限編程(XP)

XP是一種輕量、高效、低風(fēng)險(xiǎn)、柔性、可預(yù)測(cè)、科學(xué)而充滿樂趣的軟件開發(fā)方式。它與其他方法的不同之處在于：

它的短周期內(nèi)的早期、具體和持續(xù)的反饋。

它遞增地進(jìn)行計(jì)劃編制，這種方法迅速提供一個(gè)總體計(jì)劃，然后在項(xiàng)目的整個(gè)生命周期內(nèi)不斷發(fā)展它。

它針對(duì)不斷變化的業(yè)務(wù)需求靈活地對(duì)功能的實(shí)現(xiàn)進(jìn)行計(jì)劃的能力。

它依賴于由程序員或客戶編寫的自動(dòng)測(cè)試來監(jiān)控開發(fā)進(jìn)度，使得系統(tǒng)得以發(fā)展并及早捕獲缺陷。

它依賴于口頭交流、測(cè)試和源代碼來溝通系統(tǒng)的結(jié)構(gòu)和意圖。

它依賴于在整個(gè)系統(tǒng)存在期間一直持續(xù)的進(jìn)化式設(shè)計(jì)過程。

圖2 -1 軟件生存期的瀑布模型

它依賴于技術(shù)水平一般的程序員之間的緊密協(xié)作。

它依賴于能同時(shí)滿足程序員的短期本能和項(xiàng)目的長(zhǎng)期利益的實(shí)現(xiàn)。

XP項(xiàng)目以探索階段開始。探索的目的是確定需求、區(qū)分各種需求的優(yōu)先次序和對(duì)需求進(jìn)行評(píng)估。一旦確定了足夠的需求以便能夠提供將給客戶帶來收益的最小系統(tǒng)之后，即規(guī)劃第一個(gè)版本。隨著時(shí)間的推移，進(jìn)一步的探索將帶來更多的需求，也將規(guī)劃更多的版本。

一個(gè)XP項(xiàng)目被分解為一系列版本。每個(gè)版本都會(huì)給客戶帶來商業(yè)價(jià)值。當(dāng)規(guī)劃一個(gè)版本時(shí)，客戶選擇將要實(shí)現(xiàn)的故事。這一選擇在技術(shù)上可能并不是最有效的，但它確保每個(gè)版本都給企業(yè)帶來最大的收益。商業(yè)價(jià)值重于技術(shù)效率。一個(gè)版本通?；ㄙM(fèi)一到三個(gè)月的時(shí)間。版本周期越短，我們獲得反饋的速度越快。但是，一個(gè)版本必須同時(shí)給企業(yè)帶來價(jià)值，并且企業(yè)必須能夠吸收此價(jià)值。客戶最終決定版本周期長(zhǎng)短。

XP的迭代計(jì)劃一般將一個(gè)版本分解為幾個(gè)一周到三周的迭代。迭代長(zhǎng)度在項(xiàng)目開始時(shí)即已選定，并在以后保持不變。團(tuán)隊(duì)通過向客戶提交預(yù)算來開始規(guī)劃迭代。該預(yù)算是開發(fā)人員認(rèn)為他們能夠完成的工作量。這一數(shù)量采用了與故事評(píng)估相同的單位。再一次應(yīng)用一個(gè)簡(jiǎn)單的規(guī)則：開發(fā)人員在一次迭代內(nèi)可以承擔(dān)的工作量與他們?cè)谏弦淮蔚鷥?nèi)完成的工作量相同。對(duì)于第一次迭代，提供了合理但任意的評(píng)估，它可能是錯(cuò)誤的，但隨后的迭代將快速糾正它。

在編程方式上，XP采用結(jié)對(duì)編程的方法。雖然任務(wù)已經(jīng)由各個(gè)程序員負(fù)責(zé)，但所有的生產(chǎn)軟件都是由成對(duì)的程序員來編寫的。每一對(duì)程序員在一個(gè)工作站上進(jìn)行開發(fā)，共用一個(gè)鍵盤。

3.3 Scrum軟件開發(fā)過程

Scrum是新興起來的敏捷軟件開發(fā)過程，它主要基于經(jīng)驗(yàn)式的反饋控制原理。其模型如圖3-1所示：

“I”代表輸入，例如需求，采用的技術(shù)等。隨著Scrum開發(fā)進(jìn)程，輸入部分逐步明晰。

“Proeess”是Scrum過程所規(guī)定的30天的開發(fā)周期。

“C”是Scrum過程在每日實(shí)施過程中要執(zhí)行的控制行為。

“O”是每一次Scrum周期完成時(shí)所開發(fā)出的軟件產(chǎn)品。

Scrum實(shí)踐活動(dòng)主要包含以下內(nèi)容：

(1) Scrum Master：

負(fù)責(zé)整個(gè)Scrum過程的實(shí)施。它是一個(gè)介于客戶與開發(fā)團(tuán)隊(duì)之間的角色。既代表客戶向開發(fā)團(tuán)隊(duì)確定需求，又代表開發(fā)團(tuán)隊(duì)向客戶提供軟件產(chǎn)品。

(2)Product Backlog：

圖3 -1 Scrum模型

指的是將要在軟件中提供的應(yīng)用功能與技術(shù)功能，并且這些功能是經(jīng)過優(yōu)先級(jí)排序的。隨著Scrum過程的進(jìn)行，所需的功能不斷的演進(jìn)，優(yōu)先級(jí)也做相應(yīng)的調(diào)整。然而在一個(gè)Scrum處理周期內(nèi)，主體的內(nèi)容是確定不變的。

(3)Scrum Team：

為了達(dá)成Scrum過程的目標(biāo)而組建的團(tuán)隊(duì)。這個(gè)團(tuán)隊(duì)被給予充分的權(quán)限去決定哪些是完成Scrum目標(biāo)所需要的。Scrum Master與Scrum Team共同決定在一個(gè)Scrum處理周期內(nèi)從Product Backlog中選哪些功能模塊進(jìn)行開發(fā)。

(4) Daily Scrum Meeting：

每天幾分鐘的會(huì)議。會(huì)議的內(nèi)容：報(bào)告總結(jié)自上次Daily Scrum Meeting所取的成果，確定下次Daily Scrum Meeting需做的工作，分析其中存在的障礙，以及如何排除。

(5) Spint：

代表Scrum每一個(gè)處理周期，一般為30天。

(6)Spint Planning Meeting：

在每一個(gè)Spint期開始的時(shí)候要確定該Spint期的工作目標(biāo)。主要包括從Product Backlog選取工作內(nèi)容，并確定優(yōu)先等級(jí)等。

(7)Spint Review：

這是一個(gè)4小時(shí)的信息發(fā)布會(huì)議。在每一個(gè)Spnit周期束的時(shí)候，Scrum Team向管理層、客戶等介紹和演示該階段所取得的成果。

整個(gè)Scrum軟件過程以Scrum Master和Scrum Team為核心，通過在每一ScrumSpint期間內(nèi)嚴(yán)格執(zhí)行Scrum實(shí)踐所規(guī)定的活動(dòng)，不斷的確定需求，開發(fā)功能，完善產(chǎn)品。

通過以上的分析，采用增量式軟件開發(fā)過程，可以及早地發(fā)現(xiàn)問題、降低險(xiǎn)，并且使得風(fēng)險(xiǎn)發(fā)生概率在每次的迭代過程中逐次降低，大大降低了整個(gè)軟開發(fā)過程的風(fēng)險(xiǎn)成本。

4 OSGI規(guī)范對(duì)增量式開發(fā)的實(shí)現(xiàn)

OSGI規(guī)范為網(wǎng)絡(luò)服務(wù)定義了一種標(biāo)準(zhǔn)化、組件化的計(jì)算環(huán)境。在OSGI規(guī)范中，bundle是部署基于Java的應(yīng)用的唯一實(shí)體。Bundle由Java類和其他資源組成。Bundle向用戶提供功能或者向其他bundle提供組件化的服務(wù)。每一個(gè)bundle可以用基于ZIP文件格式標(biāo)準(zhǔn)而壓縮為JAR文件。

在bundle這個(gè)JAR文件中：

(1) 包含提供0個(gè)或者多個(gè)bundle服務(wù)的資源。這些資源可以是Java編程語言的類文件，也可以是其他的數(shù)據(jù)，例如HTML文件、幫助文件、圖等等。

(2) 包含一個(gè)裝配表(manifest)文件。這個(gè)裝配表文件描述了JAR文件的內(nèi)容，并提供關(guān)于bundle的一些信息。這個(gè)裝配表文件中的信息被當(dāng)做參數(shù)傳遞給OSGI框架，從而使得該bundle能被OSGI框架正確地裝載和啟動(dòng)。

(3) 描述了該bundle所依賴的其他資源。比如所需要的其他Java包等。只有bundle所依賴的資源都在的情況下，該bundle才能正確的啟動(dòng)。

(4) 設(shè)計(jì)了一個(gè)特殊的類文件以充當(dāng)bundle啟動(dòng)者(bundleActivator)的角色。在bundle啟動(dòng)者實(shí)現(xiàn)了BundleActivator接口，它主要包含兩個(gè)操作：start()與stop()。OSGI框架可以通過調(diào)用bundle啟動(dòng)者的start()，stop()方法來啟動(dòng)與停止該bundle。在start()方法中可以做一些初始工作，比如向OSGI框架注冊(cè)該bundle所提供的bundle服務(wù)。在stop方法中可以做一些清除工作。

(5) 包含一個(gè)可選的文檔。這些可選的文檔必須放在JAR文件中的OSGI-OPT目錄或者其子目錄下。這些可選文檔并不是運(yùn)行該bundle所必需的。這些文檔可能有助理解bundle的功能，比如說源代碼文件、設(shè)計(jì)文檔等。而在空間緊缺的情況下，我們可以將這些可選文檔刪除。

除了上面所說的一般bundle外，還有一個(gè)特殊而又重要的bundle被稱為系統(tǒng)bundle(System bundle)。OSGI框架就是由這個(gè)特殊的系統(tǒng)bundle來表示的。

這樣的架構(gòu)使得軟件開發(fā)從一開始就以模塊化、組件化的形式進(jìn)行分割：

(1) 在bundle的內(nèi)部實(shí)現(xiàn)上，可以由簡(jiǎn)單到復(fù)雜，不斷的演進(jìn)。單獨(dú)一個(gè)bundle就可以實(shí)現(xiàn)某一具體功能。由于bundle本身可以演進(jìn)，所以每一個(gè)bundle都可以自然而然地采用增量式的軟件開發(fā)方法。

(2) 當(dāng)某一個(gè)bundle的功能通過增量式的開發(fā)從而得到確定時(shí)，我們可以發(fā)新bundle用以實(shí)現(xiàn)另一項(xiàng)功能。這樣通過bundle數(shù)量上的增加，不斷增加和完善軟件所需的功能。

通過上述的分析，OSGI規(guī)范在設(shè)計(jì)的時(shí)候，已經(jīng)將模塊化、組件化、增量式演進(jìn)等現(xiàn)代軟件開發(fā)方法融入到其架構(gòu)與具體的規(guī)則中，確保了基于OSGI規(guī)范的軟件體可以更好地支持需求的擴(kuò)展與演進(jìn)。

[1][美]Eric Clayberg Dan Rubel，Eclipse插件開發(fā).人民郵電出版社.2006

[2][美]Ericgh Gamma Kent Beck，Contributing to Eclipse，中國(guó)電力出版社.2005

[3]閻宏.Java與模式.電子工業(yè)出版社.2005

[4]OSGi Alliance: http://www.osgi.org/

10.3969/j.issn.1001-8972.2011.005.033

馮毅 天津市理工大學(xué) 學(xué)士學(xué)位 1997年參加工作，主要從事軟件開發(fā)工作。