高級系統(tǒng)架構(gòu)設(shè)計師下午試題（I）模擬14

試題一

1企業(yè)應(yīng)用集成（EnterpriseApplicationIntegration,EA工）是每個企業(yè)都必須要面對的

實際問題。企業(yè)服務(wù)總線（EnterpriseServiceBus,ESB.是一種體系結(jié)構(gòu)模式，支持通信各

方間的服務(wù)交互的虛擬化和管理。它充當(dāng)面向服務(wù)架構(gòu)（Service-OrientedArchitecture,SOA.

中服務(wù)提供者和請求者之間的連接服務(wù)的中間層。與傳統(tǒng)的EA工技術(shù)相比，ESB采用總線式的體系結(jié)

構(gòu)集成多個應(yīng)用系統(tǒng)，基于開放標(biāo)準(zhǔn)實現(xiàn)其內(nèi)部核心功能，并支持快速加入新的應(yīng)用到已有的集成環(huán)

境中。

請圍繞''ESB模式在企業(yè)應(yīng)用集成中的應(yīng)用〃論題，依次從以下飛個方面進(jìn)行論述。

1.要敘述你參與實施的企業(yè)應(yīng)用集成項目（包括業(yè)務(wù)背景、組織結(jié)構(gòu)、現(xiàn)有應(yīng)用系統(tǒng)的分布，

以及采用的技術(shù)等），以及你所擔(dān)任的主要工作。

2.詳細(xì)論述ESB的核心功能和典型結(jié)構(gòu)；列舉目前流行的ESB產(chǎn)品：指出你參與的項目所選擇

的ESE產(chǎn)品，并從ESB核心功能的角度說明選擇該產(chǎn)品的理由。

3.闡述在使用ESB技術(shù)進(jìn)行應(yīng)用集成過程中所遇到的問題及解決辦法，簡要敘述你進(jìn)一步應(yīng)用

ESB模式的有關(guān)設(shè)想。

試題二

閱讀以下關(guān)于面向服務(wù)架構(gòu)的應(yīng)用敘述，根據(jù)要求回答問題。

「說明1

某航空公司的主要業(yè)務(wù)系統(tǒng)（如訂票系統(tǒng)、航班調(diào)度系統(tǒng)等）始建于20世紀(jì)七八十年代，之后隨

著信息化的進(jìn)展，陸續(xù)積累了許多異構(gòu)的遺產(chǎn)信息系統(tǒng)。這些系統(tǒng)部分采用了J2EE、.NET等技術(shù)進(jìn)

行開發(fā)，分布在不同的地理位置，采用不同的協(xié)議進(jìn)行數(shù)據(jù)傳輸。近年來，該公司在企業(yè)集成方面也

是煞費(fèi)苦心，已經(jīng)在幾個主要的核心系統(tǒng)之間構(gòu)建了用于信息集成的信息Hub（Information

Hub）,其他業(yè)務(wù)應(yīng)用之間也有不少點(diǎn)到點(diǎn)的集成。盡管這些企業(yè)集成技術(shù)在一定程度上增進(jìn)了系統(tǒng)

間的信息共享，但是面對歷史異構(gòu)的遺產(chǎn)信息系統(tǒng)，企業(yè)的業(yè)務(wù)整合、功能整合仍是困難重重，主要

表現(xiàn)如下。

2由于大部分核心應(yīng)用構(gòu)建在主機(jī)之上，因此工nformationHub是基于主機(jī)技術(shù)開發(fā)，很難被

開放系統(tǒng)使用。

^InformationHub對事件支持不強(qiáng)，被集成的系統(tǒng)間的事件以點(diǎn)到點(diǎn)流轉(zhuǎn)為主，被集成系統(tǒng)

間耦合性強(qiáng)。

4牽扯到多個系統(tǒng)間的業(yè)務(wù)怖作以硬編碼為主，將業(yè)務(wù)活動自動化的成本高，周期長，被開發(fā)的

業(yè)務(wù)活動模塊重用性差。

某軟件開發(fā)公司承接了該航空公司應(yīng)用系統(tǒng)集成任務(wù)，項目組經(jīng)過多方討論和論證之后，決定

采用以面向服務(wù)為中心的企業(yè)集成技術(shù)，一步步解決該公巨所面臨的企業(yè)集成問題。

2、[問題1]

項目組在討論架構(gòu)方案時，某位架構(gòu)師提出采用企業(yè)服務(wù)總線（ESB.架構(gòu)模式，通過ESB的事件

服務(wù)（EventService）完成訂閱發(fā)布，使應(yīng)用程序間的事件集成不再需要原來的點(diǎn)到點(diǎn)方式，從而

解耦組件之間的依賴關(guān)系，降低軟件系統(tǒng)互連的復(fù)雜性。結(jié)合你的系統(tǒng)架構(gòu)設(shè)計經(jīng)驗，請用400字以

內(nèi)的文字簡要說明在ESB環(huán)境中組件之間典型的交互過程，以及ESB具有的核心功能。

3、[問題2]

將彼此關(guān)聯(lián)的業(yè)務(wù)活動組成白動化流程可以進(jìn)一步提高該航空公司業(yè)務(wù)活動的效率。以服務(wù)為

中心的企業(yè)集成通過流程服務(wù)來完成業(yè)務(wù)流程集成。結(jié)合你的系統(tǒng)架構(gòu)設(shè)計經(jīng)驗，請用300字以內(nèi)的

文字列舉出3種SOA架構(gòu)中的流程服務(wù)內(nèi)容，并給出簡要說明。

4、[問題3]

若項目組采用WebService作為基于SOA集成方法的實現(xiàn)技術(shù)，請根據(jù)該航空公司目前的實際

情況，用300字以內(nèi)的文字說明系統(tǒng)應(yīng)該分為哪幾個層次，并簡要說明每個層次的功能。

試題三

閱讀以下關(guān)于設(shè)計模式應(yīng)用的敘述，根據(jù)要求回答問題。

［說明］

某軟件公司承接了一項面向兒童的模擬游戲軟件的開發(fā)任務(wù)，該游戲軟件主要模擬現(xiàn)實世界中各種鴨

子的發(fā)聲特征、飛行特征和外觀特征。游戲軟件需要模擬的鴨子種類及其特征如表所示

鴨子種類及其特征

鴨子種類發(fā)聲特征飛行特征外觀特征

發(fā)出''嘎嘎〃聲用翅膀飛行

灰鴨(MallardDuck)

(Quack)(FlyWithWings)灰色羽毛

