【軟件工程及項(xiàng)目管理】知識(shí)點(diǎn)貫通全講

【軟件工程及項(xiàng)目管理】知識(shí)點(diǎn)串講第1章 軟件工程技術(shù)發(fā)展思索 21.1 軟件工程技術(shù)發(fā)展歷程 21.2 軟件與軟件特征 31.3 軟件工程的主要研究?jī)?nèi)容 31.4 軟件技術(shù)的發(fā)展趨勢(shì) 7第2章 傳統(tǒng)的軟件工程過(guò)程 82.1 什么是軟件生命周期 82.2 軟件生命周期的六個(gè)階段 92.3 軟件生命周期的模型 10第3章軟件工程之面向?qū)ο蠹夹g(shù)概述 12第4章 面向?qū)ο筌浖こ谭椒▽W(xué)實(shí)踐 144.1是“設(shè)計(jì)主導(dǎo)”還是“程序主導(dǎo)” 144.2 面向?qū)ο蠓椒ㄅc結(jié)構(gòu)化方法比較 174.3 方法學(xué)是思路不是定律 18第5章中間件技術(shù) 19第6章 JavaEE技術(shù)軟件工程專題 216.1 企業(yè)級(jí)Java 216.2 J2EE簡(jiǎn)介 226.2.1 J2EE的概念 236.2.2 J2EE的四層模型 246.2.3 J2EE的結(jié)構(gòu) 266.3 JavaEE5 286.4 J2EE探險(xiǎn)者系列 296.5 J2EE最佳實(shí)踐 306.6 J2EE與SOA 316.7 J2EE與Web2.0 316.8StrutsVSSpring兩種MVC框架比較 33第7章 面向方面編程AOP 357.1 引言 357.2 什么是方面 367.3 AOP：利與弊 377.4 SpringAOP:Spring之面向方面編程 37第8章 基于組件的軟件工程-軟件開(kāi)發(fā)新挑戰(zhàn) 408.1 軟件開(kāi)發(fā)面臨的挑戰(zhàn) 408.2 基于組件的開(kāi)發(fā)中有幾個(gè)危及其成功的不利因素 408.3 基于組件的軟件工程 418.4 組件規(guī)范 418.5 基于組件系統(tǒng)開(kāi)發(fā)生命周期 428.6 軟件體系和基于組件的開(kāi)發(fā) 438.7 UML和基于組件的系統(tǒng)模型 448.8 CORBA與DCOM技術(shù) 448.8.1分布式對(duì)象技術(shù) 448.8.2CORBA的設(shè)計(jì)模式 468.8.3DCOM技術(shù) 508.8.4CORBA與DCOM的主要異同 538.9 基于組件軟件工程的未來(lái) 55第9章 軟件測(cè)試新技術(shù) 569.1 正交試驗(yàn)設(shè)計(jì) 569.2 均勻試驗(yàn)設(shè)計(jì) 579.3 成對(duì)組合覆蓋 579.4 軟件測(cè)試的有效方法—確定軟件測(cè)試技術(shù) 589.6 軟件測(cè)試自動(dòng)化框架 61第10軟件工程新視角 6310.1 業(yè)發(fā)展：SOA與云計(jì)算相結(jié)合 6310.2 AgileSoftwareDevelopment（敏捷軟件開(kāi)發(fā)） 6310.3 極限編程 6510.4 可信軟件 71第1章 軟件工程技術(shù)發(fā)展思索1.1 軟件工程技術(shù)發(fā)展歷程30多年來(lái),軟件工程的研究和實(shí)踐取得了長(zhǎng)足的進(jìn)步,其中一些具有里程碑意義的進(jìn)展包括:?20世紀(jì)60年代末~70年代中期,在一系列高級(jí)語(yǔ)言應(yīng)用的基礎(chǔ)上,出現(xiàn)了結(jié)構(gòu)化程序設(shè)計(jì)技術(shù),并開(kāi)發(fā)了一些支持軟件開(kāi)發(fā)的工具.?20世紀(jì)70年代中期~80年代,計(jì)算機(jī)輔助軟件工程(CASE)成為研究熱點(diǎn),并開(kāi)發(fā)了一些對(duì)軟件技術(shù)發(fā)展具有深遠(yuǎn)影響的軟件工程環(huán)境.?20世紀(jì)80年代中期~90年代,出現(xiàn)了面向?qū)ο笳Z(yǔ)言和方法,并成為主流的軟件開(kāi)發(fā)技術(shù);開(kāi)展軟件過(guò)程及軟件過(guò)程改善的研究;注重軟件復(fù)用和軟件構(gòu)件技術(shù)的研究與實(shí)踐.軟件是客觀事物的一種反映,客觀世界的不斷變化促使軟件技術(shù)的不斷發(fā)展,這種事物發(fā)展規(guī)律促使軟件工程的產(chǎn)生和發(fā)展.我們僅從解決軟硬件的異構(gòu)性和各種軟件之間的異構(gòu)性角度,就可窺見(jiàn)軟件技術(shù)發(fā)展的一種途徑.如,為屏蔽計(jì)算機(jī)硬件之間的異構(gòu)性發(fā)展了操作系統(tǒng),為屏蔽操作系統(tǒng)之間和編程語(yǔ)言之間的異構(gòu)性出現(xiàn)了支撐軟件和中間件,為屏蔽不同中間件之間的異構(gòu)性發(fā)展了WebServices技術(shù)等等;隨著解決問(wèn)題的不斷深入,易用性和適應(yīng)性要求的不斷提升,以及軟件技術(shù)的不斷發(fā)展,還會(huì)出現(xiàn)更新、更復(fù)雜的異構(gòu)問(wèn)題,它的解決會(huì)促進(jìn)軟件技術(shù)的不斷發(fā)展.從學(xué)科角度來(lái)看,要不斷提煉所要解決問(wèn)題的概念,建立相應(yīng)的模型,并尋找處理方法,從而解決這些問(wèn)題的概念模型和處理問(wèn)題邏輯間的映射問(wèn)題,如圖1所示.1.2 軟件與軟件特征軟件是對(duì)客觀世界中問(wèn)題空間與解空間的具體描述,是客觀事物的一種反映,是知識(shí)的提煉和“固化”.客觀世界是不斷變化的,因此,構(gòu)造性和演化性是軟件的本質(zhì)特征.如何使軟件模型具有更強(qiáng)的表達(dá)能力、更符合人類的思維模式,即如何提升計(jì)算環(huán)境的抽象層次,在一定意義上來(lái)講,這緊緊圍繞了軟件的本質(zhì)特征——構(gòu)造性和演化性.在高級(jí)語(yǔ)言出現(xiàn)以前,匯編語(yǔ)言(機(jī)器語(yǔ)言)是編程的工具,表達(dá)軟件模型的基本概念(或語(yǔ)言構(gòu)造)是指令,表達(dá)模型處理邏輯的主要概念(機(jī)制)是順序和轉(zhuǎn)移.顯然,這一抽象層次是比較低的.高級(jí)語(yǔ)言的出現(xiàn),例如FORTRAN語(yǔ)言、PASCAL語(yǔ)言、C語(yǔ)言等,使用了變量、標(biāo)識(shí)符、表達(dá)式等概念作為語(yǔ)言的基本構(gòu)造,并使用3種基本控制結(jié)構(gòu)來(lái)表達(dá)軟件模型的計(jì)算邏輯,因此軟件開(kāi)發(fā)人員可以在一個(gè)更高的抽象層次上進(jìn)行程序設(shè)計(jì).隨后出現(xiàn)了一系列開(kāi)發(fā)范型和結(jié)構(gòu)化程序設(shè)計(jì)技術(shù),實(shí)現(xiàn)了模塊化的數(shù)據(jù)抽象和過(guò)程抽象,提高了人們表達(dá)客觀世界的抽象層次,并使開(kāi)發(fā)的軟件具有一定的構(gòu)造性和演化性.近20年來(lái),面向?qū)ο蟪绦蛟O(shè)計(jì)語(yǔ)言的誕生并逐步流行,為人們提供了一種以對(duì)象為基本計(jì)算單元,以消息傳遞為基本交互手段來(lái)表達(dá)的軟件模型.面向?qū)ο蠓椒ǖ膶?shí)質(zhì)是以擬人化的觀點(diǎn)來(lái)看待客觀世界,即客觀世界是由一系列對(duì)象構(gòu)成,這些對(duì)象之間的交互形成了客觀世界中各式各樣的系統(tǒng)[1].面向?qū)ο蠓椒ㄖ械母拍詈吞幚磉壿嫺咏藗兘鉀Q計(jì)算問(wèn)題的思維模式,使開(kāi)發(fā)的軟件具有更好的構(gòu)造性和演化性.目前,人們更加關(guān)注軟件復(fù)用問(wèn)題,構(gòu)建比對(duì)象粒度更大、更易于復(fù)用的基本單元——構(gòu)件,并研究以構(gòu)件復(fù)用為基礎(chǔ)的軟件構(gòu)造方法,更好地凸現(xiàn)軟件的構(gòu)造性和演化特性.易于復(fù)用的軟件,一定是具有很好構(gòu)造性和演化性的軟件.1.3 軟件工程的主要研究?jī)?nèi)容從某種角度來(lái)說(shuō),軟件開(kāi)發(fā)的本質(zhì)就是要實(shí)現(xiàn)“高層概念”到“低層概念”的映射,實(shí)現(xiàn)“高層處理邏輯”到“低層處理邏輯”的映射.對(duì)于大型軟件系統(tǒng)的開(kāi)發(fā),這一映射是相當(dāng)復(fù)雜的,涉及到有關(guān)人員、使用的技術(shù)、采取的途徑以及成本和進(jìn)度的約束,因此,我們可以把軟件工程定義為:軟件工程(softwareengineering)是應(yīng)用計(jì)算機(jī)科學(xué)理論和技術(shù)以及工程管理原則和方法,按照預(yù)算和進(jìn)度,實(shí)現(xiàn)滿足用戶要求的軟件產(chǎn)品的定義、開(kāi)發(fā)、發(fā)布和維護(hù)的工程或以之為研究對(duì)象的學(xué)科,軟件工程與其他工程一樣要有自己的目標(biāo)、活動(dòng)和原則,軟件工程框架可以概括為圖2所示的內(nèi)容.軟件工程的基本目標(biāo)是生產(chǎn)具有正確性、可用性及開(kāi)銷合宜(合算性)的產(chǎn)品.正確性意指軟件產(chǎn)品達(dá)到預(yù)期功能的程度;可用性意指軟件基本結(jié)構(gòu)、實(shí)現(xiàn)及文檔達(dá)到用戶可用的程度;開(kāi)銷合宜意指軟件開(kāi)發(fā)、運(yùn)行的整個(gè)開(kāi)銷滿足用戶的需求.以上目標(biāo)的實(shí)現(xiàn)不論在理論上還是在實(shí)踐中均存在很多問(wèn)題有待解決,制約了對(duì)過(guò)程、過(guò)程模型及工程方法的選取.軟件工程活動(dòng)是“生產(chǎn)一個(gè)最終滿足用戶需求且達(dá)到工程目標(biāo)的軟件產(chǎn)品所需要的步驟”,主要包括需求、設(shè)計(jì)、實(shí)現(xiàn)、確認(rèn)以及支持等活動(dòng).需求活動(dòng)是在一個(gè)抽象層上建立系統(tǒng)模型的活動(dòng),該活動(dòng)的主要產(chǎn)品是需求規(guī)約,是軟件開(kāi)發(fā)人員和客戶之間契約的基礎(chǔ),是設(shè)計(jì)的基本輸入.設(shè)計(jì)活動(dòng)定義實(shí)現(xiàn)需求規(guī)約所需的結(jié)構(gòu),該活動(dòng)的主要產(chǎn)品包括軟件體系結(jié)構(gòu)、詳細(xì)的處理算法等.實(shí)現(xiàn)活動(dòng)是設(shè)計(jì)規(guī)約到代碼轉(zhuǎn)換的活動(dòng).驗(yàn)證/確認(rèn)是一項(xiàng)評(píng)估活動(dòng),貫穿于整個(gè)開(kāi)發(fā)過(guò)程,包括動(dòng)態(tài)分析和靜態(tài)分析.主要技術(shù)有模型評(píng)審、代碼“走查”以及程序測(cè)試等.維護(hù)活動(dòng)是軟件發(fā)布之后所進(jìn)行的修改,包括對(duì)發(fā)現(xiàn)錯(cuò)誤的修正、對(duì)環(huán)境變化所進(jìn)行的必要調(diào)整等.圍繞工程設(shè)計(jì)、工程支持以及工程管理,提出以下軟件工程基本原則:第1條原則是選取適宜的開(kāi)發(fā)風(fēng)范.以保證軟件開(kāi)發(fā)的可持續(xù)性,并使最終的軟件產(chǎn)品滿足客戶的要求.第2條原則是采用合適的設(shè)計(jì)方法.支持模塊化、信息隱蔽、局部化、一致性、適應(yīng)性、構(gòu)造性、集成組裝性等問(wèn)題的解決和實(shí)現(xiàn),以達(dá)到軟件工程的目標(biāo).第3條原則是提供高質(zhì)量的工程支持.提供必要的工程支持,例如配置管理、質(zhì)量保證等工具和環(huán)境,以保證按期交付高質(zhì)量的軟件產(chǎn)品.第4條原則是有效的軟件工程管理.僅當(dāng)對(duì)軟件過(guò)程實(shí)施有效管理時(shí),才能實(shí)現(xiàn)有效的軟件工程.由以上軟件工程的概念和框架可以看出,軟件設(shè)計(jì)的主要目標(biāo)就是要實(shí)現(xiàn)好的結(jié)構(gòu),使開(kāi)發(fā)的軟件具有良好的構(gòu)造性和演化性.軟件工程學(xué)科所研究的內(nèi)容主要包括:軟件開(kāi)發(fā)范型、軟件設(shè)計(jì)方法、工程支持技術(shù)和工程管理技術(shù).其中,軟件開(kāi)發(fā)范型涉及軟件工程的“方向”問(wèn)題,研究正確的求解軟件的計(jì)算邏輯;軟件設(shè)計(jì)方法涉及軟件工程的“途徑”問(wèn)題,研究“高層概念模型和處理邏輯”到“低層概念模型和處理邏輯”的映射;工程支持技術(shù)和過(guò)程管理技術(shù)涉及工程過(guò)程質(zhì)量和產(chǎn)品質(zhì)量問(wèn)題,研究管理學(xué)理論在軟件工程中的應(yīng)用.如上所述,軟件開(kāi)發(fā)就是實(shí)施了一個(gè)從“高層概念模型”到“低層概念模型”的映射,從“高層處理邏輯”到“低層處理邏輯”的映射,而且在這一映射中還涉及到人員、技術(shù)、成本、進(jìn)度等要素,那么就必須研究映射模式即軟件生產(chǎn)模式問(wèn)題.分析傳統(tǒng)產(chǎn)業(yè)的發(fā)展,其基本模式均是符合標(biāo)準(zhǔn)的零部件(構(gòu)件)生產(chǎn)以及基于標(biāo)準(zhǔn)構(gòu)件的產(chǎn)品生產(chǎn)(組裝),其中,構(gòu)件是核心和基礎(chǔ),“復(fù)用”是必須的手段.實(shí)踐表明,這種模式是軟件開(kāi)發(fā)工程化、軟件生產(chǎn)工業(yè)化的必由之路[4].因此,軟件產(chǎn)業(yè)的發(fā)展并形成規(guī)模經(jīng)濟(jì),標(biāo)準(zhǔn)構(gòu)件的生產(chǎn)和構(gòu)件的復(fù)用是關(guān)鍵因素.實(shí)現(xiàn)軟件復(fù)用的關(guān)鍵因素(技術(shù)和非技術(shù)因素),如圖3所示,主要包括:軟件構(gòu)件技術(shù)(softwarecomponenttechnology)、領(lǐng)域工程(domainengineering)、軟件構(gòu)架(softwarearchitecture)、軟件再工程(softwarereengineering)、開(kāi)放系統(tǒng)(opensystem)、軟件過(guò)程(softwareprocess)、CASE技術(shù)等,以及各種非技術(shù)因素,且各種因素是相互聯(lián)系、相互影響的.近年來(lái)人們認(rèn)識(shí)到,要提高軟件開(kāi)發(fā)效率,提高軟件產(chǎn)品質(zhì)量,必須改變手工作坊式的開(kāi)發(fā)方法,采取工程化的開(kāi)發(fā)方法和工業(yè)化的生產(chǎn)技術(shù).青鳥(niǎo)工程“七五”期間,已提出了軟件生產(chǎn)線的概念和思想[6],其中將軟件的生產(chǎn)過(guò)程分成3類不同的生產(chǎn)車間,即應(yīng)用構(gòu)架生產(chǎn)車間、構(gòu)件生產(chǎn)車間和基于構(gòu)件、構(gòu)架復(fù)用的應(yīng)用集成組裝車間.軟件生產(chǎn)線的概念模式如圖4所示.由上述軟件生產(chǎn)線概念模式圖中可以看出,在軟件生產(chǎn)線中,軟件開(kāi)發(fā)人員被劃分為3類:構(gòu)件生產(chǎn)者、構(gòu)件庫(kù)管理者和構(gòu)件復(fù)用者.這3種角色所需完成的任務(wù)是不同的,構(gòu)件復(fù)用者負(fù)責(zé)進(jìn)行基于構(gòu)件的軟件開(kāi)發(fā),包括構(gòu)件查詢、構(gòu)件理解、適應(yīng)性修改、構(gòu)件組裝以及系統(tǒng)演化等.圖5給出了與上述概念圖相對(duì)應(yīng)的軟件生產(chǎn)線——生產(chǎn)過(guò)程模型.從圖4和圖5中可以看出,軟件生產(chǎn)線以軟件構(gòu)件/構(gòu)架技術(shù)為核心,其中的主要活動(dòng)體現(xiàn)在傳統(tǒng)的領(lǐng)域工程和應(yīng)用工程中,但賦予了它們新的內(nèi)容,并且通過(guò)構(gòu)件管理、再工程等環(huán)節(jié)將它們有機(jī)地銜接起來(lái).另外,軟件生產(chǎn)線中的每個(gè)活動(dòng)皆有相應(yīng)的方法和工具與之對(duì)應(yīng),并結(jié)合項(xiàng)目管理、組織管理等管理問(wèn)題,形成完整的軟件生產(chǎn)流程.1.4 軟件技術(shù)的發(fā)展趨勢(shì)Internet無(wú)疑是20世紀(jì)末偉大的技術(shù)進(jìn)展之一,為我們提供了一種全球范圍的信息基礎(chǔ)設(shè)施.這個(gè)不斷延伸的網(wǎng)絡(luò)基礎(chǔ)設(shè)施,形成了一個(gè)資源豐富的計(jì)算平臺(tái),構(gòu)成了人類社會(huì)的信息化、數(shù)字化基礎(chǔ),成為我們學(xué)習(xí)、生活和工作的必備環(huán)境.如何在未來(lái)Internet平臺(tái)上進(jìn)一步進(jìn)行資源整合,形成巨型的、高效的、可信的和統(tǒng)一的虛擬環(huán)境,使所有資源能夠高效、可信地為所有用戶服務(wù),成為軟件技術(shù)的研究熱點(diǎn).Internet平臺(tái)具有如下基本特征:無(wú)統(tǒng)一控制的“真”分布性;節(jié)點(diǎn)的高度自治性;節(jié)點(diǎn)鏈接的開(kāi)放性和動(dòng)態(tài)性;人、設(shè)備和軟件的多重異構(gòu)性;實(shí)體行為的不可預(yù)測(cè)性;運(yùn)行環(huán)境的潛在不安全性;使用方式的個(gè)性化和靈活性;網(wǎng)絡(luò)連接環(huán)境的多樣性等.因此,Internet平臺(tái)和環(huán)境的出現(xiàn),對(duì)軟件形態(tài)、技術(shù)發(fā)展、理論研究提出新的問(wèn)題,也提供了新的契機(jī).傳統(tǒng)軟件的開(kāi)發(fā)基于封閉的靜態(tài)平臺(tái),是自頂向下、逐步分解的過(guò)程,因此傳統(tǒng)軟件的開(kāi)發(fā),基本都是首先確定系統(tǒng)的范圍(即Scoping),然后實(shí)施分而治之的策略,整個(gè)開(kāi)發(fā)過(guò)程處于有序控制之下.而未來(lái)軟件系統(tǒng)的開(kāi)發(fā)所基于的平臺(tái)是一個(gè)有豐富基礎(chǔ)軟件資源但同時(shí)又是開(kāi)放、動(dòng)態(tài)和多變的框架,開(kāi)發(fā)活動(dòng)呈現(xiàn)為通過(guò)基礎(chǔ)軟件資源組合為基本系統(tǒng),然后經(jīng)歷由“無(wú)序”到“有序”的往復(fù)循環(huán)過(guò)程,是動(dòng)態(tài)目標(biāo)漸趨穩(wěn)態(tài).未來(lái)軟件基本模型由于所處平臺(tái)的特性和開(kāi)放應(yīng)用的需求而變得比任何傳統(tǒng)的計(jì)算模型都更為復(fù)雜,軟件生命周期由于“無(wú)序”到“有序”的循環(huán)而呈現(xiàn)出不同于傳統(tǒng)生命周期概念的“大生命周期概念”,程序正確性由于目標(biāo)的多樣化而表現(xiàn)為傳統(tǒng)正確性描述的一個(gè)偏序集,軟件體系結(jié)構(gòu)側(cè)重點(diǎn)從基于實(shí)體的結(jié)構(gòu)分解轉(zhuǎn)變?yōu)榛趨f(xié)同的實(shí)體聚合,軟件生產(chǎn)過(guò)程和環(huán)境的變化導(dǎo)致基于Internet的面向用戶的虛擬工廠的形成.由于軟件系統(tǒng)所基于的計(jì)算機(jī)硬件平臺(tái)正經(jīng)歷從集中封閉的計(jì)算平臺(tái)向開(kāi)放的Internet平臺(tái)的轉(zhuǎn)變,軟件系統(tǒng)作為計(jì)算機(jī)系統(tǒng)的核心,隨著其運(yùn)行環(huán)境的演變也經(jīng)歷了一系列的變革.目前,面向網(wǎng)絡(luò)的計(jì)算環(huán)境正由Client/Server發(fā)展為Client/Cluster,并正朝著Client/Network和Client/VirtualEnvironment的方向發(fā)展.那么,未來(lái)的基于Internet平臺(tái)的軟件系統(tǒng)又將會(huì)呈現(xiàn)出一個(gè)什么形態(tài)呢?從技術(shù)的角度來(lái)看,以軟件構(gòu)件等技術(shù)支持的軟件實(shí)體將以開(kāi)放、自主的方式存在于Internet的各個(gè)節(jié)點(diǎn)之上,任何一個(gè)軟件實(shí)體可在開(kāi)放的環(huán)境下通過(guò)某種方式加以發(fā)布,并以各種協(xié)同方式與其他軟件實(shí)體進(jìn)行跨網(wǎng)絡(luò)的互連、互通、協(xié)作和聯(lián)盟,從而形成一種與當(dāng)前的信息Web類似的SoftwareWeb.SoftwareWeb不再僅僅是信息的提供者,它還是各種服務(wù)(功能)的提供者.由于網(wǎng)絡(luò)環(huán)境的開(kāi)放與動(dòng)態(tài)性,以及用戶使用方式的個(gè)性化要求,從而決定了這樣一種SoftwareWeb,它應(yīng)能感知外部網(wǎng)絡(luò)環(huán)境的動(dòng)態(tài)變化,并隨著這種變化按照功能指標(biāo)、性能指標(biāo)和可信性指標(biāo)等進(jìn)行靜態(tài)的調(diào)整和動(dòng)態(tài)的演化,以使系統(tǒng)具有盡可能高的用戶信賴度.我們將具有這種新形態(tài)的軟件稱為網(wǎng)構(gòu)軟件(internetware).網(wǎng)構(gòu)軟件是在Internet開(kāi)放、動(dòng)態(tài)和多變環(huán)境下軟件系統(tǒng)基本形形態(tài)的獨(dú)有的基本特征[1]:(1)自主性:是指網(wǎng)構(gòu)軟件系統(tǒng)中的軟件實(shí)體具有相對(duì)獨(dú)立性、主動(dòng)性和自適應(yīng)性.自主性使其區(qū)別于傳統(tǒng)軟件系統(tǒng)中軟件實(shí)體的依賴性和被動(dòng)性;(2)協(xié)同性:是指網(wǎng)構(gòu)軟件系統(tǒng)中軟件實(shí)體之間可按多種靜態(tài)連接和動(dòng)態(tài)合作方式在開(kāi)放的網(wǎng)絡(luò)環(huán)境下加以互連、互通、協(xié)作和聯(lián)盟.協(xié)同性使其區(qū)別于傳統(tǒng)軟件系統(tǒng)在封閉集中環(huán)境下單一靜態(tài)的連接模式;(3)反應(yīng)性:是指網(wǎng)構(gòu)軟件具有感知外部運(yùn)行和使用環(huán)境并對(duì)系統(tǒng)演化提供有用信息的能力.反應(yīng)性使網(wǎng)構(gòu)軟件系統(tǒng)具備了適應(yīng)Internet開(kāi)放、動(dòng)態(tài)和多變環(huán)境的感知能力;(4)演化性:是指網(wǎng)構(gòu)軟件結(jié)構(gòu)可以根據(jù)應(yīng)用需求和網(wǎng)絡(luò)環(huán)境變化而發(fā)生動(dòng)態(tài)演化,主要表現(xiàn)在其實(shí)體元素?cái)?shù)目的可變性、結(jié)構(gòu)關(guān)系的可調(diào)節(jié)性和結(jié)構(gòu)形態(tài)的動(dòng)態(tài)可配置性上;演化性使網(wǎng)構(gòu)軟件系統(tǒng)具備了適應(yīng)Internet開(kāi)放、動(dòng)態(tài)和多變環(huán)境的應(yīng)變能力;(5)多態(tài)性:是指網(wǎng)構(gòu)軟件系統(tǒng)的效果體現(xiàn)出相容的多目標(biāo)性.它可以根據(jù)某些基本協(xié)同原則,在動(dòng)態(tài)變化的網(wǎng)絡(luò)環(huán)境下,滿足多種相容的目標(biāo)形態(tài).多態(tài)性使網(wǎng)構(gòu)軟件系統(tǒng)在網(wǎng)絡(luò)環(huán)境下具備了一定的柔性和滿足個(gè)性化需求的能力.綜上所述,Internet及其上應(yīng)用的快速發(fā)展與普及,使計(jì)算機(jī)軟件所面臨的環(huán)境開(kāi)始從靜態(tài)封閉逐步走向開(kāi)放、動(dòng)態(tài)和多變.軟件系統(tǒng)為了適應(yīng)這樣一種發(fā)展趨勢(shì),將會(huì)逐步呈現(xiàn)出柔性、多目標(biāo)、連續(xù)反應(yīng)式的網(wǎng)構(gòu)軟件系統(tǒng)的形態(tài).面對(duì)這種新型的軟件形態(tài),傳統(tǒng)的軟件理論、方法、技術(shù)和平臺(tái)面臨了一系列挑戰(zhàn).從宏觀上看,這種挑戰(zhàn)為我們研究軟件理論、方法和技術(shù)提供了難得的機(jī)遇,使我們有可能建立一套適合于Internet開(kāi)放、動(dòng)態(tài)和多變環(huán)境的新型軟件理論、方法和技術(shù)體系.從微觀的角度來(lái)看,Internet的發(fā)展將使系統(tǒng)軟件和支撐平臺(tái)的研究重點(diǎn)開(kāi)始從操作系統(tǒng)等轉(zhuǎn)向新型中間件平臺(tái),而網(wǎng)構(gòu)軟件的理論、方法和技術(shù)的突破必將導(dǎo)致在建立新型中間件平臺(tái)創(chuàng)新技術(shù)方面的突破.歸結(jié)起來(lái),網(wǎng)構(gòu)軟件理論、方法、技術(shù)和平臺(tái)的主要突破點(diǎn)在于實(shí)現(xiàn)如下轉(zhuǎn)變,即,從傳統(tǒng)軟件結(jié)構(gòu)到網(wǎng)構(gòu)軟件結(jié)構(gòu)的轉(zhuǎn)變,從系統(tǒng)目標(biāo)的確定性到多重不確定性的轉(zhuǎn)變,從實(shí)體單元的被動(dòng)性到主動(dòng)自主性的轉(zhuǎn)變,從協(xié)同方式的單一性到靈活多變性的轉(zhuǎn)變,從系統(tǒng)演化的靜態(tài)性到系統(tǒng)演化的動(dòng)態(tài)性的轉(zhuǎn)變,從基于實(shí)體的結(jié)構(gòu)分解到基于協(xié)同的實(shí)體聚合的轉(zhuǎn)變,從經(jīng)驗(yàn)驅(qū)動(dòng)的軟件手工開(kāi)發(fā)模式到知識(shí)驅(qū)動(dòng)的軟件自動(dòng)生成模式的轉(zhuǎn)變.建立這樣一種新型的理論、方法、技術(shù)和平臺(tái)體系具有兩個(gè)方面的重要性,一方面,從計(jì)算機(jī)軟件技術(shù)發(fā)展的角度,這種新型的理論、方法和技術(shù)將成為面向Internet計(jì)算環(huán)境的一套先進(jìn)的軟件工程方法學(xué)體系,為21世紀(jì)計(jì)算機(jī)軟件的發(fā)展構(gòu)造理論基礎(chǔ);另一方面,這種基于Internet計(jì)算環(huán)境上軟件的核心理論、方法和技術(shù),必將為我國(guó)在未來(lái)5~10年建立面向Internet的軟件產(chǎn)業(yè)打下堅(jiān)實(shí)的基礎(chǔ),為我國(guó)軟件產(chǎn)業(yè)的跨越式發(fā)展提供核心技術(shù)的支持.當(dāng)前的軟件技術(shù)發(fā)展遵循軟硬結(jié)合、應(yīng)用與系統(tǒng)結(jié)合的發(fā)展規(guī)律.“軟”是指件,“硬”是指微電子,要發(fā)展面向應(yīng)用,實(shí)現(xiàn)一體化;面向個(gè)人,體現(xiàn)個(gè)性化的系統(tǒng)和產(chǎn)品.軟件技術(shù)的總體發(fā)展趨勢(shì)可歸結(jié)為:軟件平臺(tái)網(wǎng)絡(luò)化、方法對(duì)象化、系統(tǒng)構(gòu)件化、產(chǎn)品家族化、開(kāi)發(fā)工程化、過(guò)程規(guī)范化、生產(chǎn)規(guī)模化、競(jìng)爭(zhēng)國(guó)際化.第2章 傳統(tǒng)的軟件工程過(guò)程2.1 什么是軟件生命周期軟件生命周期又稱為軟件生存周期或系統(tǒng)開(kāi)發(fā)生命周期，是軟件的產(chǎn)生直到報(bào)廢的生命周期，周期內(nèi)有問(wèn)題定義、可行性分析、總體描述、系統(tǒng)設(shè)計(jì)、編碼、調(diào)試和測(cè)試、驗(yàn)收與運(yùn)行、維護(hù)升級(jí)到廢棄等階段，這種按時(shí)間分程的思想方法是\o"軟件工程"軟件工程中的一種思想原則，即按部就班、逐步推進(jìn)，每個(gè)階段都要有定義、工作、審查、形成文檔以供交流或備查，以提高軟件的質(zhì)量。但隨著新的面向?qū)ο蟮脑O(shè)計(jì)方法和技術(shù)的成熟，軟件生命周期設(shè)計(jì)方法的指導(dǎo)意義正在逐步減少。生命周期的每一個(gè)周期都有確定的任務(wù)，并產(chǎn)生一定規(guī)格的文檔（資料），提交給下一個(gè)周期作為繼續(xù)工作的依據(jù)。按照軟件的生命周期，軟件的開(kāi)發(fā)不再只單單強(qiáng)調(diào)“編碼”，而是概括了軟件開(kāi)發(fā)的全過(guò)程。軟件工程要求每一周期工作的開(kāi)始只能必須是建立在前一個(gè)周期結(jié)果“正確”前提上的延續(xù)；因此，每一周期都是按“活動(dòng)──結(jié)果──審核──再活動(dòng)──直至結(jié)果正確”循環(huán)往復(fù)進(jìn)展的。2.2 軟件生命周期的六個(gè)階段1、問(wèn)題的定義及規(guī)劃此階段是軟件開(kāi)發(fā)方與需求方共同討論，主要確定軟件的開(kāi)發(fā)目標(biāo)及其可行性。2、需求分析在確定軟件開(kāi)發(fā)可行的情況下，對(duì)軟件需要實(shí)現(xiàn)的各個(gè)功能進(jìn)行詳細(xì)分析。需求分析階段是一個(gè)很重要的階段，這一階段做得好，將為整個(gè)軟件開(kāi)發(fā)\o"項(xiàng)目"項(xiàng)目的成功打下良好的基礎(chǔ)。"唯一不變的是變化本身。"，同樣需求也是在整個(gè)軟件開(kāi)發(fā)過(guò)程中不斷變化和深入的，因此我們必須制定需求變更計(jì)劃來(lái)應(yīng)付這種變化，以保護(hù)整個(gè)項(xiàng)目的順利進(jìn)行。\o"軟件生命周期之需求分析"3、軟件設(shè)計(jì)此階段主要根據(jù)需求分析的結(jié)果，對(duì)整個(gè)軟件系統(tǒng)進(jìn)行設(shè)計(jì)，如系統(tǒng)框架設(shè)計(jì)，數(shù)據(jù)庫(kù)設(shè)計(jì)等等。軟件設(shè)計(jì)一般分為總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)。好的軟件設(shè)計(jì)將為軟件程序編寫打下良好的基礎(chǔ)。4、程序編碼此階段是將軟件設(shè)計(jì)的結(jié)果轉(zhuǎn)換成計(jì)算機(jī)可運(yùn)行的程序代碼。在程序編碼中必須要制定統(tǒng)一，符合標(biāo)準(zhǔn)的編寫規(guī)范。以保證程序的可讀性，易維護(hù)性，提高程序的運(yùn)行效率。5、軟件測(cè)試在軟件設(shè)計(jì)完成后要經(jīng)過(guò)嚴(yán)密的測(cè)試，以發(fā)現(xiàn)軟件在整個(gè)設(shè)計(jì)過(guò)程中存在的問(wèn)題并加以糾正。整個(gè)測(cè)試過(guò)程分單元測(cè)試、組裝測(cè)試以及系統(tǒng)測(cè)試三個(gè)階段進(jìn)行。測(cè)試的方法主要有白盒測(cè)試和黑盒測(cè)試兩種。在測(cè)試過(guò)程中需要建立詳細(xì)的測(cè)試計(jì)劃并嚴(yán)格按照測(cè)試計(jì)劃進(jìn)行測(cè)試，以減少測(cè)試的隨意性。6、運(yùn)行維護(hù)軟件維護(hù)是軟件生命周期中持續(xù)時(shí)間最長(zhǎng)的階段。在軟件開(kāi)發(fā)完成并投入使用后，由于多方面的原因，軟件不能繼續(xù)適應(yīng)用戶的要求。要延續(xù)軟件的使用壽命，就必須對(duì)軟件進(jìn)行維護(hù)。軟件的維護(hù)包括糾錯(cuò)性維護(hù)和改進(jìn)性維護(hù)兩個(gè)方面。2.3 軟件生命周期的模型任何軟件都是從最模糊的概念開(kāi)始的：為某個(gè)公司設(shè)計(jì)辦公的流程處理；設(shè)計(jì)一種商務(wù)信函打印系統(tǒng)并投放市場(chǎng)。這個(gè)概念是不清晰的，但卻是最高層的業(yè)務(wù)需求的原型。這個(gè)概念都會(huì)伴隨著一個(gè)目的，例如在一個(gè)“銀行\(zhòng)o"押匯"押匯系統(tǒng)”的目的是提高工作的效率。這個(gè)目的將會(huì)成為系統(tǒng)的核心思想，系統(tǒng)成敗的評(píng)判標(biāo)準(zhǔn)。1999年政府部門上了大量的OA系統(tǒng)（辦公自動(dòng)化系統(tǒng)），學(xué)過(guò)一點(diǎn)LotusNotes（LotusNotes是功能強(qiáng)大的多界面的Windows軟件，它使人們能高效地協(xié)同工作。使用Notes人們可以突破平臺(tái)技術(shù)組織和地理的限制，LotusNotes非常好用，通常要由許多應(yīng)用程序來(lái)完成的任務(wù)，用Notes一次即可完成。）的人都發(fā)了財(cái)（\o"IBM"IBM更不用說(shuō)了），但是更普遍的情況是，許多的政府部門原有的處理模式并沒(méi)有變化，反而又加上了自動(dòng)化處理的一套流程。提高工作效率的初衷卻導(dǎo)致了完全不同的結(jié)果。這樣的軟件究竟是不是成功的呢？從概念提出的那一刻開(kāi)始，軟件產(chǎn)品就進(jìn)入了軟件生命周期。在經(jīng)歷需求、分析、設(shè)計(jì)、實(shí)現(xiàn)、部署后，軟件將被使用并進(jìn)入維護(hù)階段，直到最后由于缺少維護(hù)費(fèi)用而逐漸消亡。這樣的一個(gè)過(guò)程，稱為“生命周期模型”（LifeCycleModel）。典型的幾種生命周期模型包括\o"瀑布模型"瀑布模型、\o"快速原型模型"快速原型模型、\o"迭代模型"迭代模型。瀑布模型（WaterfallModel）首先由\o"溫斯頓·羅伊斯"溫斯頓·羅伊斯（WinstonRoyce）提出。該模型由于酷似瀑布聞名。在該模型中，首先確定需求，并接受客戶和軟件質(zhì)量保證（SQA）小組的驗(yàn)證。然后擬定規(guī)格說(shuō)明，同樣通過(guò)驗(yàn)證后，進(jìn)入計(jì)劃階段…可以看出，瀑布模型中至關(guān)重要的一點(diǎn)是只有當(dāng)一個(gè)階段的文檔已經(jīng)編制好并獲得軟件質(zhì)量保證小組的認(rèn)可才可以進(jìn)入下一個(gè)階段。這樣，瀑布模型通過(guò)強(qiáng)制性的要求提供規(guī)約文檔來(lái)確保每個(gè)階段都能很好的完成任務(wù)。但是實(shí)際上往往難以辦到，因?yàn)檎麄€(gè)的模型幾乎都是以文檔驅(qū)動(dòng)的，這對(duì)于非專業(yè)的用戶來(lái)說(shuō)是難以閱讀和理解的。想象一下，你去買衣服的時(shí)候，售貨員給你出示的是一本厚厚的服裝規(guī)格說(shuō)明，你會(huì)有什么樣的感觸。雖然瀑布模型有很多很好的思想可以借鑒，但是在過(guò)程能力上有天生的缺陷。迭代式模型是\o"RUP"RUP（RationalUnifiedProcess，統(tǒng)一軟件開(kāi)發(fā)過(guò)程，統(tǒng)一軟件過(guò)程)推薦的周期模型。在RUP中，迭代被定義為：迭代包括產(chǎn)生產(chǎn)品發(fā)布（穩(wěn)定、可執(zhí)行的產(chǎn)品版本）的全部開(kāi)發(fā)活動(dòng)和要使用該發(fā)布必需的所有其他外圍元素。所以，在某種程度上，開(kāi)發(fā)迭代是一次完整地經(jīng)過(guò)所有工作流程的過(guò)程：（至少包括）需求工作流程、分析設(shè)計(jì)工作流程、實(shí)施工作流程和測(cè)試工作流程。實(shí)質(zhì)上，它類似小型的瀑布式項(xiàng)目。RUP認(rèn)為，所有的階段（需求及其它）都可以細(xì)分為迭代。每一次的迭代都會(huì)產(chǎn)生一個(gè)可以發(fā)布的產(chǎn)品，這個(gè)產(chǎn)品是最終產(chǎn)品的一個(gè)子集。迭代的思想如下圖所示。迭代和瀑布的最大的差別就在于風(fēng)險(xiǎn)的暴露時(shí)間上。“任何項(xiàng)目都會(huì)涉及到一定的風(fēng)險(xiǎn)。如果能在生命周期中盡早確保避免了風(fēng)險(xiǎn)，那么您的計(jì)劃自然會(huì)更趨精確。有許多風(fēng)險(xiǎn)直到已準(zhǔn)備集成系統(tǒng)時(shí)才被發(fā)現(xiàn)。不管開(kāi)發(fā)團(tuán)隊(duì)經(jīng)驗(yàn)如何，都絕不可能預(yù)知所有的風(fēng)險(xiǎn)?！保≧UP）二者的區(qū)別如下圖所示：由于瀑布模型的特點(diǎn)（文檔是主體），很多的問(wèn)題在最后才會(huì)暴露出來(lái)，為了解決這些問(wèn)題的風(fēng)險(xiǎn)是巨大的。“在迭代式生命周期中，您需要根據(jù)主要風(fēng)險(xiǎn)列表選擇要在迭代中開(kāi)發(fā)的新的增量?jī)?nèi)容。每次迭代完成時(shí)都會(huì)生成一個(gè)經(jīng)過(guò)測(cè)試的可執(zhí)行文件，這樣就可以核實(shí)是否已經(jīng)降低了目標(biāo)風(fēng)險(xiǎn)?！笨焖僭停≧apidPrototype）模型在功能上等價(jià)于產(chǎn)品的一個(gè)子集。注意，這里說(shuō)的是功能上。瀑布模型的缺點(diǎn)就在于不夠直觀，快速原型法就解決了這個(gè)問(wèn)題。一般來(lái)說(shuō)，根據(jù)客戶的需要在很短的時(shí)間內(nèi)解決用戶最迫切需要，完成一個(gè)可以演示的產(chǎn)品。這個(gè)產(chǎn)品只是實(shí)現(xiàn)部分的功能（最重要的）。它最重要的目的是為了確定用戶的真正需求。在我的經(jīng)驗(yàn)中，這種方法非常的有效，原先對(duì)計(jì)算機(jī)沒(méi)有絲毫概念的用戶在你的原型面前往往口若懸河，有些觀點(diǎn)讓你都覺(jué)得非常的吃驚。在得到用戶的需求之后，原型將被拋棄。因?yàn)樵烷_(kāi)發(fā)的速度很快，設(shè)計(jì)方面是幾乎沒(méi)有考慮的，如果保留原型的話，在隨后的開(kāi)發(fā)中會(huì)為此付出極大的代價(jià)。至于保留原型方面，也是有一種叫做\o"增量模型"增量模型是這么做的，但這種模型并不為大家所接受。事實(shí)上，其實(shí)現(xiàn)在的軟件組織中很少說(shuō)標(biāo)準(zhǔn)的采用那一種模型的。模型和實(shí)用還是有很大的區(qū)別。軟件生命周期模型的發(fā)展實(shí)際上是體現(xiàn)了軟件工程理論的發(fā)展。在最早的時(shí)候，軟件的生命周期處于無(wú)序、混亂的情況。一些人為了能夠控制軟件的開(kāi)發(fā)過(guò)程，就把軟件開(kāi)發(fā)嚴(yán)格的區(qū)分為多個(gè)不同的階段，并在階段間加上嚴(yán)格的審查。這就是瀑布模型產(chǎn)生的起因。瀑布模型體現(xiàn)了人們對(duì)軟件過(guò)程的一個(gè)希望：嚴(yán)格控制、確保質(zhì)量?？上У氖牵F(xiàn)實(shí)往往是殘酷的。瀑布模型根本達(dá)不到這個(gè)過(guò)高的要求，因?yàn)檐浖倪^(guò)程往往難于預(yù)測(cè)。反而導(dǎo)致了其它的負(fù)面影響，例如大量的文檔、繁瑣的審批。因此人們就開(kāi)始嘗試著用其它的方法來(lái)改進(jìn)或替代瀑布方法。例如把過(guò)程細(xì)分來(lái)增加過(guò)程的可預(yù)測(cè)性。第3章軟件工程之面向?qū)ο蠹夹g(shù)概述八十年代末以來(lái)，隨著面向?qū)ο蠹夹g(shù)成為研究的熱點(diǎn)出現(xiàn)了幾十種支持軟件開(kāi)

