【正文】 確調(diào)整產(chǎn)品、配置、安裝，以及可用性等問題上。? 管理資源與控制過程? 開發(fā)與測試組件? 對迭代進(jìn)行評估4．交付階段（The Transition Phase）交付階段的焦點(diǎn)就是確保軟件對于最終用戶是可用的。因此，在此階段，管理理念應(yīng)該進(jìn)行一個(gè)轉(zhuǎn)換，從起始階段和細(xì)化階段的知識產(chǎn)品開發(fā)轉(zhuǎn)換到構(gòu)建和交付階段的部署產(chǎn)品的開發(fā)。3．構(gòu)建階段（The Construction Phase）構(gòu)建階段的目標(biāo)是完成系統(tǒng)開發(fā)。? 制定項(xiàng)目的范圍? 計(jì)劃并準(zhǔn)備業(yè)務(wù)案例? 綜合分析，得出備選構(gòu)架? 準(zhǔn)備項(xiàng)目環(huán)境2．細(xì)化階段（The Elaboration Phase）細(xì)化階段的目標(biāo)是為系統(tǒng)構(gòu)架設(shè)立基線（baseline），為在構(gòu)建階段開展的大量的設(shè)計(jì)與實(shí)施工作打下堅(jiān)實(shí)的基礎(chǔ)。對于那些增強(qiáng)現(xiàn)有系統(tǒng)的項(xiàng)目，起始階段是比較短暫的，但是其目的仍是確定該項(xiàng)目的實(shí)施價(jià)值及可行性。 項(xiàng)目開發(fā)階段1．起始階段（The Inception Phase）對于新的開發(fā)項(xiàng)目來說，起始階段是很重要的。系統(tǒng)經(jīng)過測試后，整個(gè)開發(fā)流程告一段落，進(jìn)入運(yùn)行維護(hù)或新的功能擴(kuò)展時(shí)期。這一任務(wù)可能比較困難，也可能比較容易，主要取決于所使用的編程語言本身的能力。3．實(shí)現(xiàn)實(shí)現(xiàn)又稱編碼或開發(fā)階段，也就是將設(shè)計(jì)轉(zhuǎn)換為特定的編程語言或硬件，同時(shí)保持先進(jìn)性、靈活性和可擴(kuò)展性。2．系統(tǒng)分析和設(shè)計(jì)系統(tǒng)分析階段是基于問題和用戶需求的描述，建立現(xiàn)實(shí)世界的計(jì)算機(jī)實(shí)現(xiàn)模型。也就是說，在不同階段的每次迭代中，生命周期的每個(gè)步驟是同步進(jìn)行的，但權(quán)重不同。每個(gè)階段都包括一次或者多次的迭代。從縱向來看，項(xiàng)目的生命周期或工作流包括項(xiàng)目需求分析、系統(tǒng)分析和設(shè)計(jì)、實(shí)現(xiàn)、測試和維護(hù)。線性模型太理想化，太單純，以至很多人認(rèn)為瀑布模型已不再適合現(xiàn)代的軟件開發(fā)模式，幾乎被業(yè)界拋棄。圖21 因此，根據(jù)軟件項(xiàng)目的實(shí)際情況選擇一個(gè)適合的開發(fā)模式能減少開發(fā)周期中“坎”的出現(xiàn)次數(shù)與難度，可以很大程度地縮短開發(fā)周期。也正如此，使得開發(fā)過程中的每個(gè)步驟起點(diǎn)和終點(diǎn)在不同的軟件項(xiàng)目中出現(xiàn)不同難度的“坎”，使其難于達(dá)到該步驟開始或是終結(jié)的條件，開發(fā)過程也就不會一帆風(fēng)順。項(xiàng)目開發(fā)并不是一個(gè)簡單的過程，我們需要遵循一些開發(fā)流程。這個(gè)模型使得Java開發(fā)者能很自然運(yùn)用面向?qū)ο缶幊蹋∣bjectOriented Programming），而不需要附加的編碼。例如，Hibernate允許你將數(shù)據(jù)庫中的信息存入域?qū)ο螅╠omain objects），這樣你可以在連接斷開的情況下把這些數(shù)據(jù)顯示到用戶界面層，而那些對象也可以返回給持久層，從而在數(shù)據(jù)庫里更新。域模塊層由實(shí)際需求中的業(yè)務(wù)對象組成，比如訂單明細(xì)（OrderLineItem）、產(chǎn)品（Product）等。下面是業(yè)務(wù)層所負(fù)責(zé)的。另外，Spring把程序中所涉及到的包含業(yè)務(wù)邏輯和數(shù)據(jù)存取對象（DataAccess Object）的Objects——transaction management handler（事務(wù)管理控制）、Object Factories（對象工廠）、service objects（服務(wù)組件）都通過XML配置聯(lián)系起來。這兩個(gè)框架都著手于“依賴注射”（dependency injection），還有我們知道的“控制反轉(zhuǎn)”（Inversion of Control，IoC）這樣的簡單概念。幸好，針對這一問題有幾種框架（Framework）存在，最受歡迎的兩個(gè)框架是Spring和PicoContainer。我們往往在用戶界面層或持久層周圍看到這些業(yè)務(wù)處理的代碼，這其實(shí)是不正確的。一個(gè)典型Web應(yīng)用的中間部分是業(yè)務(wù)層或服務(wù)層。? 如何存儲、更新、刪除數(shù)據(jù)庫記錄。HQL語言容易理解且文檔做得很好。Hibernate是通過一個(gè)面向?qū)ο蟮牟樵冋Z言（HQL）或正則表達(dá)的API來完成查詢的。下面是Hibernate所負(fù)責(zé)的內(nèi)容。Hibernate的持久對象是基于POJO（Plain Old Java Object）和Java集合（collections）的。幸運(yùn)的是，有幾個(gè)對象/關(guān)系映射（Object/Relation Mapping，ORM）開源框架很好地解決了這類問題，尤其是Hibernate。開發(fā)者總是低估構(gòu)建他們自己的持久層框架的挑戰(zhàn)性。? 與數(shù)據(jù)庫直接通信? 與應(yīng)用程序相關(guān)聯(lián)的業(yè)務(wù)邏輯及校驗(yàn)? 事務(wù)處理在表示層引入這些代碼，則會帶來高耦合和難以維護(hù)的后果。 表示層一般來講，一個(gè)典型的Web應(yīng)用的前端應(yīng)該是表示層，這里可以使用Struts框架。下面將分別詳細(xì)地介紹這4層，討論一下這些層應(yīng)該提供什么，不應(yīng)該提供什么。每個(gè)層在功能上都應(yīng)該是十分明確的，而不應(yīng)該與其他層混合。如何建立你的架構(gòu)，并且怎樣讓你的各個(gè)應(yīng)用層保持一致？如何整合框架，以便讓每層以一種松散耦合的方式彼此作用而不用管底層的技術(shù)細(xì)節(jié)？這里討論一個(gè)使用3種開源框架的策略：表示層用Struts，業(yè)務(wù)層用Spring，而持久層則用Hibernate，如圖11所示。更重要的是，框架能把開發(fā)者從底層編碼中解放出來，使他們能專心于應(yīng)用程序的邏輯。一個(gè)好框架應(yīng)具備以下幾點(diǎn)：減輕開發(fā)者處理復(fù)雜問題的負(fù)擔(dān)，具有良好的可擴(kuò)展性，并且有一個(gè)支持它的強(qiáng)大的用戶團(tuán)體。然而，就算用Java建造一個(gè)不是很煩瑣的Web應(yīng)用系統(tǒng)，也不是件輕松的事情。目前，國內(nèi)外信息化建設(shè)已經(jīng)進(jìn)入以Web應(yīng)用為基礎(chǔ)核心的階段。Java語言應(yīng)該算得上是開發(fā)Web應(yīng)用的最佳語言。有很多東西需要仔細(xì)考慮，比如要考慮怎樣建立用戶接口？在哪里處理業(yè)務(wù)邏輯？怎樣持久化數(shù)據(jù)？而這3層構(gòu)架中，每一層都有各自要仔細(xì)考慮的內(nèi)容，比如各個(gè)層該使用什么技術(shù)？怎樣的設(shè)計(jì)既能松散耦合還能靈活改變？怎樣替換某個(gè)層而不影響整體構(gòu)架？應(yīng)用程序如何做各個(gè)方面的處理（例如，事務(wù)處理）？幸運(yùn)的是，構(gòu)架一個(gè)Web應(yīng)用需要解決的一些問題已經(jīng)由曾遇到過這類問題的開發(fā)者建立起處理這類問題的框架（Framework）。好的框架一般有針對性地處理某一類問題，并且能將它做好（Do One Thing Well），好的框架還應(yīng)該能指導(dǎo)代碼如何分布。本書將討論怎樣結(jié)合3種著名的框架Struts、Spring和Hibernate來使你的應(yīng)用程序做到松散耦合。大部分的Web應(yīng)用在職責(zé)上至少能被分成4層：表示層（Presentation Layer）、持久層（Persistence Layer）、業(yè)務(wù)層（Business Layer）和域模塊層（domain model Layer）。每個(gè)層要相互獨(dú)立，通過一個(gè)通信接口而相互聯(lián)系。下面是Struts所負(fù)責(zé)的：? 管理用戶的請求，做出相應(yīng)的響應(yīng)? 提供一個(gè)流程控制器，委派調(diào)用業(yè)務(wù)邏輯和其他上層處理? 處理異常 ? 為顯示提供一個(gè)數(shù)據(jù)模型 ? 用戶界面的驗(yàn)證以下內(nèi)容，不該在Struts表示層的編碼中經(jīng)常出現(xiàn)，它們與表示層無關(guān)的。典型的Web應(yīng)用的后端是持久層。系統(tǒng)內(nèi)部的持久層不但需要大量調(diào)試時(shí)間，而且還經(jīng)常因?yàn)槿鄙俟δ苁怪兊秒y以控制，這是持久層的通病。Hibernate為Java提供了持久化機(jī)制和查詢服務(wù)，它還給已經(jīng)熟悉SQL和JDBC API的Java開發(fā)者創(chuàng)造了一個(gè)學(xué)習(xí)橋梁，使他們學(xué)習(xí)起來很方便。此外，使用Hibernate并不妨礙你正在使用的IDE（Integrated Development Enviroment）。? 如何查詢對象的相關(guān)信息。HQL非常類似于SQL，只是把SQL里的table和columns用Object和它的fields代替。HQL是一種面向?qū)ο蟛樵兊淖匀徽Z言，很容易就能學(xué)會它。? Hibernate這類的高級ORM框架支持大部分主流數(shù)據(jù)庫，并且支持父表/子表（Parent/ child）關(guān)系、事務(wù)處理、繼承和多態(tài)。從編碼的視角來看，這層是最容易被忽視的。因?yàn)樗鼤斐沙绦虼a的高耦合，這樣一來，隨著時(shí)間推移，這些代碼將很難維護(hù)。這些也被稱為輕量級容器（micro container），它們能讓你很好地把對象搭配起來。這里，我們將關(guān)注于Spring的依賴注射和面向方面編程。后面我們會通過項(xiàng)目和實(shí)例來揭示Spring是怎樣運(yùn)用這些概念的。? 處理應(yīng)用程序的業(yè)務(wù)邏輯和業(yè)務(wù)校驗(yàn)? 管理事務(wù)? 提供與其他層相互作用的接口? 管理業(yè)務(wù)層級別的對象的依賴? 在表示層和持久層之間增加了一個(gè)靈活的機(jī)制，使得他們不直接聯(lián)系在一起? 通過揭示從表示層到業(yè)務(wù)層之間的上下文（Context）來得到業(yè)務(wù)邏輯（business services）? 管理程序的執(zhí)行（從業(yè)務(wù)層到持久層）既然我們致力于一個(gè)Web的應(yīng)用，我們就需要一個(gè)對象集合，讓它在不同層之間移動(dòng)。開發(fā)者在這層不用管那些數(shù)據(jù)傳輸對象（Data Transfer Object），而僅關(guān)注域?qū)ο螅╠omain object）即可。而且，你不必把對象轉(zhuǎn)化成DTO（這可能導(dǎo)致它在不同層之間的傳輸過程中丟失）。本書圍繞上述架構(gòu)，通過一個(gè)完整的項(xiàng)目online bookstore來具體展開StrutsSpring Hibernate這3部分的講解。一個(gè)項(xiàng)目的開發(fā)會被分成很多步驟來實(shí)現(xiàn)，每一個(gè)步驟都有自己的起點(diǎn)和終點(diǎn)。不同的開發(fā)模式其實(shí)就是將步驟的起點(diǎn)和終點(diǎn)重新定義，甚至重新組合排列，雖然任何一個(gè)開發(fā)模式最終目的都是完成軟件項(xiàng)目的開發(fā)，但期間所經(jīng)歷的過程不一樣，過程步驟之間的起點(diǎn)和終點(diǎn)的定義不同，所帶來的“坎”也就不一樣，項(xiàng)目周期自然各不相同。我們首先了解一下傳統(tǒng)瀑布式開發(fā)流程，如圖21所示。瀑布式（Waterfall）開發(fā)流程，在瀑布模型中，開發(fā)被認(rèn)為是按照需求分析、設(shè)計(jì)、實(shí)現(xiàn)、測試（確認(rèn)）、集成和維護(hù)堅(jiān)定而順暢地進(jìn)行的。 我們向大家推薦的是統(tǒng)一開發(fā)流程RUP（Rational Unified Process），它是目前最流行的一套項(xiàng)目開發(fā)流程模式，其基本特征是通過多次迭代完成一個(gè)項(xiàng)目的開發(fā)，每次迭代都會帶來項(xiàng)目整體的遞增，如圖22所示。從橫向來看，項(xiàng)目開發(fā)可以分為4個(gè)階段：起始（Inception）、細(xì)化（Elaboration）、建造（Construction）和移交（transition）。在每次迭代中，根據(jù)不同的要求或工作流（如需求、分析和設(shè)計(jì)等）投入不同的工作量。這是與傳統(tǒng)瀑布式開發(fā)流程區(qū)別最大的地方。 項(xiàng)目生命周期1．項(xiàng)目需求分析需求分析階段的活動(dòng)包括定義潛在的角色（角色指使用系統(tǒng)的人，以及與系統(tǒng)相互作用的軟、硬件環(huán)境）、識別問題域中的對象和關(guān)系，以及基于需求規(guī)范說明和角色的需要發(fā)現(xiàn)用例（usecase）和詳細(xì)描述用例。系統(tǒng)設(shè)計(jì)是結(jié)合問題域的知識和目標(biāo)系統(tǒng)的體系結(jié)構(gòu)（求解域），將目標(biāo)系統(tǒng)分解為子系統(tǒng)，之后基于分析模型添加細(xì)節(jié)，完成系統(tǒng)設(shè)計(jì)。在這個(gè)階段，設(shè)計(jì)階段的類被轉(zhuǎn)換為使用面向?qū)ο缶幊陶Z言編制（不推薦使用過程語言）的實(shí)際代碼。4．測試和維護(hù)測試用于檢驗(yàn)系統(tǒng)是否滿足用戶功能需求，以便增加用戶對系統(tǒng)的信心。在項(xiàng)目繼續(xù)進(jìn)行前，我們必須處理重要的業(yè)務(wù)與需求風(fēng)險(xiǎn)。起始階段有4個(gè)重要活動(dòng)。構(gòu)架是通過考慮最重要的需求與評估風(fēng)險(xiǎn)演進(jìn)而來的，構(gòu)架的穩(wěn)定性是通過一個(gè)或多個(gè)構(gòu)架原型（prototype）進(jìn)行評估的。構(gòu)建階段從某種意義上來看是一個(gè)制造過程，其中，重點(diǎn)工作就是管理資源、控制操作，以優(yōu)化成本、日程和質(zhì)量。構(gòu)建階段的每次迭代都具有3個(gè)關(guān)鍵活動(dòng)。交付階段包括為發(fā)布應(yīng)用而進(jìn)行的產(chǎn)品測試，在用戶反饋的基礎(chǔ)上做微小的調(diào)整等內(nèi)容。交付階段的關(guān)鍵活動(dòng)如下：? 確定最終用戶支持資料 ? 在用戶的環(huán)境中測試可交付的產(chǎn)品? 基于用戶反饋精確調(diào)整產(chǎn)品? 向最終用戶交付最終產(chǎn)品最后，作為補(bǔ)充，我們再簡單介紹一種新的開發(fā)流程：敏捷開發(fā)和極限編程。敏捷開發(fā)過程的方法很多，主要有SCRUM、Crystal、特征驅(qū)動(dòng)軟件開發(fā)（Feature Driven Development，簡稱FDD）、自適應(yīng)軟件開發(fā)(Adaptive Software Development，簡稱ASD)，以及最重要的極限編程(eXtreme Programming,簡稱XP)。XP在很多方面都和傳統(tǒng)意義上的軟件工程不同，同時(shí)，它也和傳統(tǒng)得管理和項(xiàng)目計(jì)劃得方法不同。 XP具有12個(gè)過程，只有完全使用12個(gè)過程才是真正使用了XP，只是簡單使用了其中一個(gè)方法并不代表使用了XP。? 現(xiàn)場客戶（Onsite Customer） ? 計(jì)劃博弈（Planning Game） ? 系統(tǒng)隱喻（System Design） ? 簡化設(shè)計(jì)（Simple Design） ? 集體擁有代碼（Collective Code Ownership） ? 結(jié)對編程（Pair Programming） ? 測試驅(qū)動(dòng)（Testdriver） ? 小型發(fā)布（Small Release） ? 重構(gòu)（Refactoring） ? 持續(xù)集成（Continous integration） ? 每周40小時(shí)工作制（40hour Weeks） ? 代碼規(guī)范（Coding Standards） 下面是極限編程的有效實(shí)踐。這個(gè)場所的墻壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進(jìn)度的東西。每2周，開發(fā)人員就為下2周估算候選特性的成本，而客戶則根據(jù)成本和商務(wù)價(jià)值來選擇要實(shí)現(xiàn)的特性。 簡單設(shè)計(jì)團(tuán)隊(duì)保持設(shè)計(jì)恰好和當(dāng)前的系統(tǒng)功能相匹配。 結(jié)對編程所有的產(chǎn)品軟件都是由兩個(gè)程序員并排坐在一起在同一臺機(jī)器上構(gòu)建的。同樣，它更是一種編寫文檔的行為。程序員以非常短的循環(huán)周期工作，他們先增加一個(gè)失敗的測試，然后使之通過。 持續(xù)集成團(tuán)隊(duì)總是使系統(tǒng)完整地被集成。 集體代碼所有權(quán)任何結(jié)對的程序員都可以在任何時(shí)候改進(jìn)任何代碼。 編碼標(biāo)準(zhǔn)系統(tǒng)中所有的代碼看起來就好像是由一人單獨(dú)編寫的。如果模塊的外觀與整個(gè)隱喻不符，那么你就知道該模塊是錯(cuò)誤的。他們以能夠長期維持的速度努力工作，他們保存精力，他們把項(xiàng)目看