紅頭鴨發(fā)出''嘎嘎〃聲用翅膀飛行

(RedHeadDuck)(Quack)(FlyVJithWings)灰色羽毛、頭部紅色

不發(fā)聲不能飛行

棉花鴨(CottonDuck)

(QuackNoWay)(FlyNoWay)白色

發(fā)出橡皮與空氣摩

不能飛行

橡皮鴨(RubberDuck)

擦的聲音(FlybloWay)黑白橡皮顏色

(Squeak)

為支持將來能夠模擬更多種類鴨子的特征，該公司架構(gòu)師采用某種設(shè)計模式設(shè)計的類圖如圖1所示。

在圖1中，類Duck描述了抽象的鴨子,方法fly5、quackb和display5分別表示不同種類的鴨子都

具有飛行特征、發(fā)聲特征和外觀特征；類FlyBehavior與QuackBehavior分別用于表示抽象的飛

行行為與發(fā)聲行為。

圖1

5、［問題1］

請用350字以內(nèi)的文字指出該公司架構(gòu)師所采用的設(shè)計模式的具體名稱、設(shè)計意圖及其優(yōu)缺點(diǎn)。

6、［問題2］

請用400字以內(nèi)的文字指出該公司架構(gòu)師所采用的設(shè)計模式的適用性，以及圖1中需要考慮哪些實現(xiàn)

問題？

7、［問題3］

設(shè)計模式在力度和抽象層次上各不相同。按設(shè)計模式的目的劃分，可分為創(chuàng)建型、結(jié)構(gòu)型和行為型3

種模式；按設(shè)計模式的范圍劃分，可分為類設(shè)計模式和對象設(shè)計模式兩種。請將下列標(biāo)記的設(shè)

計模式填入到下表中的(1)~(5)空缺處。(請用A~J答題)

A.AbstractFac七ory模式B.Adapter模式C.ChainofResponsibility模式

D.Decorator模式E.FactoryMethod模式F.Flyweight模式

G.Interpreter^xtH.工terator模式I.TemplateMethod模式

J.Visitor模式

設(shè)計模式空間

目的

創(chuàng)建型結(jié)構(gòu)型行為型

范圍類(1)(2)

對象(3)(4)(5)

試題四

8、RUP(RationalUnifiedProces)是一種軟件工程過程產(chǎn)品，它吸取了現(xiàn)代軟件開發(fā)中許多

成功的實踐。RUP把軟件生存周期劃分為多個循環(huán)(Cycles),每個循環(huán)生成產(chǎn)品的一個新的版本。

每個循環(huán)依次由4個連續(xù)的階段(Phase)組成，每個階段完成確定的任務(wù)。與傳統(tǒng)的軟件過程相比，

基于RJP的軟件過程可以降低項口的風(fēng)險，規(guī)范管理和開發(fā)流程，有效地控制資源，提高軟件開發(fā)的

成功率和生產(chǎn)率。

請圍繞''統(tǒng)一軟件開發(fā)過程的應(yīng)用〃論題，依次從以下3個方面進(jìn)行論述。

1.概要敘述你參與管理和開發(fā)的軟件項目及你在其中擔(dān)任的主要工作，包括角色、工作內(nèi)容等。

2.論述RUP的核心工作流和典型的迭代策略模式，具體論述你所參與項目如何應(yīng)用RUP,在項

目實施過程中遇到了什么問題，如何解決。

3.分析與評估你在所參與項目中應(yīng)用RUP裁剪的實際開發(fā)效果，以及你進(jìn)一步應(yīng)用RUP的有關(guān)

設(shè)想。

試題五

閱讀以下關(guān)于Java企業(yè)級應(yīng)用系統(tǒng)開發(fā)架構(gòu)的敘述，根據(jù)要求回答問題。

［說明］

某軟件公司承擔(dān)了某中小型企業(yè)應(yīng)用軟件開發(fā)任務(wù)，進(jìn)度要求緊迫。為了按時完成任務(wù)，選擇

合適的企業(yè)應(yīng)用系統(tǒng)開發(fā)架構(gòu)非常重要。項目組在進(jìn)行方案論證時，項目組成員提出了兩種開發(fā)思路。

9劉工建議采用J2EE5.0和￡比3.0進(jìn)行開發(fā)。理由是J2EE定義了標(biāo)準(zhǔn)的應(yīng)用開發(fā)體系結(jié)構(gòu)

和部署環(huán)境，EJB是J2EE的基礎(chǔ)和核心。J2EE5.0主要目標(biāo)是簡化開發(fā)，相比EJB2.1,EJB3.0

具有很多改進(jìn)和提高。

10杜工建議采用Struts、Spring和Hibenate輕量級開源框架相結(jié)合的方式。理由是隨著

Java開源項目陣營的發(fā)展壯大，一些基于POJOs(PlanOldJavaObjects)的開源框架被廣泛

地引入到Java企業(yè)應(yīng)用開發(fā)中來，與重量級的EJB框架相比，這些輕量級的框架有很多優(yōu)點(diǎn)。

項目組仔細(xì)比較分析了兩種方案的特點(diǎn)、優(yōu)點(diǎn)和不足之處。認(rèn)為杜工和劉T的建議都合理，但

是從結(jié)合當(dāng)前項目實際情況出發(fā)，最后決定采用杜工的建議。

9、［問題1］

Java企業(yè)級應(yīng)用框架一般被劃分為3個層次，請用150字以內(nèi)的文字說明都有哪3個層次？功能

分別是什么？

10、［問題2］

請用200字以內(nèi)的文字?jǐn)⑹鯯truts、Spring和Hibernate開源框架特點(diǎn)和結(jié)合方式。

11、［問題3］

請用200字以內(nèi)的文字說明基于Struts、Spring和Eibernate的輕量級框架與基于EJB的重

量級框架解決問題的側(cè)重點(diǎn)右什么不同？

答案：

試題一

1、1.簡要介紹你參與規(guī)劃、設(shè)計、實施和管理的企業(yè)應(yīng)用集成項目的基本情況(包括業(yè)務(wù)背景、組

織結(jié)構(gòu)、現(xiàn)有應(yīng)用系統(tǒng)的分布和采用的技術(shù)等)，簡要說明自己在該項目中的角色、所承擔(dān)的主要任

務(wù)及開展的主要工作。論文敘述自己參與管理和實施的企業(yè)應(yīng)用集成項目應(yīng)有一定的規(guī)模，自己在該

項目中擔(dān)任的主要工作應(yīng)有一定的分量。