發(fā)的面向?qū)ο蠓椒?。其中，Booch,

Coad/Yourdon,OMT和Jacobson的方法在面向?qū)ο筌浖_(kāi)發(fā)界得到了廣泛的認(rèn)可，特別值得一提的是統(tǒng)一建模語(yǔ)言UML

（Unified

Modeling

Language），該方法結(jié)合了Booch,

OMT,

和Jacobson方法

的優(yōu)點(diǎn)，統(tǒng)一了符號(hào)體系，并從其它的方法和工程實(shí)踐中吸收了許多經(jīng)過(guò)實(shí)際檢驗(yàn)

的概念和技術(shù)。UML方法自去年提出后到現(xiàn)在已發(fā)展到1.1版，并已提交給對(duì)象管

理集團(tuán)OMG，申請(qǐng)成為面向?qū)ο蠓椒ǖ臉?biāo)準(zhǔn)。面向?qū)ο蠓椒ǘ贾С秩N基本的活動(dòng)：識(shí)別對(duì)象和類，描述對(duì)象和類之間的關(guān)

系，以及通過(guò)描述每個(gè)類的功能定義對(duì)象的行為。為了發(fā)現(xiàn)對(duì)象和類，開(kāi)發(fā)人員要在系統(tǒng)需求和系統(tǒng)分析的文檔中查找名詞和名

