ＲＵＰ與ＸＰ中的模式應用及比較

摘要：簡要介紹了Rational統(tǒng)一過程(RUP)、極限編程(XP)和模式，并就模式在RUP和XP中的應用進行了分析和比較

關(guān)鍵詞：軟件過程：模式：RUP XP

0 引言

軟件過程是軟件工程的基礎。軟件過程是由一系列的項目的階段、方法、技術(shù)和實踐組成，人們利用它們來開發(fā)、維護軟件和相關(guān)的產(chǎn)物(artifacts)。一個有效的軟件過程能夠增強一個組織的軟件生產(chǎn)力。在當今眾多的軟件過程中，RUP和XP最為流行，且使用越來越廣泛。在面向?qū)ο笙到y(tǒng)的設計中，經(jīng)常會發(fā)現(xiàn)類和通信對象重復出現(xiàn)的模式。這些模式解決特定的設計問題，并使得面向?qū)ο笤O計更靈活、優(yōu)美和最終可復用，如果在面向?qū)ο笙到y(tǒng)的設計過程中，將過程和模式的優(yōu)點結(jié)合，會使兩者相得益彰。本文就當今最流行的兩個軟件過程(RUP和XP)中模式的應用進行分析與比較。

1 相關(guān)介紹

1.1 Rational統(tǒng)一過程

RUP(Rational Unified Process)是一個面向?qū)ο筌浖こ痰耐ㄓ脴I(yè)務流程。它描述了一系列相關(guān)的軟件工程流程，使之具有相同的結(jié)構(gòu)，即相同的流程構(gòu)架。RUP為在開發(fā)組織中分配任務和職責提供一種規(guī)范方法。任何一個RUP的開發(fā)周期都是可以迭代的。

RUP的三大特點是：用例驅(qū)動、以構(gòu)架為中心、迭代和增量開發(fā)。RUP的生命周期，由四個順序的階段和九個核心的工作流組成。四個階段分別是：初始階段(Inception)、細化階段(Elaboration)、構(gòu)造階段(Construction)和交付階段(Transition)。九個核心工作流又分為六個核心過程工作流：業(yè)務建模、需求、分析和設計、實現(xiàn)、測試、部署和三個核心支持工作流：配置和變更管理、項目管理、環(huán)境。圖1勾畫了RUP的完整的生命周期。

1.2極限編程

極限編程XP(eXtreme Programming)是敏捷方法中頗具代表的一種、1996年，Kent將XP新概念用于項目ChryslerComprehensive Compensation system的開發(fā)中，取得了顯著的效果，XP提供了一個全局的、價值驅(qū)動的開發(fā)過程視圖，體現(xiàn)了四個價值目標：溝通、簡化、反饋和勇氣。XP的生命周期包括四個基本活動：編碼、測試、聆聽和設計。XP非常注重測試，要求先寫測試后編碼，因此，它的基本活動的次序是：聆聽、測試、編碼、設計。先聽取需要做什么；然后編寫測試，如果通過了，則證明交付了需要做的東西；下一步，編寫那些通過測試的任務代碼；最后，調(diào)整代碼的設計使其更簡單、更有效，同時仍能夠通過測試。XP有十二條慣例：規(guī)劃策略、小型發(fā)行版、系統(tǒng)隱喻、測試、正確的設計、重構(gòu)、成對編程、集體代碼所有權(quán)、持續(xù)集成、每周四十小時工作制、現(xiàn)場客戶、編碼標準。XP的革新在于把所有的慣例放在一起，以便它們互相支持，讓一些慣例的優(yōu)勢彌補其它慣例的缺點。XP已經(jīng)經(jīng)歷了很多實踐考驗，而且已經(jīng)被成功應用在許多大型的公司，如：Bayerische Landesbank，Credit Suiss Life。XP適用于需求不確定、變化快，項目歷時不超過半年，而人數(shù)不超過十個、在同一地點工作的中小型團隊，也被用于構(gòu)造中小型復雜的系統(tǒng)。方案。一個模式有四個必要部分：模式適用的上下文陳述；模式提出的問題；形成解決方案過程中的約束；對這些約束的解決方案。

模式主要有分析模式、設計模式、組織模式、過程模式等。分析模式是用于系統(tǒng)領(lǐng)域建模的模式，是針對某種常見的應用領(lǐng)域問題的建模。設計模式則是關(guān)于如何保持設計的靈活性的，它們在軟件的很多地方都有應用。在《Design Patterns》中設計模式被分為創(chuàng)建型(creational)、結(jié)構(gòu)型(Structural)、行為型(Behavioral)三種。而在《POSA Volume 1：A System ofPatterns》中模式分為體系結(jié)構(gòu)模式(architecural pattern)、設計模式(design pattern)和慣用法(idiom)。