(2)如何根據(jù)企業(yè)的具體組織結(jié)構(gòu)確定集成系統(tǒng)的體系結(jié)構(gòu)，并據(jù)此設(shè)計系統(tǒng)的功能分布與物理

拓?fù)浣Y(jié)構(gòu)？

(3)相關(guān)子系統(tǒng)之間的數(shù)據(jù)格式轉(zhuǎn)換問題。

(4)針對具體業(yè)務(wù)編寫合適的處理邏輯并確定消息路由問題等。

論述解決以上問題所采取的策略、具體辦法和步驟，以及它們對該工程項目后期的工作產(chǎn)生了

哪些積極(或消極)的影響(效果和存在的問題)。論文最后可以進(jìn)一步討論你在該工程項目中獲得的

與ESB應(yīng)用相關(guān)的兒點(diǎn)體會，以及在今后的工作過程中，如果碰到類似的開發(fā)項目你將如何應(yīng)用這些

經(jīng)驗或教訓(xùn)。對需要進(jìn)一步改進(jìn)的地方，應(yīng)有具體的著眼點(diǎn)，不能泛泛而談。

4.論文寫作過程中值得關(guān)注的一些要點(diǎn)如下(全書同)。

(1)整篇論文要結(jié)構(gòu)合理、切中要害、陳述完整、言簡意賅、語言流暢、字跡清楚，切忌對知識

點(diǎn)的堆積、長篇大論、言之無物。

(2)選擇自己參與過的工程項目進(jìn)行分析論述，所述項目切題真實，介紹清楚。

(3)下午試卷H是論述題目，問題中提到的中心內(nèi)容在題目的說明中都有所涉及。在答題時首先

要冷靜并認(rèn)真閱讀題目，找出和問題相關(guān)的知識點(diǎn)，確定考題的關(guān)鍵考點(diǎn)，這是答題的前提。

(4)摘要是全文概括，千萬不要寫成引言。

(5)圍繞論文主題，對所參與的項目進(jìn)行科學(xué)敘述與評價，要有具體的著眼點(diǎn)，不能泛泛而談，

盡可能從字里行間讓閱卷者體會到你的實際工作能力、業(yè)務(wù)水平和項目實踐經(jīng)驗。

(6)在考試過程中應(yīng)注意技巧，讓答題的思路最大限度地符合出題的思路，避免跑題，這樣容易

得到閱卷老師的共鳴。

(7)根據(jù)考生對所參與的項目中針對本論文主題的相關(guān)敘述與評價，可確定他(她)有無參與信

息系統(tǒng)項目開發(fā)過程的實踐經(jīng)驗C

試題二

2、企業(yè)服務(wù)總線(EnterpriseServiceBus,ESB)是由中間件技術(shù)實現(xiàn)的支持面向強(qiáng)務(wù)架構(gòu)(SOA)

的基礎(chǔ)軟件平臺，支持異構(gòu)環(huán)境中的服務(wù)以基于消息和事件驅(qū)動模式的交互，并且具有適當(dāng)?shù)姆?wù)質(zhì)

量和可管理性。ESB技術(shù)的基本思想是，提供一種標(biāo)準(zhǔn)的軟件底層架構(gòu)，各種程序組件能夠以服務(wù)單

元的方式''插入〃到該平臺上運(yùn)行，并且組件之間能夠以標(biāo)準(zhǔn)的消息通信方式來進(jìn)行交互。

一個在ESB環(huán)境中組件之間典型的交互過程是：首先由服務(wù)請求者觸發(fā)一次交互過程，產(chǎn)生一個

服務(wù)請求消息，并將該消息按照.ESB的要求標(biāo)準(zhǔn)化，然后標(biāo)準(zhǔn)化的消息被發(fā)送給服務(wù)總線。ESB根

據(jù)請求消息中的服務(wù)名或者接口名進(jìn)行目的組件查找，將消息轉(zhuǎn)發(fā)至目的組件，并最終將處理結(jié)果逆

向返回給服務(wù)請求者。

這種交互過程不再是點(diǎn)對點(diǎn)的直接交互模式，而是由事件驅(qū)動的消息交互模式。通過這種方式，

ESB最大限度上解耦了組件之間的依賴關(guān)系，降低了軟件系統(tǒng)互連的復(fù)雜性。連接在總線上的組件無

須了解其他組件和應(yīng)用系統(tǒng)的位置及交互協(xié)議，只需要向服務(wù)總線發(fā)出請求，消息即可獲得所需服務(wù)。

服務(wù)總線事實上實現(xiàn)了組件和應(yīng)用系統(tǒng)的位置透明和協(xié)議透明。技術(shù)人員可以通過開發(fā)符合ESB標(biāo)準(zhǔn)

的組件(適配器)將外部應(yīng)用連接至服務(wù)總線，實現(xiàn)與其他系統(tǒng)的互操作。同時，ESB以中間件的方式，

提供服務(wù)容錯、負(fù)載均衡、QoS保障和可管理功能。

ESB的基本核心功能歸納如下。

(1)提供位置透明性的消息路由和尋址服務(wù)。

(2)提供服務(wù)注冊和命名的管理功能。

(3)支持多種消息傳遞范型(如請求/響應(yīng)、發(fā)布/訂閱等)。

(4)支持多種可以廣泛使用的傳輸協(xié)議(即傳輸協(xié)議轉(zhuǎn)換)。

(5)支持多種數(shù)據(jù)格式及其相互轉(zhuǎn)換(即多種平臺下多種集成方式的支持)。

(6)提供日志和監(jiān)控功能。

3、企業(yè)部門內(nèi)部的工T系統(tǒng)通過將業(yè)務(wù)活動自動化來提高業(yè)務(wù)活動的效率。但是這些剖門的業(yè)務(wù)活動

并不是獨(dú)立的，而是和其他部門的活動彼此關(guān)聯(lián)的。將彼此關(guān)聯(lián)的業(yè)務(wù)活動組成自動化流程可以進(jìn)一

步提高業(yè)務(wù)活動的效率。以服務(wù)為中心的企業(yè)集成通過流程服務(wù)來完成業(yè)務(wù)流程集成。在業(yè)務(wù)流程集

成中，粒度的業(yè)務(wù)邏輯被組合成業(yè)務(wù)流程，流程服務(wù)提供自動執(zhí)行這些業(yè)務(wù)流程的能力。在參考架構(gòu)

中，流程服務(wù)包括以下內(nèi)容。

(1)編排服務(wù)(ChoreographyService)：通過預(yù)定義的流程邏輯控制流程中業(yè)務(wù)活動的執(zhí)