詞短語(yǔ)，包括可感知的事物（汽車、壓力、傳感器）；角色（母親、教師、政治

家）；事件（著陸、中斷、請(qǐng)求）；互相作用（借貸、開(kāi)會(huì)、交叉）；人員；場(chǎng)所；組織；設(shè)備；和地點(diǎn)。通過(guò)瀏覽使用系統(tǒng)的腳本發(fā)現(xiàn)重要的對(duì)象和其責(zé)任，是

面向?qū)ο蠓治龊驮O(shè)計(jì)過(guò)程的初期重要的技術(shù)。

當(dāng)重要的對(duì)象被發(fā)現(xiàn)后，通過(guò)一組互相關(guān)聯(lián)的模型詳細(xì)表示類之間的關(guān)系和對(duì)

象的行為，這些模型從四個(gè)不同的側(cè)面表示了軟件的體系結(jié)構(gòu)：靜態(tài)邏輯、動(dòng)態(tài)邏

輯、靜態(tài)物理和動(dòng)態(tài)物理。

靜態(tài)邏輯模型描述實(shí)例化（類成員關(guān)系）、關(guān)聯(lián)、聚集（整體/部分）、和一

般化（繼承）等關(guān)系。這被稱為對(duì)象模型。一般化關(guān)系表示屬性和方法的繼承關(guān)