2 模式在RUP和XP應用及比較

2.1模式在RUP中的應用

RUP在不同的核心過程工作流中可能會用到不同的軟件模式。

在分析設計工作流中，定義備選構(gòu)架的活動之一是構(gòu)架分析。構(gòu)架分析要定義系統(tǒng)構(gòu)架模式、核心機制和建模約定。在構(gòu)架設計中應用構(gòu)架模式可以增強構(gòu)架的穩(wěn)定性。這里的構(gòu)架模式就是POSA中的體系結(jié)構(gòu)模式，表示軟件系統(tǒng)的基本結(jié)構(gòu)化組織圖式。RUP作了進一步的解釋：構(gòu)架模式是一個特定范圍的模式(即解決方案模板)，并且也是具體軟件構(gòu)架的模板。它涉及整個系統(tǒng)范圍內(nèi)的特征，并且通常涉及子系統(tǒng)范圍內(nèi)(而非類級別)的關(guān)系。對于交互系統(tǒng)，使用MVC(模型一視圖一控制器)模式。比如，在網(wǎng)上商店中，MVC模式用于提供不同的人員與系統(tǒng)之間進行交互的界面視圖，如圖2所示。在定義構(gòu)架時，RUP中應用到了分析機制的概念。分析機制代表常見問題的常用解決模式，它們可能表示結(jié)構(gòu)模式或行為模式，也可能同時表示這兩者。分析機制通常實例化一個或多個構(gòu)架模式或分析模式。而RUP的分析模式把Fowler的分析模式擴展到了業(yè)務領(lǐng)域之外的其他領(lǐng)域。而且，RUP主張在構(gòu)架設計中利用分析機制代表構(gòu)架中的中低層的復雜技術(shù)來避免細節(jié)分散構(gòu)架的重點。比如，“永久性”分析機制使得在對象生存期用例、進程生存期或系統(tǒng)關(guān)閉和啟動等方面在確定對象永久性方面的需要時，不必考慮永久性機制的確切功能或工作方式。

在對構(gòu)架進行改進時，初期的重點活動之一是確定設計機制。設計機制是對相應分析機制的改進，設計機制為概念上的分析機制添加具體的細節(jié)，但又并不具體到所需的技術(shù)。跟分析機制類似，設計機制可以實例化一種或多種構(gòu)架模式或設計模式。設計模式為改進軟件系統(tǒng)的子系統(tǒng)、構(gòu)件或其間的關(guān)系提供了方案。設計模式規(guī)模比構(gòu)架模式較小，通常獨立于編程語言。當設計模式的范圍界定之后，它將形成一部分具體的設計模型。設計模式還可用在構(gòu)件的設計及類的設計中。

在確定設計機制的活動中，有一步是將設計機制映射到實施機制。實施機制是使用特定的編程語言及其他實施技術(shù)對相應設計機制的改進。一個實施機制可以實例化一個或多個代碼模式或?qū)嵤┠Ｊ剑谄錁?gòu)建過程中很可能運用多種實施模式(代碼模式)。實施模式也就是POSA中的慣用法，是一種編程語言專用的低級模式，說明如何利用給定語言的特性來實施構(gòu)件的某些特定方面或?qū)嵤?gòu)件之間的關(guān)系。比如，記數(shù)指針使C++的動態(tài)分配共享對象的內(nèi)存管理更容易。

RUP最大的特點之一就是以構(gòu)架為中心，在整個生命周期中，各個階段的工作始終圍繞構(gòu)架展開。在構(gòu)架的定義、確定、改進過程中，充分利用了各層次的模式。

2.2模式在XP中的應用

XP強調(diào)即時實現(xiàn)，沒有明確的分析和設計階段。XP的四個活動中，編碼和設計是同時進行的，編碼和設計活動便融為一體，這樣就弱化了構(gòu)架的概念，這是它與強調(diào)以構(gòu)架設計為中心的RUP的最大不同。XP看似沒有構(gòu)架設計，但實際上構(gòu)架設計還是存在的。XP提倡使用一些簡單的圖例、比喻等方式來表達軟件的構(gòu)架，而這種構(gòu)架設計是無時無刻不在進行的，即XP用系統(tǒng)隱喻代替了RUP的形式上的架構(gòu)。系統(tǒng)隱喻是表示系統(tǒng)如何工作的一個簡單的分配事例。這個事例包含一些類和模式，正是這些類和模式形成了將要建立系統(tǒng)的核心內(nèi)容。通過與已經(jīng)熟悉的情況的類比，這些模式幫助我們理解新的和不熟悉的事情。因而XP可針對需求的特點，采用相應的模式來設計構(gòu)架。同時，XP的文檔較少，模式通過代碼共享、結(jié)對編程起到了溝通的作用。