行，并幫助業(yè)務(wù)流程從錯誤中恢復(fù)。

(2)事務(wù)服務(wù)(TransactionService)：用于保證流程執(zhí)行中的事務(wù)特性(ACID)。對于短

流程，通常采用傳統(tǒng)的兩階段提交技術(shù)；對于長流程，一般采用補(bǔ)償?shù)姆椒ā?/p>

(3)人工服務(wù)(StaffService)：用于將人工的活動集成到流程中。一方面，它通過關(guān)聯(lián)的交

互服務(wù)使得人工可以參與到流程執(zhí)行中；另一方面，它需要管理由于人工參與帶來的管理任務(wù)，如任

務(wù)分派、授權(quán)和監(jiān)管等。

4、在采用WebService作為SOA的實現(xiàn)技術(shù)時，根據(jù)該航空公司目前的實際情況，從功能角度考慮，

該系統(tǒng)應(yīng)該至少分為6個層次，分別為底層傳輸層、服務(wù)通信協(xié)議層、服務(wù)描述層、服務(wù)層、業(yè)務(wù)流

程層和服務(wù)注冊層，如下表所示,

WebService各層次功能及相關(guān)標(biāo)7圭

層次功能相關(guān)標(biāo)準(zhǔn)

底層傳輸層HTTP、SMTP、FTP和

主要負(fù)責(zé)消息的傳輸機(jī)制

(Transport)JMS等

服務(wù)通信協(xié)議層

(Service描述并定義服務(wù)之間進(jìn)行消息傳

SOAP和REST協(xié)議

Communication遞所需的技術(shù)標(biāo)準(zhǔn)

Protocol)

服務(wù)描述層

主要以一種統(tǒng)一的方式描述服務(wù)

(ServiceWSDL

Description)的接口與消息交換方式

將遺產(chǎn)系統(tǒng)進(jìn)行包裝，并通過發(fā)

服務(wù)層

布的WSDL接口描述被定位和調(diào)

(Service)

用

支持服務(wù)發(fā)現(xiàn)、服務(wù)調(diào)用和點(diǎn)到

業(yè)務(wù)流程層點(diǎn)的服務(wù)調(diào)用，并將業(yè)務(wù)流程從

WS-BPEL(BPEL4WS)

(BusinessProcess)WebService的底層調(diào)用抽象

出來

使服務(wù)提供者能夠通過WSDL發(fā)

服務(wù)注冊層

布服務(wù)定義，并支持服務(wù)請求者UDDI

(ServiceRegistry)

查找所需的服務(wù)信息

試題三

5、依題意，在圖1rf1,Duck為抽象類，描述了抽象的鴨子，方法fly()、quack()和display()

分別表示不同種類的鴨子都具有飛行特征、發(fā)聲特征和外觀特征；而類RubberDuck、MallardDuck.

CottonDuck#RedHeadDuck分別描述具體的鴨子種類；類FlyBehavior與QuackBehavior為

抽象類，分別用于表示抽象的飛行行為與發(fā)聲行為；類FlyNoWav與FlyWithWings分別描述不

能飛行的行為和用翅膀飛行的行為；類Quack、Squeak與QuackNoWay分別描述發(fā)出''嘎嘎〃聲的行

為、發(fā)出橡皮與空氣摩擦聲的行為和不發(fā)聲的行為。鑒于不同的鴨子種類只是在行為方面有所區(qū)別，

且為支持將來能夠模擬更多種類鴨子的特征，該公司架構(gòu)師最有可能采用策略(Strategy)設(shè)計模式

來設(shè)計如圖1所示的模擬鴨子游戲軟件。

Strategy模式定義了一組能夠用來表示可能行為集合的類。這些行為可以在應(yīng)用程序中使用，

來修改應(yīng)用程序功能。Strategy(策略)模式的設(shè)計意圖是，定義一系列的算法，把它們一個個封裝

起來，并且使它們可相互替換，使得算法可獨(dú)立于使用它的客戶而變化。具體而言，該模式是一種定

義一系列算法的方法，從概念上看，所有這些算法完成的都是相同的工作，只是實現(xiàn)不同，它可以以

相同的方式調(diào)用所有的算法，減少了各種算法類與使用算法類之間的耦合。Strategy模式的一般結(jié)

構(gòu)如圖2所示。

圖2

Straws模式的一般結(jié)構(gòu)RI

Strategy模式具有以下一些優(yōu)點(diǎn)和缺點(diǎn)。

(1)另一種子類化方法。Strategy類層次為Context(上下文)定義了一系列的可供重用的算

法或行為。繼承有助于析取出這些算法中的公共功能?？梢灾苯由梢粋€Context類的子類，從而

給它以不同的行為。但這會將行為強(qiáng)制編制到Cont一xt中，而將算法的實現(xiàn)與Context的實現(xiàn)混合

起來，從而使Context難以理解、難以維護(hù)和難以擴(kuò)展，而且還不能動態(tài)地改變算法。最后得到一

堆相關(guān)的類，它們之間的唯一差別是它們所使用的算法或行為。將算法封裝在獨(dú)立的Strategy類中

使得架構(gòu)師可以獨(dú)立于Context而改變它，使它易于切換、理解和擴(kuò)展。

(2)在類自身中定義了每一個行為，從而減少了一些條件語句；Strategy模式提供了用條件語

句選擇所需行為以外的另一種選擇。當(dāng)不同的行為堆砌在一個類中時，很難避免使用條件語句來選擇

合適的行為。將行為封裝在一個個獨(dú)立的七egy類中消除了這些條件語句。

(3)更容易擴(kuò)展模型，即在不對應(yīng)用程序進(jìn)行代碼修改的情況下，使該模式具有新的行為。

(4)客戶必須了解不同的Strategy。該模式有一個潛在的缺點(diǎn)，就是一個客戶耍選擇一個合適

的Strategy就必須知道這些Strategy到底有何不同。此時可能不得不向客戶暴露具體的實現(xiàn)問題。

因此僅當(dāng)這些不同行為變成與客戶相關(guān)的行為時，才需要使用Strategy模式。

(5)Strategy和Context之間的通信開銷。無論各個Concretestrategy(具體策略)實現(xiàn)的

算法是簡單還是復(fù)雜，它們都共享Strategy定義的接口。因此很可能某些Concr一teStrat一gy不

會都用到所有通過這個接口傳遞給它們的信息；簡單的ConcreteStrategy可能不使用其中的任何

信息。這就意味著有時Context.會創(chuàng)建和初始化一些永遠(yuǎn)不會用到的參數(shù)。如果存在這樣問題，