系。定義對(duì)象模型的圖形符號(hào)體系通常是從用于數(shù)據(jù)建模的實(shí)體關(guān)系圖導(dǎo)出的。對(duì)設(shè)計(jì)十分重要的約束，如基數(shù)（一對(duì)一、一對(duì)多、多對(duì)多），也在對(duì)象模型中表

示。動(dòng)態(tài)邏輯模型描述對(duì)象之間的互相作用。互相作用通過(guò)一組協(xié)同的對(duì)象，對(duì)象

之間消息的有序的序列，參與對(duì)象的可見(jiàn)性定義，來(lái)定義系統(tǒng)運(yùn)行時(shí)的行為。Booch方法中的對(duì)象交互作用圖被用來(lái)描述重要的互相作用，顯示參與的對(duì)象和對(duì)

象之間按時(shí)間排序的消息?？梢?jiàn)性圖用來(lái)描述互相作用中對(duì)象的可見(jiàn)性。對(duì)象的可

見(jiàn)性定義了一個(gè)對(duì)象如何處于向它發(fā)送消息的方法的作用域之中。例如，它可以是

方法的參數(shù)、局部變量、新的對(duì)象、或當(dāng)前執(zhí)行方法的對(duì)象的部分。

靜態(tài)物理模型通過(guò)模塊描述代碼的布局。動(dòng)態(tài)物理模型描述軟件的進(jìn)程和線程

體系結(jié)構(gòu)。

八十年代末以來(lái)，隨著面向?qū)ο蠹夹g(shù)成為研究的熱點(diǎn)出現(xiàn)了幾十種支持軟件開(kāi)

發(fā)的面向?qū)ο蠓椒?。其中，Booch,

Coad/Yourdon,

OMT,

和Jacobson的方法在面

向?qū)ο筌浖_(kāi)發(fā)界得到了廣泛的認(rèn)可。特別值得一提的是統(tǒng)一的建模語(yǔ)言UML

（Unified

Modeling

Language），該方法結(jié)合了Booch,

OMT,

和Jacobson方法

的優(yōu)點(diǎn)，統(tǒng)一了符號(hào)體系，并從其它的方法和工程實(shí)踐中吸收了許多經(jīng)過(guò)實(shí)際檢驗(yàn)

的概念和技術(shù)。UML方法自去年提出后到現(xiàn)在已發(fā)展到1.1版，并已提交給對(duì)象管

理集團(tuán)OMG，申請(qǐng)成為面向?qū)ο蠓椒ǖ臉?biāo)準(zhǔn)。面向?qū)ο蠓椒ǘ贾С秩N基本的活動(dòng)：識(shí)別對(duì)象和類，描述對(duì)象和類之間的關(guān)

系，以及通過(guò)描述每個(gè)類的功能定義對(duì)象的行為。

為了發(fā)現(xiàn)對(duì)象和類，開(kāi)發(fā)人員要在系統(tǒng)需求和系統(tǒng)分析的文檔中查找名詞和名

詞短語(yǔ)，包括可感知的事物（汽車、壓力、傳感器）；角色（母親、教師、政治

家）；事件（著陸、中斷、請(qǐng)求）；互相作用（借貸、開(kāi)會(huì)、交叉）；人員；場(chǎng)

所；組織；設(shè)備；和地點(diǎn)。通過(guò)瀏覽使用系統(tǒng)的腳本發(fā)現(xiàn)重要的對(duì)象和其責(zé)任，是

面向?qū)ο蠓治龊驮O(shè)計(jì)過(guò)程的初期重要的技術(shù)。

當(dāng)重要的對(duì)象被發(fā)現(xiàn)后，通過(guò)一組互相關(guān)聯(lián)的模型詳細(xì)表示類之間的關(guān)系和對(duì)

象的行為，這些模型從四個(gè)不同的側(cè)面表示了軟件的體系結(jié)構(gòu)：靜態(tài)邏輯、動(dòng)態(tài)邏

輯、靜態(tài)物理和動(dòng)態(tài)物理。

靜態(tài)邏輯模型描述實(shí)例化（類成員關(guān)系）、關(guān)聯(lián)、聚集（整體/部分）、和一

般化（繼承）等關(guān)系。這被稱為對(duì)象模型。一般化關(guān)系表示屬性和方法的繼承關(guān)

系。定義對(duì)象模型的圖形符號(hào)體系通常是從用于數(shù)據(jù)建模的實(shí)體關(guān)系圖導(dǎo)出的。對(duì)

計(jì)十分重要的約束，如基數(shù)（一對(duì)一、一對(duì)多、多對(duì)多），也在對(duì)象模型中表

示。

動(dòng)態(tài)邏輯模型描述對(duì)象之間的互相作用。互相作用通過(guò)一組協(xié)同的對(duì)象，對(duì)象

之間消息的有序的序列，參與對(duì)象的可見(jiàn)性定義，來(lái)定義系統(tǒng)運(yùn)行時(shí)的行為。

Booch方法中的對(duì)象交互作用圖被用來(lái)描述重要的互相作用，顯示參與的對(duì)象和對(duì)象之間按時(shí)間排序的消息。可見(jiàn)性圖用來(lái)描述互相作用中對(duì)象的可見(jiàn)性。對(duì)象的可

見(jiàn)性定義了一個(gè)對(duì)象如何處于向它發(fā)送消息的方法的作用域之中。例如，它可以是

方法的參數(shù)、局部變量、新的對(duì)象、或當(dāng)前執(zhí)行方法的對(duì)象的部分。

靜態(tài)物理模型通過(guò)模塊描述代碼的布局。動(dòng)態(tài)物理模型描述軟件的進(jìn)程和線程體系結(jié)構(gòu)。第4章 面向?qū)ο筌浖こ谭椒▽W(xué)實(shí)踐兩位研究面向?qū)ο筌浖こ痰拿绹?guó)學(xué)者(StaveHalladay和MichaelWiebel)曾這樣說(shuō)：“一般的面向?qū)ο缶幊?OOP)思路不過(guò)是一批烏合之眾，把靈機(jī)一動(dòng)、隨機(jī)應(yīng)變的技巧用于他們絞盡腦汁抽象出來(lái)的‘對(duì)象’而已。即使是最優(yōu)秀的OOP程序員，他們所能對(duì)付的極限也莫過(guò)于中等規(guī)模的開(kāi)發(fā)項(xiàng)目。倘若程序員經(jīng)驗(yàn)不足，系統(tǒng)規(guī)模又很大，那么采用OOP只能把你引入漫無(wú)邊際的泥沼之中。”