但XP中常強調(diào)重構(gòu)，而很少提到模式。對此經(jīng)常有一種看法是：模式鼓勵過分設計，重構(gòu)保持簡單、輕量級。模式導致的過分設計是因為設計人員不恰當?shù)厥褂媚Ｊ健嶋H上發(fā)現(xiàn)問題時，應該使用可以解決問題的模式的最簡單的實現(xiàn)，才不至于使解決方案復雜化。GOF在《設計模式》一書中提出“設計模式為重構(gòu)提供了目標”。在XP中可以通過重構(gòu)來得到模式，達到去除重復代碼，保持簡單，提高軟件復用的目的。為了在XP中正確恰當?shù)厥褂媚Ｊ剑瑧摫苊庠谝婚_始使用模式，而是在設計演進中重構(gòu)得到模式，要從簡單開始，考慮模式但將它們放在次要地位，小規(guī)模重構(gòu)，只在真正需要模式的時候才把重構(gòu)轉(zhuǎn)移為模式。又由于在早期設計中使用模式可以防止以后的重構(gòu)，所以，如果在早期設計確實需要引入模式，那么該按照模式原始的樣子來實現(xiàn)它。這樣，在后面的變更中，模式才易于被替換或升級。

在XP中也可以使用適合的構(gòu)架模式、設計模式等。或者在早期設計需要時使用模式，或者在后來的迭代中，重構(gòu)引入模式。模式的引入需要為某些部分的設計增添靈活性來滿足需求。

2，3 RUP與XP中模式應用的比較

在RUP和XP中都可以應用于模式，但它們在模式的應用上不完全相同。

首先，從模式使用的階段看：RUP圍繞構(gòu)架這個中心，階段和工作流都相對更為明確。RUP中應用模式進行分析、設計和編碼等在相應的核心工作流中進行。而XP不同，XP的分析、設計階段不明顯，模式在適宜的時候被引入，因此模式的應用階段性不強。其次，從模式使用的時間看，RUP非常適宜于開發(fā)復雜、技術(shù)難度大、需求多變、高風險的項目，因此在RUP中，模式的應用往往比較早。而XP并不鼓勵太早的使用模式，主張推遲模式的引入，以免因過早的使用模式引起過分設計而失去簡單化。第三，從模式使用的人員看，RUP中人員角色分工相對明確，因而在不同的流程活動中的模式的使用由相應的人員決定，比如，由構(gòu)架設計師在構(gòu)架分析活動中確定分析機制定義構(gòu)架模式。在XP中，要求人員同時懂得多種技術(shù)，使用模式的角色分工不明確。因為XP的代碼共享，當某個成員發(fā)現(xiàn)代碼混亂、太多重復的時候，就可利用重構(gòu)和模式讓系統(tǒng)保持簡單。在重構(gòu)當中引入模式，這就使得模式的使用人員不確定。

模式和不同的軟件過程結(jié)合在一起，會產(chǎn)生不同的效果。RUP包括了軟件開發(fā)的各個方面，適用于大型軟件項目的開發(fā)。XP屬于輕量級的過程，主要關(guān)注于代碼和技術(shù)，適用于小型項目的開發(fā)。大多數(shù)大型的軟件系統(tǒng)都是由幾個子系統(tǒng)(A、B、C等)組成，子系統(tǒng)又可能由幾個模塊組成，在實際的開發(fā)中，我們可以結(jié)合RUP和XP，在起始和細化階段采用RUP結(jié)合模式方法完成需求分析和構(gòu)架設計，在構(gòu)造和移交階段采用XP結(jié)合模式的方法來實現(xiàn)部分子系統(tǒng)或模塊。

3 結(jié)束語

模式為軟件設計與開發(fā)提供了巨大的幫助。根據(jù)軟件的開發(fā)環(huán)境，選取合適的軟件開發(fā)過程，靈活應用模式，可以高效率地開發(fā)出一個高質(zhì)量的軟件產(chǎn)品。