那么將需要在Strategy和Context之間進(jìn)行更加緊密的耦合。

(6)增加了對象的數(shù)目。Strategy增加了一個應(yīng)用中的對象的數(shù)目。有時可以將Strategy實

現(xiàn)為可供各Context共享的無狀態(tài)的對象來減少這一開銷。任何其余的狀態(tài)都由Context維護(hù)。

Context在每一次對Strategy^')象的請求中都將這個狀態(tài)傳遞過去。共享的Strategy不應(yīng)在各次

調(diào)用之間維護(hù)狀態(tài)。

6、在以下情況中，應(yīng)該使用Strategy模式。

(1)許多相關(guān)類只是在行為方面有所區(qū)別。、'策略〃提供了一種用多個行為中的一個行為來配置

一個類的方法。

(2)需要使用一個算法的不同變體。例如，定義了一些反映不同的空間或時間權(quán)衡的算法，當(dāng)這

些變體實現(xiàn)為一個算法的類層次時，可以使用策略模式。

(3)算法使用客戶端未知的數(shù)據(jù)，可使用策略模式以避免暴露復(fù)雜的、與算法相關(guān)的數(shù)據(jù)結(jié)構(gòu)。

(4)一個類定義了多種行為，并且這些行為在這個類的操作中以多個條件語句的形式出現(xiàn)。將相

關(guān)的條件分支移入它們各自的Strategy類中以代替這些條件語句。

依題意，在圖1中，需要考慮以下一些Strategy模式實現(xiàn)問題。

(1)定義類Duck和類FlyBehavior(或類QuackBehavior)接口。這些接口必須使得類

FlyWithwings>類FlyNoWay、類Quack、類Squeak和類QuackNoWay等能夠有效地訪問它所需

要的類Duck中的任何數(shù)據(jù)，反之亦然。一種解決辦法是讓類Duck將數(shù)據(jù)放在參數(shù)中傳遞給類

FlyBehavior(或類QuackBehavior)操作，也就是說，將數(shù)據(jù)發(fā)送給類FlyBehavior(或類

QuackBehavior)<>這使得類FlyBehavior(或類QuackBehavior)和類Duck解耦。但從另一個

角度考慮，類Duck也可能發(fā)送?些類FlyBehavior（或類QuackBehavior）不需要的數(shù)據(jù)。

另一種解決辦法是讓類Duck將自身作為一個參數(shù)傳遞給類FlyBehavior（或類

QuackBehavior）,該類FlyBehavior（或類QuackBehavior）再顯式地向類Duck請求數(shù)據(jù)；或

者類FlyBehavior（或類QuackBehavior）可以存儲對它的類Duck的一個引用，這樣根本不再需要

傳遞任何東西。這兩種情況下，類FlyBehavior（或類QuackBehavior）都可以請求到它所需要的

數(shù)據(jù)。但要求類Duck必須對它的數(shù)據(jù)定義一個更為精細(xì)的接口，這將使得類FlyBehavior（或類

QuackBehavior）和類Duck更加緊密地耦合在一起。

（2）將類FlyBehavior（或類QuackBehavior）作為模板參數(shù)。例如，在C++中，可利用模板

機(jī)制用一個Strategy來配置一個類。然而這種技術(shù)僅當(dāng)下面條件滿足時才可以使用：可以在編譯時

選擇Strategy；它無須在運(yùn)行時改變。在這種情況下，要被配置的類（如類Duck）被定義為以一個

Strategy類作為一個參數(shù)的模板類。使用模板不再需要定義給類FlyBehavior（或類

QuackBehavior）定義接口的抽象類。把類FlyBehavior（或類QuackBehavior）作為一個模板參

數(shù)也使得可以將一個類FlyBehavior（或類QuackBehavior）和它的類Duck靜態(tài)地綁定在一起，從

而提高效率。

（3）盡量使類FlyBehavior（或類QuackBehavior）成為可選的對象。即使在不使用額外的

FlyBehavior（或類OuackBehayior）對象的情況下，類Duck也還有意義，那么它還可以被簡化。

類Duck在訪問類FlyBehavior（或類QuackBehavior）前先檢查它是否存在，如果有，那么就使用

它；如果沒有，那么類Duck執(zhí)行默認(rèn)的行為。這種方法的好處是客戶根本不需要處理

FlyBehavior（或類QuackBehavior）對象，除非它們不喜歡默認(rèn)的行為。7、設(shè)計模式主

要用于得到簡潔靈活的系統(tǒng)設(shè)計，GOF的書中共有23個設(shè)計模式，這些模式可以按兩個準(zhǔn)則來分類：

一是按設(shè)計模式的目的劃分，可分為創(chuàng)建型、結(jié)構(gòu)型和行為型3種模式：一是按設(shè)計模式的范圍劃分，

即根據(jù)設(shè)計模式是作用于類還是作用于對象來劃分，可分為類設(shè)計模式和對象設(shè)計模式，如表所示。

設(shè)計模式空間

目的

創(chuàng)建型結(jié)構(gòu)型行為型

Interpreier

Factory

類Adapter（類）Template

MethodMethod

Chainof

Responsibil

Adapter（對

ity

Abstract象）Command

范圍Bridge

FactoryIterator

Composite

對象BuilderMediator

PrototypeDecoratorMemento

SingletonFacadeObserver

Flyweight

State

ProxyStrategy

Visitor

創(chuàng)建型模式是對對象實例化過程的抽象，它通過采用抽象類所定義的接口，封裝了系統(tǒng)中對象

如何創(chuàng)建及組合等信息。該模式允許在系統(tǒng)中創(chuàng)建對象，而不需要在代碼中標(biāo)識特定類的類型，這樣

用戶就不需要編寫大量復(fù)雜的代碼來初始化對象。它是通過該類的子類來創(chuàng)建對象的。但是，這可能

會限制在系統(tǒng)內(nèi)創(chuàng)建對象的類型或數(shù)目。創(chuàng)建型模式主要有FactoryMethod（工廠方法）、

AbstractFactory（抽象工廠）、Builder（構(gòu)建器）、Prototype（原型）和Singleton（單獨(dú)）

等模式。

結(jié)構(gòu)型模式主要用于如何組合已有的類和對象以獲得更大的結(jié)構(gòu)，一般借鑒封裝、代理或繼承

等概念將一個或多個類或?qū)ο筮M(jìn)行組合和封裝，以提供統(tǒng)一的外部視圖或新的功能。該模式允許在不