一方面是幾乎沒(méi)有一位軟件工程學(xué)者認(rèn)為OOP是完美無(wú)缺的，另一方面是OOP勢(shì)如破竹，近乎每一種最新推出的程序開(kāi)發(fā)工具或語(yǔ)言都采用了OOP思路;一方面是越來(lái)越多的“烏合之眾”在毫無(wú)章法、隨心所欲地處理著“對(duì)象”，另一方面是經(jīng)過(guò)近30年的積累已經(jīng)擁有了最大多數(shù)用戶的結(jié)構(gòu)化軟件方法的日漸萎縮……面對(duì)這一現(xiàn)實(shí)，研究軟件工程方法學(xué)的專家們紛紛指出：“當(dāng)前擺在軟件開(kāi)發(fā)方法學(xué)面前的一個(gè)重要課題是：從理論上理解OOP具有強(qiáng)大生命力的天然合理性，并完善面向?qū)ο筌浖こ谭椒▽W(xué)體系?！币荒陙?lái)我們通過(guò)國(guó)內(nèi)外一些實(shí)用系統(tǒng)的開(kāi)發(fā)實(shí)踐，對(duì)面向?qū)ο蟮能浖こ谭椒ㄟM(jìn)行了較為深入的學(xué)習(xí)和探討，特別是在北京市公路局計(jì)算機(jī)系統(tǒng)的一期工程實(shí)踐中，借鑒國(guó)外軟件設(shè)計(jì)經(jīng)驗(yàn)，較系統(tǒng)地采用了面向?qū)ο筌浖こ谭椒ǎ芤娣藴\。4.1是“設(shè)計(jì)主導(dǎo)”還是“程序主導(dǎo)”在一個(gè)系統(tǒng)開(kāi)發(fā)過(guò)程中是只采用OOP還是采用了OOSE(面向?qū)ο筌浖こ?方法，關(guān)鍵看整個(gè)開(kāi)發(fā)過(guò)程是“設(shè)計(jì)主導(dǎo)”還是“程序主導(dǎo)”。近年來(lái)，大量先進(jìn)程序開(kāi)發(fā)工具進(jìn)入我國(guó)，這對(duì)提高軟件開(kāi)發(fā)效率無(wú)疑具有很大的作用。然而，它們又往往使程序主導(dǎo)型軟件開(kāi)發(fā)人員在“以程序代系統(tǒng)”、“以算法代設(shè)計(jì)”的誤區(qū)里越陷越深。一般的軟件開(kāi)發(fā)人員(包括那些只見(jiàn)程序不見(jiàn)系統(tǒng)的程序員)主觀上都認(rèn)為：軟件開(kāi)發(fā)不應(yīng)“系統(tǒng)設(shè)計(jì)主導(dǎo)”而應(yīng)“程序算法主導(dǎo)”。但是用下面幾個(gè)問(wèn)題考察一下，結(jié)果往往相反。問(wèn)題1在進(jìn)行軟件設(shè)計(jì)和選擇軟件開(kāi)發(fā)工具之前，是否進(jìn)行開(kāi)發(fā)方法學(xué)的選擇?所謂方法學(xué)是指組織軟件生產(chǎn)過(guò)程的一系列方法、技術(shù)和規(guī)范。方法學(xué)是軟件開(kāi)發(fā)者長(zhǎng)年失敗和成功經(jīng)驗(yàn)的理論性總結(jié)，從軟件重用的思路來(lái)說(shuō)，方法學(xué)重用的價(jià)值遠(yuǎn)非某些程序組件重用可比。以北京市公路局系統(tǒng)為例。首先，在系統(tǒng)調(diào)查階段我們了解到：這個(gè)系統(tǒng)要分期(遞增式)開(kāi)發(fā)。由于處于機(jī)構(gòu)改革時(shí)期，系統(tǒng)生存期內(nèi)的用戶需求和系統(tǒng)結(jié)構(gòu)變因很多。這表明目標(biāo)系統(tǒng)應(yīng)該具有較強(qiáng)的可維護(hù)性，即每期開(kāi)發(fā)成果應(yīng)在后續(xù)工程中具有較高的可重用率。其次，一期工程的工作量相當(dāng)大(最后成果包括124個(gè)模塊、72類報(bào)表、119個(gè)數(shù)據(jù)庫(kù)表、439個(gè)窗口、912個(gè)數(shù)據(jù)窗口)，而開(kāi)發(fā)者對(duì)公路局業(yè)務(wù)不了解，多為經(jīng)驗(yàn)不足的大學(xué)生，理解需求的能力較低。這表明采用的開(kāi)發(fā)方法學(xué)必須能最大限度地減少重復(fù)勞動(dòng)，實(shí)現(xiàn)開(kāi)發(fā)過(guò)程中的成果共享和重用;必須能支持消除需求理解誤差的調(diào)整工序，使下游成品階段的設(shè)計(jì)變更比較容易進(jìn)行。在開(kāi)發(fā)此系統(tǒng)之前，我們承接了一個(gè)國(guó)外軟件的下游開(kāi)發(fā)任務(wù)。由于它采用了面向?qū)ο蟮能浖O(shè)計(jì)，使我們深刻認(rèn)識(shí)到國(guó)內(nèi)外軟件開(kāi)發(fā)方法學(xué)和技術(shù)上的差距，頗受啟發(fā)。參照我們承接的國(guó)外軟件開(kāi)發(fā)工作量計(jì)算方法，即僅下游120個(gè)模塊(含報(bào)表)的編碼和測(cè)試為41人月，那么公路局系統(tǒng)從上游設(shè)計(jì)開(kāi)始近200個(gè)模塊和報(bào)表、100多個(gè)數(shù)據(jù)庫(kù)表的開(kāi)發(fā)工作量至少也應(yīng)在120人月以上。由于采用了面向?qū)ο蟮能浖こ谭椒?，盡管開(kāi)發(fā)人員大多經(jīng)驗(yàn)不足，但是第一期工程總工時(shí)最終仍控制在80人月以內(nèi)，降低成本1/3左右。同時(shí)在系統(tǒng)可維護(hù)性、重用度及其他功能和性能指標(biāo)上，均超過(guò)了我們以往采用結(jié)構(gòu)化方法開(kāi)發(fā)的系統(tǒng)。對(duì)停留在程序主導(dǎo)級(jí)開(kāi)發(fā)的軟件開(kāi)發(fā)人員來(lái)說(shuō)，他們選擇OOP的原因也往往是被動(dòng)的。其實(shí)，在程序主導(dǎo)開(kāi)發(fā)者的辭典中是找不到“方法學(xué)”這一詞的，或者把“方法學(xué)”與“程序算法”混為一談。至于把OOP看成是OOSE的全部就更不足為怪了。問(wèn)題2對(duì)象抽象的出發(fā)點(diǎn)是現(xiàn)實(shí)世界的問(wèn)題描述，還是可執(zhí)行的實(shí)例對(duì)象?在現(xiàn)實(shí)世界早期抽象階段，面向?qū)ο蠓椒ㄅc其他方法區(qū)別并不大，都要從現(xiàn)實(shí)世界的問(wèn)題描述出發(fā)，即從用戶接口、問(wèn)題領(lǐng)域的知識(shí)和經(jīng)驗(yàn)出發(fā)，構(gòu)筑現(xiàn)實(shí)世界的問(wèn)題模型，也就是確定目標(biāo)系統(tǒng)是“做什么的”。面向?qū)ο蟮膯?wèn)題分析模型從3個(gè)側(cè)面進(jìn)行描述，即對(duì)象模型(對(duì)象的靜態(tài)結(jié)構(gòu))、動(dòng)態(tài)模型(對(duì)象相互作用的順序)和功能模型(數(shù)據(jù)變換及功能依存關(guān)系)。軟件工程的抽象原則、層次原則和分割原則同樣適用于面向?qū)ο蠓椒ǎ磳?duì)象抽象與功能抽象原則是一樣的，也是從高級(jí)到低級(jí)、從邏輯到物理，逐級(jí)細(xì)分。每一級(jí)抽象都重復(fù)對(duì)象建模(對(duì)象識(shí)別)→動(dòng)態(tài)建模(事件識(shí)別)→功能建模(操作識(shí)別)的過(guò)程，直到每一個(gè)對(duì)象實(shí)例在物理(程序編碼)上全部實(shí)現(xiàn)。對(duì)象抽象是從邏輯級(jí)還是物理級(jí)出發(fā)，與開(kāi)發(fā)前是否進(jìn)行方法學(xué)選擇一樣，也是區(qū)分OOSE與OOP的試金石。由于許多工具或語(yǔ)言(如PB、C++、Motif)都支持OOP，使一些程序級(jí)系統(tǒng)開(kāi)發(fā)人員可以很方便地不經(jīng)過(guò)邏輯抽象就直接開(kāi)發(fā)物理對(duì)象，在早期階段意識(shí)不到從物理層即實(shí)例對(duì)象出發(fā)進(jìn)行系統(tǒng)開(kāi)發(fā)的禍患，孰不知正是這種隨心所欲的OOP不僅無(wú)法發(fā)揮面向?qū)ο蠓椒☉?yīng)有的優(yōu)越性，而且還會(huì)給開(kāi)發(fā)后期帶來(lái)大量返工作業(yè)。和以往采用結(jié)構(gòu)化方法一樣，我們?cè)谙到y(tǒng)設(shè)計(jì)階段也引入了原型化方法，以便用系統(tǒng)樣品即原型與用戶對(duì)話，求得對(duì)需求理解的勾通，避免或減少后期返工。大多OOP工具都為開(kāi)發(fā)原型提供便利，問(wèn)題在于原型與最終產(chǎn)品間的關(guān)系，即原型是邏輯對(duì)象還是物理對(duì)象的樣品。若是后者，那就等同于最終產(chǎn)品。在木已成舟時(shí)再讓用戶評(píng)審，若發(fā)現(xiàn)問(wèn)題，要么推倒重來(lái)，要么強(qiáng)迫用戶削足適履。事實(shí)上，我們?yōu)樵O(shè)計(jì)評(píng)審而基于邏輯對(duì)象開(kāi)發(fā)的原型，相當(dāng)部分被用戶否決。但由于尚未進(jìn)行對(duì)象實(shí)例即物理級(jí)開(kāi)發(fā)，而是使用超類對(duì)象原型統(tǒng)一模擬對(duì)象事件和操作，所以無(wú)論是對(duì)象模型、動(dòng)態(tài)模型還是功能模型，修改起來(lái)都不困難。問(wèn)題3設(shè)計(jì)階段是否先設(shè)計(jì)超類，是否在實(shí)例對(duì)象設(shè)計(jì)開(kāi)始之前完成超類對(duì)象的實(shí)現(xiàn)?面向?qū)ο蠓椒ㄩ_(kāi)發(fā)出的軟件具有較強(qiáng)的可重用性，這種重用包括開(kāi)發(fā)項(xiàng)目?jī)?nèi)部的重用和外部的重用。重用依存于超類設(shè)計(jì)，沒(méi)有超類的對(duì)象系統(tǒng)好比“把洗衣機(jī)當(dāng)米缸”，不能物盡其用。超類設(shè)計(jì)的好與不好，首先看其內(nèi)部重用率的高低，內(nèi)部重用率高，必然外部重用率也高。由于系統(tǒng)開(kāi)發(fā)工期緊、工作量大，而我們的開(kāi)發(fā)隊(duì)伍年輕，經(jīng)驗(yàn)和人力都不足，內(nèi)部重用率高的超類開(kāi)發(fā)無(wú)疑是我們的救星。它可以減少重復(fù)勞動(dòng),易于統(tǒng)一規(guī)格,對(duì)復(fù)雜問(wèn)題統(tǒng)一攻關(guān)、統(tǒng)一解決,便于統(tǒng)一維護(hù)。對(duì)超類的抽象即實(shí)例對(duì)象的泛化原則，我們是從下面幾個(gè)方面考慮的：(1)尋找大多數(shù)實(shí)例對(duì)象的共同行為。例如“打印報(bào)表”、“查詢靜態(tài)代碼表”、“錄入數(shù)據(jù)庫(kù)表數(shù)據(jù)”等。(2)超類的多態(tài)性設(shè)計(jì)要保證使用超類繼承關(guān)系可以滿足各子類的操作要求。例如，繼承同一個(gè)“數(shù)據(jù)錄入”祖先窗口，可以完成不同結(jié)構(gòu)數(shù)據(jù)庫(kù)表的數(shù)據(jù)錄入。(3)利于信息的隱蔽性，不會(huì)破壞數(shù)據(jù)的完整性，利于將復(fù)雜問(wèn)題簡(jiǎn)單化。例如，對(duì)具有復(fù)雜關(guān)系、結(jié)構(gòu)及相關(guān)存取操作的數(shù)據(jù)庫(kù)表集的維護(hù)。如果不使用一個(gè)泛化類將數(shù)據(jù)結(jié)構(gòu)及其相關(guān)操作封裝起來(lái)，下層程序員要想操作有關(guān)庫(kù)表就必須對(duì)庫(kù)表設(shè)計(jì)有深入的了解，并且確保程序算法設(shè)計(jì)不得破壞數(shù)據(jù)的相關(guān)一致性，這將大大增加程序設(shè)計(jì)和測(cè)試的難度，要求程序員有較豐富的經(jīng)驗(yàn)。而采用這種泛化類(公用函數(shù)、公用存儲(chǔ)過(guò)程)后，程序員所要做的只是發(fā)“消息”和取“輸出信息”了。(4)有利于推行開(kāi)發(fā)規(guī)范，統(tǒng)一界面風(fēng)格。我們?cè)陂_(kāi)發(fā)國(guó)外軟件中受到的最大磨練是：國(guó)外對(duì)用戶界面(報(bào)表、屏幕)一絲不荀的嚴(yán)格要求。所有屏幕按鈕的高、寬、起始位置都用精確到小數(shù)點(diǎn)后3位的X、Y座標(biāo)進(jìn)行規(guī)定。這樣出來(lái)的產(chǎn)品使人看上去就有賞心悅目之感。但是如果人人都做界面窗口、按鈕的精細(xì)調(diào)整，工作量勢(shì)必成倍增長(zhǎng)。采用屏幕界面模版超類的繼承關(guān)系，結(jié)合特化處理，問(wèn)題便可迎刃而解。顯然，超類的設(shè)計(jì)和實(shí)現(xiàn)必須在程序員普遍進(jìn)行實(shí)例對(duì)象開(kāi)發(fā)之前完成。也就是說(shuō)，OOSE的上游系統(tǒng)設(shè)計(jì)人員必須文武(設(shè)計(jì)與編程)雙全，能夠擔(dān)負(fù)起超類對(duì)象的程序?qū)崿F(xiàn)與測(cè)試任務(wù)，這與結(jié)構(gòu)化方法的上層系統(tǒng)設(shè)計(jì)人員基本可以不編程有所不同。同時(shí)，超類對(duì)象在下游開(kāi)發(fā)過(guò)程中必須經(jīng)常吸收特化過(guò)程中的反饋(包括來(lái)自用戶的反饋)，進(jìn)行相應(yīng)的調(diào)整修改。所以O(shè)OSE擔(dān)任超類對(duì)象設(shè)計(jì)與實(shí)現(xiàn)的設(shè)計(jì)人員很難像結(jié)構(gòu)化方法那樣進(jìn)入編程階段后就可以稍事輕松，他們往往始終離不開(kāi)編程現(xiàn)場(chǎng)。如果設(shè)計(jì)階段不預(yù)先設(shè)計(jì)和開(kāi)發(fā)出超類對(duì)象，在同一項(xiàng)目的多數(shù)開(kāi)發(fā)者之間沒(méi)有可以共同繼承的祖先對(duì)象，甚至在各個(gè)開(kāi)發(fā)人員自己的作用范圍內(nèi)都不使用繼承關(guān)系，那么這不僅不是OOSE，就連稱之為OOP都很勉強(qiáng)。問(wèn)題4 如何處理對(duì)象模型面向?qū)ο箨P(guān)系數(shù)據(jù)庫(kù)模式的映射?面向?qū)ο蟮臄?shù)據(jù)庫(kù)設(shè)計(jì)方法可以用于各種數(shù)據(jù)庫(kù)，如層次型、網(wǎng)絡(luò)型、關(guān)系型，當(dāng)然也包括面向?qū)ο笮?。OOSE中的數(shù)據(jù)庫(kù)設(shè)計(jì)無(wú)疑必須采用面向?qū)ο蟮臄?shù)據(jù)庫(kù)設(shè)計(jì)方法。數(shù)據(jù)庫(kù)設(shè)計(jì)也稱數(shù)據(jù)庫(kù)模式，基本上由3個(gè)層次的模式構(gòu)成：從特定DB應(yīng)用角度來(lái)看待DB設(shè)計(jì)的外部模式;從組織或企業(yè)角度出發(fā)進(jìn)行的DB設(shè)計(jì)即概念模式;處理對(duì)應(yīng)特定DBMS特征與局限性的DB設(shè)計(jì)即內(nèi)部模式。具體而言，內(nèi)部模式是數(shù)據(jù)庫(kù)的SQL定義，邏輯模式是表集合的邏輯定義，外部模式是從特定應(yīng)用角度看的局部DB。外部模式與邏輯模式之間的接口是視圖、存儲(chǔ)過(guò)程或其他駐在服務(wù)器端的DB處理程序。如果在抽象出的對(duì)象模型中，各個(gè)應(yīng)用分別是一個(gè)或多個(gè)超類對(duì)象的子對(duì)象，那么，選擇適當(dāng)細(xì)分層次的對(duì)象模型將其映射到概念模型，是數(shù)據(jù)庫(kù)庫(kù)表對(duì)象設(shè)計(jì)的關(guān)鍵。外部模式與概念模式之間的接口越少、越簡(jiǎn)單越好，這樣的程序設(shè)計(jì)簡(jiǎn)單，數(shù)據(jù)庫(kù)和程序都易于維護(hù)。也就是說(shuō)，局部化是個(gè)重要的設(shè)計(jì)原則。OOP多是數(shù)據(jù)庫(kù)的后端處理，是基于既存數(shù)據(jù)庫(kù)的。因此無(wú)論是否進(jìn)行過(guò)問(wèn)題世界的對(duì)象建模，以及是否將對(duì)象模型合理地映射到數(shù)據(jù)庫(kù)邏輯模式(面向?qū)ο髷?shù)據(jù)庫(kù)設(shè)計(jì))，OOP都可以工作。問(wèn)題5編程時(shí)是否先調(diào)查有無(wú)可重用(繼承)對(duì)象，是否參與下層對(duì)象對(duì)上層對(duì)象、超類對(duì)象的反饋?埋頭于自己分擔(dān)的程序?qū)Y(jié)構(gòu)化方法或許是必須的，但在面向?qū)ο蠓椒ㄖ袚?dān)任程序設(shè)計(jì)的開(kāi)發(fā)人員，應(yīng)該先去調(diào)查對(duì)象數(shù)據(jù)辭典中有無(wú)其他開(kāi)發(fā)人員已經(jīng)完成、自己稍加特化就可重用的對(duì)象。從總體上說(shuō)，對(duì)象的共享、重用應(yīng)該由上層設(shè)計(jì)人員統(tǒng)一管理，以便保證對(duì)象風(fēng)格的一致性，避免沖突。但是，對(duì)象的獨(dú)立性、封裝性和多態(tài)性都很便于重用，這是結(jié)構(gòu)化系統(tǒng)所不能比擬的，而重用是軟件開(kāi)發(fā)方法學(xué)的最重要思想之一。上層設(shè)計(jì)人員往往不可能面面俱到，懂得軟件設(shè)計(jì)理論的開(kāi)發(fā)人員，即使只開(kāi)發(fā)下層程序也應(yīng)采用最省力、最有效率的編程方法，即大量使用重用對(duì)象。在繼承超類對(duì)象和重用他人對(duì)象時(shí)，若發(fā)現(xiàn)有設(shè)計(jì)不合理的地方，應(yīng)該及時(shí)反映給對(duì)象開(kāi)發(fā)的承擔(dān)者。對(duì)上層設(shè)計(jì)人員來(lái)說(shuō)，一方面應(yīng)該鼓勵(lì)程序?qū)崿F(xiàn)人員重用既存對(duì)象，另一方面應(yīng)通過(guò)開(kāi)發(fā)人員共享對(duì)象數(shù)據(jù)辭典，使個(gè)別的對(duì)象重用能夠立即反映到整體對(duì)象模型中，以保證設(shè)計(jì)變更時(shí)的一致性。4.2 面向?qū)ο蠓椒ㄅc結(jié)構(gòu)化方法比較分析是問(wèn)題抽象(做什么)，設(shè)計(jì)是問(wèn)題求解(怎么做)，實(shí)現(xiàn)是問(wèn)題的解(結(jié)果)。任何方法學(xué)對(duì)客觀世界的抽象和求解過(guò)程都是如此。在問(wèn)題抽象階段，結(jié)構(gòu)化方法面向過(guò)程，按照數(shù)據(jù)變換的過(guò)程尋找問(wèn)題的結(jié)點(diǎn)，對(duì)問(wèn)題進(jìn)行分解。因此，與面向?qū)ο蠓椒◤?qiáng)調(diào)的對(duì)象模型不同，描述數(shù)據(jù)變換的功能模型是結(jié)構(gòu)化方法的重點(diǎn)。如果問(wèn)題世界的功能比數(shù)據(jù)更復(fù)雜或者更重要，那么結(jié)構(gòu)化方法仍然應(yīng)是首選的方法學(xué)。如果數(shù)據(jù)結(jié)構(gòu)復(fù)雜且變換并不多，那么如以過(guò)程主導(dǎo)分析和設(shè)計(jì)，一旦有系統(tǒng)變更就會(huì)給下游開(kāi)發(fā)帶來(lái)極大混亂。由于對(duì)過(guò)程的理解不同，面向過(guò)程的功能細(xì)分所分割出的功能模塊有時(shí)會(huì)因人而異。而面向?qū)ο蟮膶?duì)象細(xì)分，從同一問(wèn)題領(lǐng)域的對(duì)象出發(fā)，不同人得出相同結(jié)論的比率較高。在設(shè)計(jì)上，結(jié)構(gòu)化方法學(xué)產(chǎn)生自頂向下、結(jié)構(gòu)清晰的系統(tǒng)結(jié)構(gòu)。每個(gè)模塊有可能保持較強(qiáng)的獨(dú)立性，但它往往與數(shù)據(jù)庫(kù)結(jié)構(gòu)相獨(dú)立，功能模塊與數(shù)據(jù)庫(kù)邏輯模式間沒(méi)有映射關(guān)系，程序與數(shù)據(jù)結(jié)構(gòu)很難封裝在一起。如果數(shù)據(jù)結(jié)構(gòu)復(fù)雜，模塊獨(dú)立性很難保證。面向?qū)ο蠓椒ǔ橄蟮南到y(tǒng)結(jié)構(gòu)往往并不比結(jié)構(gòu)化方法產(chǎn)生的系統(tǒng)結(jié)構(gòu)簡(jiǎn)單，但它能映射到數(shù)據(jù)庫(kù)結(jié)構(gòu)中，很容易實(shí)現(xiàn)程序與數(shù)據(jù)結(jié)構(gòu)的封裝。在軟件工程基本原則中有一條“形式化原則”，即對(duì)問(wèn)題世界的抽象結(jié)論應(yīng)該以形式化語(yǔ)言(圖形語(yǔ)言、偽碼語(yǔ)言等)表述出來(lái)。結(jié)構(gòu)化方法可以用數(shù)據(jù)流圖、系統(tǒng)結(jié)構(gòu)圖、數(shù)據(jù)辭典、狀態(tài)轉(zhuǎn)移圖、實(shí)體關(guān)系圖來(lái)進(jìn)行系統(tǒng)邏輯模型的描述;而面向?qū)ο蠓椒梢允褂脤?duì)象模型圖、數(shù)據(jù)辭典、動(dòng)態(tài)模型圖、功能模型圖。其中對(duì)象模型圖近似系統(tǒng)結(jié)構(gòu)圖與實(shí)體關(guān)系圖的結(jié)合，動(dòng)態(tài)模型圖類似狀態(tài)遷移圖，功能模型圖類似數(shù)據(jù)流圖。公路局系統(tǒng)有100多個(gè)數(shù)據(jù)庫(kù)表，但數(shù)據(jù)的加工(變換)很單純，如果當(dāng)初選擇結(jié)構(gòu)化方法學(xué)，情況會(huì)怎么樣?在問(wèn)題抽象的最初階段不會(huì)有太大差異。由于數(shù)據(jù)變換少，可以把對(duì)象和對(duì)象的操作看成一一對(duì)應(yīng)，即最初問(wèn)題描述的對(duì)象模型與功能模型基本一致。以其中計(jì)劃管理處子系統(tǒng)為例，對(duì)象是計(jì)劃管理員、規(guī)劃管理員、概預(yù)算管理員、統(tǒng)計(jì)管理員，功能(操作)是計(jì)劃、規(guī)劃、概預(yù)算、統(tǒng)計(jì)。問(wèn)題存在于下層抽象里。首先，許多公共超類對(duì)象設(shè)計(jì)與結(jié)構(gòu)化方法相悖，因?yàn)樗茐牧诉^(guò)程的連續(xù)性及系統(tǒng)結(jié)構(gòu)的邏輯層次性，把一些下層模塊及在過(guò)程分析中沒(méi)有語(yǔ)義的對(duì)象，放在系統(tǒng)結(jié)構(gòu)的上層。因此如果采用結(jié)構(gòu)化方法，須將繼承關(guān)系改為下層模塊調(diào)用關(guān)系。但是事實(shí)上，祖先對(duì)象的一些狀態(tài)(屬性值)是從主控模塊直接得到指示而確定的;從控制角度說(shuō)，它的確處于系統(tǒng)的上層地位。如果采用結(jié)構(gòu)化方法，結(jié)果將是要么把系統(tǒng)結(jié)構(gòu)變成網(wǎng)絡(luò)狀，失去結(jié)構(gòu)化特征，要么放棄這種統(tǒng)一完成重復(fù)性勞動(dòng)的設(shè)計(jì)方案。其次，應(yīng)用對(duì)象模型向數(shù)據(jù)庫(kù)概念模式的映射設(shè)計(jì)也是該系統(tǒng)采用面向?qū)ο蠓椒ǖ囊粋€(gè)標(biāo)志。如果使用結(jié)構(gòu)化方法，數(shù)據(jù)庫(kù)模式可能映射客觀世界的數(shù)據(jù)結(jié)構(gòu)。由于公路、養(yǎng)路單位、管理單位、路況、橋梁、隧道及道路上的綠化情況等各實(shí)體間客觀存在著復(fù)雜的多重關(guān)系，其結(jié)果可能定義出一個(gè)像蜘蛛網(wǎng)似的關(guān)系庫(kù)結(jié)構(gòu)，因而大大加重了數(shù)據(jù)庫(kù)前端應(yīng)用編程和數(shù)據(jù)庫(kù)維護(hù)的負(fù)擔(dān)?？傊撓到y(tǒng)若使用結(jié)構(gòu)化方法，系統(tǒng)結(jié)構(gòu)和數(shù)據(jù)庫(kù)結(jié)構(gòu)都可能成為網(wǎng)狀結(jié)構(gòu)，且互相無(wú)關(guān)。而目前采用的面向?qū)ο蠓椒ǎ到y(tǒng)結(jié)構(gòu)和數(shù)據(jù)庫(kù)結(jié)構(gòu)都是多重繼承結(jié)構(gòu)，相互存在映射關(guān)系。顯然前者較后者復(fù)雜性高、可維護(hù)性差、內(nèi)部重用難度大、重用率低。其實(shí)，無(wú)論是用什么方法學(xué)開(kāi)發(fā)軟件，交給用戶的都應(yīng)該是滿足用戶當(dāng)前需求的軟件。用戶在短期內(nèi)不會(huì)發(fā)現(xiàn)開(kāi)發(fā)者使用先進(jìn)方法學(xué)給他們帶來(lái)的益處，倒是開(kāi)發(fā)者本身由于大大減輕了開(kāi)發(fā)負(fù)擔(dān)而最先受益。但是隨著時(shí)間的推移，獲得最大收益的還是用戶，因?yàn)檐浖拈L(zhǎng)期質(zhì)量(包括維護(hù)成本低和生存周期長(zhǎng))給用戶帶來(lái)的好處才是根本的。4.3 方法學(xué)是思路不是定律對(duì)于方法學(xué)，我們是這樣理解的：(1)方法學(xué)的目的是：使后人分享前人的成功，避開(kāi)前人的失敗，把注意力集中在尚未開(kāi)拓領(lǐng)域的創(chuàng)造性勞動(dòng)上。所以方法學(xué)與開(kāi)發(fā)人員的創(chuàng)造性是絕不沖突的。它既不能像法律那樣靠權(quán)威來(lái)界定是非邊界，也不能像定律那樣通過(guò)證明和推理給出普遍結(jié)論。如果一定要做比喻的話，它好比人的世界觀。(2)沒(méi)有放之四海而皆準(zhǔn)的方法學(xué)，任何方法學(xué)都有其局限性，所以軟件開(kāi)發(fā)人員大可不必拘泥于某種特定的方法學(xué)。例如，面向?qū)ο蠓椒ǖ膶?duì)象模型圖，這種形式化語(yǔ)言遠(yuǎn)不如結(jié)構(gòu)化方法的結(jié)構(gòu)圖和數(shù)據(jù)流圖簡(jiǎn)單明了，倘若把公路局系統(tǒng)全部用對(duì)象模型圖表述出來(lái)，至少也要幾十頁(yè)。由于最上層功能模型與對(duì)象模型是一致的，所以我們采用的是結(jié)構(gòu)化方法的系統(tǒng)結(jié)構(gòu)圖。(3)事實(shí)表明，由OOP帶動(dòng)的OOSE方法確實(shí)比結(jié)構(gòu)化方法更能自然地抽象現(xiàn)實(shí)世界，而且一些OOP工具確實(shí)已相當(dāng)成熟。相反，結(jié)構(gòu)化方法及開(kāi)放平臺(tái)下的結(jié)構(gòu)化程序開(kāi)發(fā)工具，雖然不能說(shuō)止步不前，但其近年來(lái)的進(jìn)步是有限的。(4)根據(jù)我們的體會(huì)，對(duì)實(shí)踐OOSE有以下一些建議：1最好在選定方法學(xué)后，對(duì)全體開(kāi)發(fā)人員進(jìn)行一次關(guān)于面向?qū)ο蠓椒▽W(xué)的培訓(xùn)。2由于有超類對(duì)象的提前開(kāi)發(fā)工作，OOSE的上游設(shè)計(jì)工作量比結(jié)構(gòu)化方法的上游工作負(fù)擔(dān)重，時(shí)間和人力應(yīng)該更充足一些。否則到下游開(kāi)發(fā)后再追加或多次修改變更超類對(duì)象，容易造成混亂和無(wú)效勞動(dòng)。3由于系統(tǒng)越大對(duì)象類越多，為了便于內(nèi)部重用和共享，應(yīng)該建立電子化的對(duì)象數(shù)據(jù)辭典，以便對(duì)對(duì)象進(jìn)行統(tǒng)一歸類管理。4應(yīng)該有嚴(yán)格的命名規(guī)則，如果可能，應(yīng)將命名規(guī)則集成到數(shù)據(jù)辭典中。5下層開(kāi)發(fā)鋪開(kāi)后，如果發(fā)現(xiàn)應(yīng)該對(duì)某些實(shí)例對(duì)象泛化成新的超類對(duì)象，必須盡快進(jìn)行新超類追加的設(shè)計(jì)，變更越快越好。6子對(duì)象繼承超類對(duì)象后，發(fā)現(xiàn)超類設(shè)計(jì)的缺陷是常有的事。開(kāi)發(fā)隊(duì)伍內(nèi)部應(yīng)有很暢通的反饋渠道，使超類得到及時(shí)的修正。子對(duì)象切不可輕易將超類對(duì)象封殺掉，使系統(tǒng)失去統(tǒng)一控制。遵從系統(tǒng)設(shè)計(jì)中定義的繼承關(guān)系進(jìn)行實(shí)例對(duì)象開(kāi)發(fā)應(yīng)該成為全體開(kāi)發(fā)人員的理念。7面向?qū)ο笤O(shè)計(jì)的好處越到后來(lái)越顯著，特別是在系統(tǒng)維護(hù)和擴(kuò)充方面。第5章中間件技術(shù)一什么是中間件為解決分布異構(gòu)問(wèn)題，人們提出了中間件(middleware)的概念。中間件是位于平臺(tái)(硬件和操作系統(tǒng))和應(yīng)用之間的通用服務(wù)，如圖1所示，這些服務(wù)具有標(biāo)準(zhǔn)的程序接口和協(xié)議。針對(duì)不同的操作系統(tǒng)和硬件平臺(tái)，它們可以有符合接口和協(xié)議規(guī)范的多種實(shí)現(xiàn)。圖1中間件也許很難給中間件一個(gè)嚴(yán)格的定義，但中間件應(yīng)具有如下的一些特點(diǎn)：滿足大量應(yīng)用的需要運(yùn)行于多種硬件和OS平臺(tái)支持分布計(jì)算，提供跨網(wǎng)絡(luò)、硬件和OS平臺(tái)的透明性的應(yīng)用或服務(wù)的交互支持標(biāo)準(zhǔn)的協(xié)議支持標(biāo)準(zhǔn)的接口由于標(biāo)準(zhǔn)接口對(duì)于可移植性和標(biāo)準(zhǔn)協(xié)議對(duì)于互操作性的重要性，中間件已成為許多標(biāo)準(zhǔn)化工作的主要部分。對(duì)于應(yīng)用軟件開(kāi)發(fā)，中間件遠(yuǎn)比操作系統(tǒng)和網(wǎng)絡(luò)服務(wù)更為重要，中間件提供的程序接口定義了一個(gè)相對(duì)穩(wěn)定的高層應(yīng)用環(huán)境，不管底層的計(jì)算機(jī)硬件和系統(tǒng)軟件怎樣更新?lián)Q代，只要將中間件升級(jí)更新，并保持中間件對(duì)外的接口定義不變，應(yīng)用軟件幾乎不需任何修改，從而保護(hù)了企業(yè)在應(yīng)用軟件開(kāi)發(fā)和維護(hù)中的重大投資。三、主要中間件的分類中間件所包括的范圍十分廣泛，針對(duì)不同的應(yīng)用需求涌現(xiàn)出多種各具特色的中間件產(chǎn)品。但至今中間件還沒(méi)有一個(gè)比較精確的定義，因此，在不同的角度或不同的層次上，對(duì)中間件的分類也會(huì)有所不同。由于中間件需要屏蔽分布環(huán)境中異構(gòu)的操作系統(tǒng)和網(wǎng)絡(luò)協(xié)議，它必須能夠提供分布環(huán)境下的通訊服務(wù)，我們將這種通訊服務(wù)稱之為平臺(tái)。基于目的和實(shí)現(xiàn)機(jī)制的不同，我們將平臺(tái)分為以下主要幾類：遠(yuǎn)程過(guò)程調(diào)用（RemoteProcedureCall）面向消息的中間件（Message-OrientedMiddleware）對(duì)象請(qǐng)求代理（ObjectRequestBrokers）它們可向上提供不同形式的通訊服務(wù)，包括同步、排隊(duì)、訂閱發(fā)布、廣播等等，在這些基本的通訊平臺(tái)之上，可構(gòu)筑各種框架，為應(yīng)用程序提供不同領(lǐng)域內(nèi)的服務(wù)，如事務(wù)處理監(jiān)控器、分布數(shù)據(jù)訪問(wèn)、對(duì)象事務(wù)管理器OTM等。平臺(tái)為上層應(yīng)用屏蔽了異構(gòu)平臺(tái)的差異，而其上的框架又定義了相應(yīng)領(lǐng)域內(nèi)的應(yīng)用的系統(tǒng)結(jié)構(gòu)、標(biāo)準(zhǔn)的服務(wù)組件等，用戶只需告訴框架所關(guān)心的事件，然后提供處理這些事件的代碼。當(dāng)事件發(fā)生時(shí)，框架則會(huì)調(diào)用用戶的代碼。用戶代碼不用調(diào)用框架，用戶程序也不必關(guān)心框架結(jié)構(gòu)、執(zhí)行流程、對(duì)系統(tǒng)級(jí)API的調(diào)用等，所有這些由框架負(fù)責(zé)完成。因此，基于中間件開(kāi)發(fā)的應(yīng)用具有良好的可擴(kuò)充性、易管理性、高可用性和可移植性。二分類1、遠(yuǎn)程過(guò)程調(diào)用遠(yuǎn)程過(guò)程調(diào)用是一種廣泛使用的分布式應(yīng)用程序處理方法。一個(gè)應(yīng)用程序使用RPC來(lái)“遠(yuǎn)程”執(zhí)行一個(gè)位于不同地址空間里的過(guò)程，并且從效果上看和執(zhí)行本地調(diào)用相同。事實(shí)上，一個(gè)RPC應(yīng)用分為兩個(gè)部分：server和client。server提供一個(gè)或多個(gè)遠(yuǎn)程過(guò)程；client向server發(fā)出遠(yuǎn)程調(diào)用。server和client可以位于同一臺(tái)計(jì)算機(jī)，也可以位于不同的計(jì)算機(jī)，甚至運(yùn)行在不同的操作系統(tǒng)之上。它們通過(guò)網(wǎng)絡(luò)進(jìn)行通訊。相應(yīng)的stub和運(yùn)行支持提供數(shù)據(jù)轉(zhuǎn)換和通訊服務(wù)，從而屏蔽不同的操作系統(tǒng)和網(wǎng)絡(luò)協(xié)議。在這里RPC通訊是同步的。采用線程可以進(jìn)行異步調(diào)用。在RPC模型中，client和server只要具備了相應(yīng)的RPC接口，并且具有RPC運(yùn)行支持，就可以完成相應(yīng)的互操作，而不必限制于特定的server。因此，RPC為client/server分布式計(jì)算提供了有力的支持。同時(shí)，遠(yuǎn)程過(guò)程調(diào)用RPC所提供的是基于過(guò)程的服務(wù)訪問(wèn)，client與server進(jìn)行直接連接，沒(méi)有中間機(jī)構(gòu)來(lái)處理請(qǐng)求，因此也具有一定的局限性。比如，RPC通常需要一些網(wǎng)絡(luò)細(xì)節(jié)以定位server；在client發(fā)出請(qǐng)求的同時(shí)，要求server必須是活動(dòng)的等等。2、面向消息的中間件MOM指的是利用高效可靠的消息傳遞機(jī)制進(jìn)行平臺(tái)無(wú)關(guān)的數(shù)據(jù)交流，并基于數(shù)據(jù)通信來(lái)進(jìn)行分布式系統(tǒng)的集成。通過(guò)提供消息傳遞和消息排隊(duì)模型，它可在分布環(huán)境下擴(kuò)展進(jìn)程間的通信，并支持多通訊協(xié)議、語(yǔ)言、應(yīng)用程序、硬件和軟件平臺(tái)。目前流行的MOM中間件產(chǎn)品有IBM的MQSeries、BEA的MessageQ等。消息傳遞和排隊(duì)技術(shù)有以下三個(gè)主要特點(diǎn)：通訊程序可在不同的時(shí)間運(yùn)行:程序不在網(wǎng)絡(luò)上直接相互通話，而是間接地將消息放入消息隊(duì)列，因?yàn)槌绦蜷g沒(méi)有直接的聯(lián)系。所以它們不必同時(shí)運(yùn)行。消息放入適當(dāng)?shù)年?duì)列時(shí)，目標(biāo)程序甚至根本不需要正在運(yùn)行；即使目標(biāo)程序在運(yùn)行，也不意味著要立即處理該消息。對(duì)應(yīng)用程序的結(jié)構(gòu)沒(méi)有約束:在復(fù)雜的應(yīng)用場(chǎng)合中，通訊程序之間不僅可以是一對(duì)一的關(guān)系，還可以進(jìn)行一對(duì)多和多對(duì)一方式，甚至是上述多種方式的組合。多種通訊方式的構(gòu)造并沒(méi)有增加應(yīng)用程序的復(fù)雜性。程序與網(wǎng)絡(luò)復(fù)雜性相隔離:程序?qū)⑾⒎湃胂㈥?duì)列或從消息隊(duì)列中取出消息來(lái)進(jìn)行通訊，與此關(guān)聯(lián)的全部活動(dòng)，比如維護(hù)消息隊(duì)列、維護(hù)程序和隊(duì)列之間的關(guān)系、處理網(wǎng)絡(luò)的重新啟動(dòng)和在網(wǎng)絡(luò)中移動(dòng)消息等是MOM的任務(wù)，程序不直接與其它程序通話，并且它們不涉及網(wǎng)絡(luò)通訊的復(fù)雜性。3、對(duì)象請(qǐng)求代理隨著對(duì)象技術(shù)與分布式計(jì)算技術(shù)的發(fā)展，兩者相互結(jié)合形成了分布對(duì)象計(jì)算，并發(fā)展為當(dāng)今軟件技術(shù)的主流方向。1990年底，對(duì)象管理集團(tuán)OMG首次推出對(duì)象管理結(jié)構(gòu)OMA(ObjectManagementArchitecture)，對(duì)象請(qǐng)求代理（ObjectRequestBroker）是這個(gè)模型的核心組件。它的作用在于提供一個(gè)通信框架，透明地在異構(gòu)的分布計(jì)算環(huán)境中傳遞對(duì)象請(qǐng)求。CORBA規(guī)范包括了ORB的所有標(biāo)準(zhǔn)接口。1991年推出的CORBA1.1定義了接口描述語(yǔ)言O(shè)MGIDL和支持Client/Server對(duì)象在具體的ORB上進(jìn)行互操作的API。CORBA2.0規(guī)范描述的是不同廠商提供的ORB之間的互操作。對(duì)象請(qǐng)求代理(ORB)是對(duì)象總線，它在CORBA規(guī)范中處于核心地位，定義異構(gòu)環(huán)境下對(duì)象透明地發(fā)送請(qǐng)求和接收響應(yīng)的基本機(jī)制，是建立對(duì)象之間client/server關(guān)系的中間件。ORB使得對(duì)象可以透明地向其他對(duì)象發(fā)出請(qǐng)求或接受其他對(duì)象的響應(yīng)，這些對(duì)象可以位于本地也可以位于遠(yuǎn)程機(jī)器。ORB攔截請(qǐng)求調(diào)用，并負(fù)責(zé)找到可以實(shí)現(xiàn)請(qǐng)求的對(duì)象、傳送參數(shù)、調(diào)用相應(yīng)的方法、返回結(jié)果等。client對(duì)象并不知道同server對(duì)象通訊、激活或存儲(chǔ)server對(duì)象的機(jī)制，也不必知道server對(duì)象位于何處、它是用何種語(yǔ)言實(shí)現(xiàn)的、使用什么操作系統(tǒng)或其他不屬于對(duì)象接口的系統(tǒng)成分。值得指出的是client和server角色只是用來(lái)協(xié)調(diào)對(duì)象之間的相互作用，根據(jù)相應(yīng)的場(chǎng)合，ORB上的對(duì)象可以是client，也可以是server，甚至兼有兩者。當(dāng)對(duì)象發(fā)出一個(gè)請(qǐng)求時(shí)，它是處于client角色；當(dāng)它在接收請(qǐng)求時(shí)，它就處于server角色。大部分的對(duì)象都是既扮演client角色又扮演server角色。另外由于ORB負(fù)責(zé)對(duì)象請(qǐng)求的傳送和server的管理，client和server之間并不直接連接，因此，與RPC所支持的單純的Client/Server結(jié)構(gòu)相比，ORB可以支持更加復(fù)雜的結(jié)構(gòu)。4、事務(wù)處理監(jiān)控事務(wù)處理監(jiān)控（Transactionprocessingmonitors）最早出現(xiàn)在大型機(jī)上，為其提供支持大規(guī)模事務(wù)處理的可靠運(yùn)行環(huán)境。隨著分布計(jì)算技術(shù)的發(fā)展，分布應(yīng)用系統(tǒng)對(duì)大規(guī)模的事務(wù)處理提出了需求，比如商業(yè)活動(dòng)中大量的關(guān)鍵事務(wù)處理。事務(wù)處理監(jiān)控界于client和server之間，進(jìn)行事務(wù)管理與協(xié)調(diào)、負(fù)載平衡、失敗恢復(fù)等，以提高系統(tǒng)的整體性能。它可以被看作是事務(wù)處理應(yīng)用程序的“操作系統(tǒng)”?？傮w上來(lái)說(shuō)，事務(wù)處理監(jiān)控有以下功能：進(jìn)程管理，包括啟動(dòng)server進(jìn)程、為其分配任務(wù)、監(jiān)控其執(zhí)行并對(duì)負(fù)載進(jìn)行平衡。事務(wù)管理，即保證在其監(jiān)控下的事務(wù)處理的原子性、一致性、獨(dú)立性和持久性。通訊管理，為client和server之間提供了多種通訊機(jī)制，包括請(qǐng)求響應(yīng)、會(huì)話、排隊(duì)、訂閱發(fā)布和廣播等。事務(wù)處理監(jiān)控能夠?yàn)榇罅康腸lient提供服務(wù)，比如飛機(jī)定票系統(tǒng)。如果server為每一個(gè)client都分配其所需要的資源的話，那server將不堪重負(fù)（如圖2所示）。但實(shí)際上，在同一時(shí)刻并不是所有的client都需要請(qǐng)求服務(wù)，而一旦某個(gè)client請(qǐng)求了服務(wù)，它希望得到快速的響應(yīng)。事務(wù)處理監(jiān)控在操作系統(tǒng)之上提供一組服務(wù)，對(duì)client請(qǐng)求進(jìn)行管理并為其分配相應(yīng)的服務(wù)進(jìn)程，使server在有限的系統(tǒng)資源下能夠高效地為大規(guī)模的客戶提供服務(wù)。JavaEE技術(shù)軟件工程專題JavaEE以前稱為J2EE，可以幫助開(kāi)發(fā)和部署可移植、健壯、可伸縮且安全的服務(wù)器端Java應(yīng)用程序。JavaEE是在JavaSE的基礎(chǔ)上構(gòu)建的，它提供Web服務(wù)、組件模型、管理和通信API，可以用來(lái)實(shí)現(xiàn)企業(yè)級(jí)的面向服務(wù)體系結(jié)構(gòu)（SOA）和Web2.0應(yīng)用程序。本專題匯集大量相關(guān)技術(shù)資源，幫助您理解這些Java服務(wù)器端技術(shù)如何獨(dú)立以及共同工作，這是您成功開(kāi)發(fā)Java企業(yè)級(jí)應(yīng)用的關(guān)鍵。6.1 企業(yè)級(jí)Java企業(yè)Java計(jì)算模型由四部分組成：標(biāo)準(zhǔn)平臺(tái)定義（企業(yè)JavaAPIs）、工業(yè)強(qiáng)度的應(yīng)用服務(wù)器、構(gòu)件架構(gòu)和簡(jiǎn)化編碼工作的開(kāi)發(fā)工具。