重寫代碼或自定義代碼的情況下創(chuàng)建系統(tǒng)，從而使系統(tǒng)具有增強(qiáng)的重復(fù)使用性和應(yīng)用性能。該模式控

制了應(yīng)用程序大部分之間的關(guān)系，將以不同的方式影響應(yīng)用程序。結(jié)構(gòu)型模式主要有Adapter（適配

器）、Bridge（橋接）、Composite（組成）、Decorator（裝飾）、Fagade（外觀）、Flyweight（享

元）和Proxy（代理）等。

行為型模式主要用于對象之間的職責(zé)及其提供的服務(wù)的分配，它不僅描述對象或類的模式，還

描述它們之間的通信模式，特別是描述一組對等的對象怎樣相互協(xié)作以完成其中任意一個對象都無法

單獨(dú)完成的任務(wù)。該模式可以影響一個系統(tǒng)的狀態(tài)和行為流。通過優(yōu)化狀態(tài)和行為流轉(zhuǎn)換及修改的方

式，可以簡化、優(yōu)化并且提高應(yīng)用程序的可維護(hù)性。行為型模式主要有工nterpreter（解釋器）、

TemplateMethod（模板方法）、ChainofResponsibility（職貨鏈）、Command（命令）、

Iterator（迭代器）、Mediator（中介者）、Memento（備忘錄）、Observer（觀察者）、State（狀

態(tài)）、Strategy（策略）和Visitor（訪問者）等。

試題四

8、簡要介紹你參與管理和開發(fā)的大中型信息系統(tǒng)軟件工程項目的基本情況，簡要說明自己在該項目

中的角色、所承擔(dān)的主要任務(wù)及開展的主要工作。論文敘述自己參與設(shè)計和實施的軟件項目應(yīng)有一定

的規(guī)模，自己在該項目中擔(dān)任的主要工作應(yīng)有一定的分量。

2.統(tǒng)一軟件開發(fā)過程（RUP）是一種用例驅(qū)動的，以體系結(jié)構(gòu)為中心、迭代和增量的軟件開發(fā)過

程?？梢圆捎枚S模型來描述RU?一時間和內(nèi)容。從時間維來看，軟件生存周期被劃分為不同的循環(huán)

（Cycles）o每個循環(huán)又被劃分為4個連續(xù)的階段（Phase）,每個階段都包含一個妥善定義的里程碑

（Milestone）；每個階段還可以被進(jìn)一步劃分為若干輪迭代（Iterations）o一次迭代是一次完整

的開發(fā)過程，每次迭代結(jié)束時會發(fā)布一個可執(zhí)行的產(chǎn)品，這個產(chǎn)品是正在開發(fā)的軟件系統(tǒng)的一個子集，

它會逐漸擴(kuò)展為最終系統(tǒng)。內(nèi)容結(jié)構(gòu)指的是一些將活動（Activities）組織在一起的、天然存在的

規(guī)則。

1）RUP的生命周期

RUP把生命周期模型劃分為初始階段（Inception）細(xì)化階段（Elaboration）構(gòu)造階段

（Construction）和交付階段iTransition）4個階段，如下表所示。每個階段結(jié)束于一個主要的

里程碑（MaiorMil一stones）。每個階段本質(zhì)上是兩個里程碑之間的時間跨度。在每個階段的結(jié)尾

執(zhí)行一次評估以確定這個階段的目標(biāo)是否已經(jīng)滿足。如果評估結(jié)果令人滿意的話，可以允許項目進(jìn)入

下一個階段。

RUP各階段說明

階段目標(biāo)口標(biāo)說明里程碑里程碑說明

為了達(dá)到該目的必須識別所有與

系統(tǒng)交互的外部實體，在較高層

確定項目開發(fā)的次上定義交互的特性。在這個階生命周期目標(biāo)

初始評價項目基本的生存

目標(biāo)和范圍，即段中所關(guān)注的是整個項目進(jìn)行中(Lifecycle

階段能力

確定項目的邊界的業(yè)務(wù)和需求方面的主要風(fēng)險。Objective)

對于建立在原有系統(tǒng)基礎(chǔ)上的開

發(fā)項目來講，初始階段可能很短

確定系統(tǒng)架構(gòu)和為系統(tǒng)的結(jié)構(gòu)建立了

為了達(dá)到該目的，必須在理解整

明確需求。分析管理基準(zhǔn)并使項目小

個系統(tǒng)的基礎(chǔ)上，對體系結(jié)構(gòu)作

問題領(lǐng)域，建立生命周期結(jié)構(gòu)組能夠在構(gòu)建階段中

出決策，包括具范圍、主要功能

精化健全的體系結(jié)構(gòu)(Lifecycle進(jìn)行衡量。此刻，要

和諸如性能等非功能需求。同時

階段基礎(chǔ)，編制項目Architectu檢驗詳細(xì)的系統(tǒng)目標(biāo)

re)

計劃，淘汰項目為項目建立支持環(huán)境，包括創(chuàng)建和范圍、結(jié)構(gòu)的選擇，

中最高風(fēng)險的元開發(fā)案例，創(chuàng)建模板、準(zhǔn)則及準(zhǔn)以及主要風(fēng)險的解決

素備工具方案

決定了產(chǎn)品是否可以

所有剩余的構(gòu)件和應(yīng)用程序功能在測試環(huán)境中進(jìn)行部

被開發(fā)并集成為產(chǎn)品，所有的功初始功能署。此刻，要確定軟

實現(xiàn)剩余的系統(tǒng)

構(gòu)建能被詳細(xì)測試。從某種意義上說，(Initial件、環(huán)境及用戶是否

功能，所有的功

階段構(gòu)建階段是一個制造過程，其重Operationa可以開始系統(tǒng)的運(yùn)

能被詳細(xì)測試

點(diǎn)放在管理資源及控制運(yùn)作以優(yōu)1)作。此時的產(chǎn)品版本

化成木、進(jìn)度和質(zhì)量也常被稱為''Beta"

版

重點(diǎn)是確保軟件對最終用戶是可

此時要確定目標(biāo)是否

用的，該階段可以跨越幾次迭代，

實現(xiàn)，是否應(yīng)該開始

包括為發(fā)布做準(zhǔn)備的產(chǎn)品測試，

完成軟件的交付產(chǎn)品發(fā)布另一個開發(fā)周期。在

移交基于用戶反饋的少量的調(diào)整。用

工作，將系統(tǒng)移(Product一些情況下這個里程

階段戶反饋應(yīng)主要集中在產(chǎn)品調(diào)整、Release)

交給客戶碑可能與下一個周期

設(shè)置、安裝和可用性問題，所有

主要的結(jié)構(gòu)問題應(yīng)該已經(jīng)在項目的初始階段的結(jié)束重

生命周期的早期階段解決了合

2)RUP中有9個核心工作流，分為6個核心過程工作流(CoreProcessWorkflows)和3個核心

支持工作流(CoreSupportingWorkflows)o9個核心工作流在項目中輪流被迭代使用，在每一

次迭代中以不同的重點(diǎn)和強(qiáng)度重復(fù)

(1)業(yè)務(wù)建模(BusinessMod一ling)工作流：描述了如何為新的目標(biāo)組織開發(fā)一個構(gòu)想，并

基于這個構(gòu)想在商業(yè)用例模型和商業(yè)對象模型中定義組織的過程、角色和責(zé)任。

(2)需求(Requirement)工作流：描述系統(tǒng)應(yīng)該做/么，并使開發(fā)人員和用戶就這一描述達(dá)

成共識。為了達(dá)到該目標(biāo)，要對需要的功能和約束進(jìn)行提取、組織和文檔化：最重要的是理解系統(tǒng)所

解決問題的定義和范圍。

(3)分析和設(shè)計(Analysis或Design)工作流：將需求轉(zhuǎn)化成未來系統(tǒng)的設(shè)計，為系統(tǒng)開發(fā)一

個健壯的結(jié)構(gòu)并調(diào)整設(shè)計使其與實現(xiàn)環(huán)境相匹配，優(yōu)化其性能。分析設(shè)計的結(jié)果是一個設(shè)計模型和一

個可選的分析模型。

(4)實現(xiàn)(工mplementaticm)工作流：以層次化的子系統(tǒng)形式定義代碼的組織結(jié)構(gòu)，以組件的

形式(源文件、二進(jìn)制文件或可執(zhí)行文件)實現(xiàn)類和對象，將開發(fā)出的組件作為單元進(jìn)行測試，并集

成由單個開發(fā)者(或小組)所產(chǎn)生的結(jié)果，使其成為可執(zhí)行的系統(tǒng)。

(5)測試(Test)工作流：檢驗對象間的交1L作用，驗i止軟件中所有組件的止確集成，檢驗所有

的需求已被正確的實現(xiàn)，識別并確認(rèn)缺陷在軟件部署之前被提出并處理。

(6)部署(Deployment)工作流：軟件打包、生成軟件本身以外的產(chǎn)品、安裝軟件，以及為用

戶提供幫助等。成功的生成版本并將軟件分發(fā)給最終用戶。該工作流描述了那些與確保軟件產(chǎn)品對最

終用戶具有可用性相關(guān)的活動。

(7)配置和變更管理(Configuration或ChangeManagement)工作流：描述了如何管理并

行開發(fā)、分布式開發(fā)、如何自動化創(chuàng)建工程，以及對產(chǎn)品修改原因、時間和人員保持審計記錄。該工

作流提供了準(zhǔn)則來管理演化系統(tǒng)中的多個變體，跟蹤軟件創(chuàng)建過程中的版本。

(8)項目管理(ProjectManagement)工作流：為項目的管理提供框架，為計劃、人員配備、

執(zhí)行和監(jiān)控項目提供實用的準(zhǔn)則，為管理風(fēng)險提供框架等。軟件項目管理平衡各種可能產(chǎn)生沖突的目

標(biāo)，管理風(fēng)險，克服各種約束并成功交付使用戶滿意的產(chǎn)品。

(9)環(huán)境(Environment)工作流：向軟件開發(fā)組織提供軟件開發(fā)環(huán)境，包括過程和工具。該工

作流集中于配置項目過程中所需要的活動，同樣也支持開發(fā)項目規(guī)范的活動，提供了逐步的指導(dǎo)手冊

并介紹了如何在組織中實現(xiàn)過程C

W)關(guān)于RUP迭代計劃的安排，通常有以下4種典型的策略模式

(1)增量式(incremental)o該模式的特點(diǎn)是項目架構(gòu)的風(fēng)險較小(往往是開發(fā)一些重復(fù)性的

項目)，所以精化階段只需要一個迭代。但項目的開發(fā)工作量較大，構(gòu)建階段需要有多次迭代來實現(xiàn)，

每次迭代都在上一次迭代的基礎(chǔ)上增加實現(xiàn)一部分的系統(tǒng)功能。

(2)演進(jìn)式(Evolutionary)。當(dāng)項目架構(gòu)的風(fēng)險較大時?(從未開發(fā)過類似項目)，需要在精化

階段通過多次迭代來建立系統(tǒng)的架構(gòu)，架構(gòu)是通過多次迭代的探索，逐步演化而來的。當(dāng)架構(gòu)建立時，

往往系統(tǒng)的功能也已經(jīng)基本實現(xiàn)，所以構(gòu)建階段只需要一次迭代。

(3)增量提交(incrementalDeliveq)o該模式的特點(diǎn)是產(chǎn)品化階段的迭代較多，比較常見

的例子是項目的難度并不大，但W務(wù)需求在不斷地發(fā)牛變化，所以需要通過迭代來不斷地部署完成的

系統(tǒng)；但同時又要不斷地收集用戶的反饋來完善系統(tǒng)需求，并通過后續(xù)的迭代來補(bǔ)充實現(xiàn)這些需求。

(4)單次迭代(GrandDesign)o傳統(tǒng)的瀑布模型可以看做是迭代化開發(fā)的一個特例，整個開

發(fā)流程只有一次迭代。但這種模式有一個固有的弱點(diǎn)，由于它對風(fēng)險的控制能力較差，往往會在產(chǎn)品

化階段產(chǎn)生一些額外的迭代，造成項目的延誤。

4)結(jié)合項目實踐經(jīng)驗，說明在你參與管理和開發(fā)的軟件項目中如何應(yīng)用RUP,在項目實施過程

中遇到了什么問題，采用了哪些技術(shù)、方法和步驟來解決相關(guān)的問題，以及它們對該工程項目后期的

工作產(chǎn)生了哪些積極(或消極)的影響(效果和存在的問題)，對所提出的問題，應(yīng)有具體的著眼點(diǎn)，

不能泛泛而談。

3.RUP是一個通用的過程模板，包含了很多開發(fā)指南、制品，以及開發(fā)過程所涉及的各種角色

說明。RUP非常龐大，沒有一個項目會使用RUP中的所有東西，針對具體的開發(fā)機(jī)構(gòu)和項目，應(yīng)用RUP