EnterpriseJavaBeans和EnterpriseJavaBeanAPIsEnterpriseJavaBeans(EJB)使開(kāi)發(fā)者只編寫一次構(gòu)件，然后便可在最適合他們的應(yīng)用程序和企業(yè)需要的服務(wù)器環(huán)境中使用它們。標(biāo)準(zhǔn)化的EnterpriseJavaBeanAPIs使這成為可能。正如Sun在EnterpriseJavaBeans--Java的服務(wù)器構(gòu)件？中所說(shuō)明的企業(yè)的Java平臺(tái)由一套標(biāo)準(zhǔn)的應(yīng)用程序編程接口(API)到一套核心的企業(yè)-類基礎(chǔ)服務(wù)(其中包括生命周期、命名、遠(yuǎn)程喚醒、消息處理、交易、數(shù)據(jù)庫(kù)訪問(wèn)和管理)組成。這些基礎(chǔ)訪問(wèn)經(jīng)常是使用不同的產(chǎn)品和技術(shù)在不同的平臺(tái)上實(shí)現(xiàn)的，所以很難創(chuàng)建可移植的企業(yè)-類應(yīng)用程序系統(tǒng)。JavaEnterpriseAPIs提供了一個(gè)無(wú)需考慮實(shí)現(xiàn)方式，為經(jīng)常服務(wù)奠定基石的公共接口。應(yīng)用程序服務(wù)器應(yīng)用程序服務(wù)器為執(zhí)行由EnterpriseJavaBeans創(chuàng)建的中間件提供了一個(gè)平臺(tái)。這些服務(wù)器必須具有高度的可伸縮性以支持多用戶。用戶端可安全的且同時(shí)的訪問(wèn)應(yīng)用程序。應(yīng)用程序能夠在任何服務(wù)器平臺(tái)上執(zhí)行。若想了解更多的信息，請(qǐng)參閱IBM的應(yīng)用程序服務(wù)器。構(gòu)件架構(gòu)構(gòu)件是可被用來(lái)構(gòu)造其它應(yīng)用程序系統(tǒng)的應(yīng)用程序。在企業(yè)內(nèi)部，重要的部件提供一下的商業(yè)服務(wù)：交易、安全的數(shù)據(jù)庫(kù)訪問(wèn)等等。構(gòu)件可被方便的導(dǎo)入開(kāi)發(fā)工具中并用來(lái)為快速開(kāi)發(fā)基于Java的商業(yè)應(yīng)用程序提供架構(gòu)。它們被用來(lái)設(shè)置應(yīng)用程序并由Web服務(wù)器或數(shù)據(jù)庫(kù)系統(tǒng)執(zhí)行。這些構(gòu)件遵從EnterpriseJavaBeans的規(guī)范。若想了解更多的信息，請(qǐng)參閱IBM的構(gòu)件架構(gòu)。開(kāi)發(fā)工具企業(yè)Java開(kāi)發(fā)工具為創(chuàng)建Java兼容的應(yīng)用程序、applet、servlets和JavaBean構(gòu)件提供了一個(gè)途徑。通過(guò)將Java客戶端自動(dòng)連接到現(xiàn)存的服務(wù)器數(shù)據(jù)、交易和應(yīng)用程序上，客戶便可以利用現(xiàn)存的商業(yè)應(yīng)用程序和web上日常的商業(yè)運(yùn)作。6.2 J2EE簡(jiǎn)介6.2.1 J2EE的概念目前，Java2平臺(tái)有3個(gè)版本，它們是適用于小型設(shè)備和智能卡的Java2平臺(tái)Micro版（Java2PlatformMicroEdition，J2ME）、適用于桌面系統(tǒng)的Java2平臺(tái)標(biāo)準(zhǔn)版（Java2PlatformStandardEdition，J2SE）、適用于創(chuàng)建服務(wù)器應(yīng)用程序和服務(wù)的Java2平臺(tái)企業(yè)版（Java2PlatformEnterpriseEdition，J2EE）。J2EE是一種利用Java2平臺(tái)來(lái)簡(jiǎn)化企業(yè)解決方案的開(kāi)發(fā)、部署和管理相關(guān)的復(fù)雜問(wèn)題的體系結(jié)構(gòu)。J2EE技術(shù)的基礎(chǔ)就是核心Java平臺(tái)或Java2平臺(tái)的標(biāo)準(zhǔn)版，J2EE不僅鞏固了標(biāo)準(zhǔn)版中的許多優(yōu)點(diǎn)，例如"編寫一次、隨處運(yùn)行"的特性、方便存取數(shù)據(jù)庫(kù)的JDBCAPI、CORBA技術(shù)以及能夠在Internet應(yīng)用中保護(hù)數(shù)據(jù)的安全模式等等，同時(shí)還提供了對(duì)EJB（EnterpriseJavaBeans）、JavaServletsAPI、JSP（JavaServerPages）以及XML技術(shù)的全面支持。其最終目的就是成為一個(gè)能夠使企業(yè)開(kāi)發(fā)者大幅縮短投放市場(chǎng)時(shí)間的體系結(jié)構(gòu)。J2EE體系結(jié)構(gòu)提供中間層集成框架用來(lái)滿足無(wú)需太多費(fèi)用而又需要高可用性、高可靠性以及可擴(kuò)展性的應(yīng)用的需求。通過(guò)提供統(tǒng)一的開(kāi)發(fā)平臺(tái)，J2EE降低了開(kāi)發(fā)多層應(yīng)用的費(fèi)用和復(fù)雜性，同時(shí)提供對(duì)現(xiàn)有應(yīng)用程序集成強(qiáng)有力支持，完全支持EnterpriseJavaBeans，有良好的向?qū)еС执虬筒渴饝?yīng)用，添加目錄支持，增強(qiáng)了安全機(jī)制，提高了性能。J2EE的優(yōu)勢(shì)J2EE為搭建具有可伸縮性、靈活性、易維護(hù)性的商務(wù)系統(tǒng)提供了良好的機(jī)制:保留現(xiàn)存的IT資產(chǎn):由于企業(yè)必須適應(yīng)新的商業(yè)需求，利用已有的企業(yè)信息系統(tǒng)方面的投資，而不是重新制定全盤方案就變得很重要。這樣，一個(gè)以漸進(jìn)的（而不是激進(jìn)的，全盤否定的）方式建立在已有系統(tǒng)之上的服務(wù)器端平臺(tái)機(jī)制是公司所需求的。J2EE架構(gòu)可以充分利用用戶原有的投資，如一些公司使用的BEATuxedo、IBMCICS,IBMEncina,、InpriseVisiBroker以及NetscapeApplicationServer。這之所以成為可能是因?yàn)镴2EE擁有廣泛的業(yè)界支持和一些重要的'企業(yè)計(jì)算'領(lǐng)域供應(yīng)商的參與。每一個(gè)供應(yīng)商都對(duì)現(xiàn)有的客戶提供了不用廢棄已有投資，進(jìn)入可移植的J2EE領(lǐng)域的升級(jí)途徑。由于基于J2EE平臺(tái)的產(chǎn)品幾乎能夠在任何操作系統(tǒng)和硬件配置上運(yùn)行，現(xiàn)有的操作系統(tǒng)和硬件也能被保留使用。高效的開(kāi)發(fā):J2EE允許公司把一些通用的、很繁瑣的服務(wù)端任務(wù)交給中間件供應(yīng)商去完成。這樣開(kāi)發(fā)人員可以集中精力在如何創(chuàng)建商業(yè)邏輯上，相應(yīng)地縮短了開(kāi)發(fā)時(shí)間。高級(jí)中間件供應(yīng)商提供以下這些復(fù)雜的中間件服務(wù):狀態(tài)管理服務(wù)--讓開(kāi)發(fā)人員寫更少的代碼，不用關(guān)心如何管理狀態(tài)，這樣能夠更快地完成程序開(kāi)發(fā)。持續(xù)性服務(wù)--讓開(kāi)發(fā)人員不用對(duì)數(shù)據(jù)訪問(wèn)邏輯進(jìn)行編碼就能編寫應(yīng)用程序，能生成更輕巧，與數(shù)據(jù)庫(kù)無(wú)關(guān)的應(yīng)用程序，這種應(yīng)用程序更易于開(kāi)發(fā)與維護(hù)。分布式共享數(shù)據(jù)對(duì)象CACHE服務(wù)--讓開(kāi)發(fā)人員編制高性能的系統(tǒng)，極大提高整體部署的伸縮性。支持異構(gòu)環(huán)境:J2EE能夠開(kāi)發(fā)部署在異構(gòu)環(huán)境中的可移植程序。基于J2EE的應(yīng)用程序不依賴任何特定操作系統(tǒng)、中間件、硬件。因此設(shè)計(jì)合理的基于J2EE的程序只需開(kāi)發(fā)一次就可部署到各種平臺(tái)。這在典型的異構(gòu)企業(yè)計(jì)算環(huán)境中是十分關(guān)鍵的。J2EE標(biāo)準(zhǔn)也允許客戶訂購(gòu)與J2EE兼容的第三方的現(xiàn)成的組件，把他們部署到異構(gòu)環(huán)境中，節(jié)省了由自己制訂整個(gè)方案所需的費(fèi)用?？缮炜s性:企業(yè)必須要選擇一種服務(wù)器端平臺(tái)，這種平臺(tái)應(yīng)能提供極佳的可伸縮性去滿足那些在他們系統(tǒng)上進(jìn)行商業(yè)運(yùn)作的大批新客戶。基于J2EE平臺(tái)的應(yīng)用程序可被部署到各種操作系統(tǒng)上。例如可被部署到高端UNIX與大型機(jī)系統(tǒng)，這種系統(tǒng)單機(jī)可支持64至256個(gè)處理器。（這是NT服務(wù)器所望塵莫及的）J2EE領(lǐng)域的供應(yīng)商提供了更為廣泛的負(fù)載平衡策略。能消除系統(tǒng)中的瓶頸，允許多臺(tái)服務(wù)器集成部署。這種部署可達(dá)數(shù)千個(gè)處理器，實(shí)現(xiàn)可高度伸縮的系統(tǒng)，滿足未來(lái)商業(yè)應(yīng)用的需要。穩(wěn)定的可用性:一個(gè)服務(wù)器端平臺(tái)必須能全天候運(yùn)轉(zhuǎn)以滿足公司客戶、合作伙伴的需要。因?yàn)镮NTERNET是全球化的、無(wú)處不在的，即使在夜間按計(jì)劃停機(jī)也可能造成嚴(yán)重?fù)p失。若是意外停機(jī)，那會(huì)有災(zāi)難性后果。J2EE部署到可靠的操作環(huán)境中，他們支持長(zhǎng)期的可用性。一些J2EE部署在WINDOWS環(huán)境中，客戶也可選擇健壯性能更好的操作系統(tǒng)如SunSolaris、IBMOS/390。最健壯的操作系統(tǒng)可達(dá)到99.999%的可用性或每年只需5分鐘停機(jī)時(shí)間。這是實(shí)時(shí)性很強(qiáng)商業(yè)系統(tǒng)理想的選擇。6.2.2 J2EE的四層模型J2EE使用多層的分布式應(yīng)用模型，應(yīng)用邏輯按功能劃分為組件，各個(gè)應(yīng)用組件根據(jù)他們所在的層分布在不同的機(jī)器上。事實(shí)上，sun設(shè)計(jì)J2EE的初衷正是為了解決兩層模式(client/server)的弊端，在傳統(tǒng)模式中，客戶端擔(dān)當(dāng)了過(guò)多的角色而顯得臃腫，在這種模式中，第一次部署的時(shí)候比較容易，但難于升級(jí)或改進(jìn)，可伸展性也不理想，而且經(jīng)?；谀撤N專有的協(xié)議?D?D通常是某種數(shù)據(jù)庫(kù)協(xié)議。它使得重用業(yè)務(wù)邏輯和界面邏輯非常困難?，F(xiàn)在J2EE的多層企業(yè)級(jí)應(yīng)用模型將兩層化模型中的不同層面切分成許多層。一個(gè)多層化應(yīng)用能夠?yàn)椴煌拿糠N服務(wù)提供一個(gè)獨(dú)立的層，以下是J2EE典型的四層結(jié)構(gòu):運(yùn)行在客戶