時還要做裁剪，即要對RUP進(jìn)行配置。RUP就像一個元過程(m一ta-process),通過對RUP進(jìn)行裁剪

可以得到很多不同的開發(fā)過程，這些軟件開發(fā)過程可以看做RUP的具體實例，以適應(yīng)于不同的開發(fā)機(jī)

構(gòu)和項目需求。針對一個具體的軟件項目，RUP裁剪可以分為以下幾個步驟。

(1)確定本項目需要哪些工作流。RUP的9個核心工作流并不總是需要的，可以根據(jù)項目的規(guī)模、

類型等對核心工作流做一些取舍。例如，嵌入式軟件系統(tǒng)項目通常不需要業(yè)務(wù)建模這一工作流。

(2)確定每個工作流要產(chǎn)出哪些制品。例如，規(guī)定某個工作流應(yīng)產(chǎn)出哪些類型的文檔。

(3)確定生命周期的4個階段之間如何演進(jìn)。確定階段間演進(jìn)要以風(fēng)險控制為原則，決定每個階

段要執(zhí)行哪些工作流，每個工作流執(zhí)行到什么程度，產(chǎn)出的制品有哪些，每個制品完成到什么程度等。

(4)確定每個階段內(nèi)的迭代計劃。規(guī)劃RUP的4個階段中每次迭代開發(fā)的具體內(nèi)容有哪些。

(5)規(guī)劃工作流內(nèi)部結(jié)構(gòu)。工作流不是活動的簡單堆積.，它涉及角色、活動及制品，其復(fù)雜程度

與項目規(guī)模及角色多少等因素有關(guān)。通常用活動圖的形式給出所規(guī)劃的工作流的內(nèi)部結(jié)構(gòu)。這一步?jīng)Q

定裁剪后的RUP要設(shè)立哪些角色，是對RUP進(jìn)行裁剪的難點(diǎn)。

結(jié)合RUP裁剪步驟的相關(guān)知識，分析與評估你在所參與項目中應(yīng)用RUP裁剪的實后開發(fā)效果。注

意要給出具體的評價依據(jù)，評價要客觀、適當(dāng)。論文最后可以進(jìn)一步討論你在該工程項目中獲得的、

應(yīng)用RUP方面的幾點(diǎn)經(jīng)驗體會，以及在今后的工作過程中，如果碰到類似的開發(fā)項目你將如何應(yīng)用這

些經(jīng)驗或教訓(xùn)。

試題五

9、這是一道要求讀者掌握J(rèn)ava企業(yè)應(yīng)用框架層次結(jié)構(gòu)及其各層功能的簡答題。本題所涉及的知識點(diǎn)

如下。

（1）Java企業(yè)應(yīng)用框架一般被劃分為表現(xiàn)層、業(yè)務(wù)邏輯組件層和持久層等3個邏輯層次。

（2）其中，表現(xiàn)層用來建立應(yīng)用系統(tǒng)的界面，對應(yīng)視圖（View）。該層集中于為從客戶端發(fā)來的

請求服務(wù)的對象及其行為，用于展現(xiàn)數(shù)據(jù)；負(fù)責(zé)View組件實現(xiàn)模式、組件在View顯示粒度、頁面跳

轉(zhuǎn)，以及事件觸發(fā)等功能。例如，表現(xiàn)層采用JSF（JavaServerFace）,JSF的開發(fā)流程的核心

是事件驅(qū)動，組件和標(biāo)簽的封裝程度非常高，很多典型應(yīng)用已經(jīng)不需要開發(fā)者去處理HTTP,整個過

程是通過1OC（依賴注入）來實現(xiàn)的，即可以幫助對客戶端請求進(jìn)行先期及后期的處理等。

（3）業(yè)務(wù)邏輯組件層用來開發(fā)應(yīng)用邏輯，對應(yīng)控制器（Controller）。例如，業(yè)務(wù)邏輯組件層

采用EJB3.0的SessionBean。EJB3.0允許開發(fā)者使用耦合松散的組件來開發(fā)應(yīng)用，實現(xiàn)一個EJB

所有使用的類和接口都減少了。

該層集中于支持由表現(xiàn)層發(fā)起的（某些情況下也可能由持久層直接發(fā)起）業(yè)務(wù)數(shù)據(jù)的邏輯處理。

例如，隱藏業(yè)務(wù)對象的復(fù)雜性，集中工作流的處理；分離表現(xiàn)層與持久層，并為服務(wù)提供外觀和代理

接口等。

（4）持久層是實現(xiàn)持久化存儲，對應(yīng)模型（Model）o仞如，采用EJB3.0實體Bean持久化模型，

吸收了Hibernate的一些思想采用0/RMappinR模式。

該層集中于支持外部資源通信。例如，與數(shù)據(jù)庫交互數(shù)據(jù)；抽象數(shù)據(jù)源，提供透明的數(shù)據(jù)訪問；

幫助法行EJB組件中的異步處理等。

10、這是一道要求讀者掌握Struts,Spring和Hibenate輕量級開源框架特點(diǎn)和結(jié)合方式的簡答

題。本題所涉及的知識點(diǎn)如下。

（1）由于EJB容器能夠很好的處理系統(tǒng)性能、事務(wù)機(jī)制、安全訪問權(quán)限，以及分布式運(yùn)算等問題，

基于EJB框架進(jìn)行開發(fā)能保證企業(yè)應(yīng)用平滑發(fā)展，而不是發(fā)展到一種規(guī)模就重新更換一套軟件系統(tǒng)，

旦可以保證開發(fā)人員將大部分精力集中在業(yè)務(wù)邏輯的開發(fā)上。采用EJB框架開發(fā)的企業(yè)應(yīng)用具有必須

繼承或依頗EJB容器的特點(diǎn)。EJB充分考慮到了頂級大型項目的需求，使用它幾乎能解決企業(yè)級應(yīng)用

涉及的所有問題，相應(yīng)的基于EJB框架也是一個功能復(fù)雜的重量級框架。

（2）在基于POJOs輕量級框架上開發(fā)的應(yīng)用程序無須依賴于EJB容器可獨(dú)立運(yùn)行，對應(yīng)于Java

企業(yè)應(yīng)用3個層次的輕量級框架技術(shù)分別都得到了一定的發(fā)展。Struts框架+Spring框架

+Hiberhate框架實現(xiàn)了表現(xiàn)層、業(yè)務(wù)邏輯組件層和持久層的結(jié)合。

（3）目前比較流行的開源表現(xiàn)層