【正文】 現(xiàn),清楚的開發(fā)角色劃分,這些優(yōu)勢在大型項目中表現(xiàn)得尤為突出。另外從設計結構來看,這種模型充分體現(xiàn)了模型視圖 控制器(MVC)的設計模式。廣東工業(yè)大學工學碩士學位論文12 MVC設計模式 MVC設計模式的結構MVC 英文即 ModelViewController,即把一個應用的輸入、處理、輸出流程按照 Model、View 、Controller 的方式進行分離,這樣一個應用被分成三個層模型層、視圖層、控制層。其結構如圖：圖 33 MVC 體系結構圖Figure 33 MVC architectureMVC 模式的處理流程是,首先控制器接收用戶的請求,并決定應該調用哪個模型來進行處理,然后模型調用業(yè)務邏輯來處理用戶的請求并返回數(shù)據,最后控制器用相應的視圖返回數(shù)據,并通過表示層呈現(xiàn)給用戶。Model：模型指的是真正完成任務的代碼,包含應用系統(tǒng)的核心功能 ,表示一個應用系統(tǒng)的數(shù)據,并且包含訪問、維護和管理這些數(shù)據的邏輯。所有屬于應用系統(tǒng)持久狀態(tài)的數(shù)據都應該保存于模型對象里。模型提供的服務必須足夠適用于不同的終端。一個模型聚集了相關的數(shù)據和操作,以提供一個詳細而精確的服務,這些被封裝在操作中的抽象事物的功能被模型化。一個模型的接口提供了訪問和更新模型狀態(tài),執(zhí)行封裝在模型中的復雜進程的方法。模型服務被控制器訪問,用于查詢或更改模型的狀態(tài)。當模型狀態(tài)發(fā)生變化時,模型會通報給視圖。對大多數(shù) WEB 應第三章 相關技術介紹13用程序而言,功能比界面感覺更重要。在模型同界面分離的情況下,代碼即可實現(xiàn)可管理性和可重用性。例如,在一個保險應用程序中,模型就是處理計算保險費和同數(shù)據庫交互的那些業(yè)務代碼。模型通常也被稱作業(yè)務邏輯。View：視圖表示模型的狀態(tài),是應用系統(tǒng)的外觀,當模型發(fā)生改變時,視圖也將隨之改變,以維持系統(tǒng)數(shù)據的一致性。在 MVC 模式下,通常的設計前提是界面任務較小,當然視圖也應該具有一定的功能性并遵守可用性的約束,但視圖界面不應當處理數(shù)據。事實上,視圖的每一部分都只能包含采集數(shù)據的邏輯,并把采集到的數(shù)據傳遞給設計模式中的其他組成部分進行處理。Controller：控制器是聯(lián)系模型與視圖之間的紐帶,控制模型和視圖之間的交互過程。它獲取并翻譯用戶輸入的動作,指定執(zhí)行該動作的模型,或者根據用戶的輸入和執(zhí)行的結果來選擇下一個視圖。 MVC設計模式在 J2EE平臺中的應用模型MVC 設計模式是一種用于分離數(shù)據維護和數(shù)據表現(xiàn)的方法,在 J2EE 中引入MVC 設計模式 ,有助于把應用劃分為合理的組件,從而可以方便的進行系統(tǒng)的開發(fā)、維護和擴充。隨著 J2EE 各種組件技術的廣泛應用和 MVC 設計模式的發(fā)展與完善,J2EE 與 MVC 設計模式在 WEB 應用系統(tǒng)開發(fā)領域達到了很好的結合。目前 ,這種結合己經被廣泛的應用于許多企業(yè)級 WEB 應用系統(tǒng)的開發(fā)過程中；其中,JSP 用于創(chuàng)建與用戶交互的視圖、JAVABEAN、EJB 等組件用于創(chuàng)建實現(xiàn)業(yè)務邏輯的模型,Servlet 用于創(chuàng)建實現(xiàn)業(yè)務邏輯與用戶交互的控制器。 WEB 應用客戶端的用戶動作被視圖傳遞給 Servlet 集中處理控制邏輯 ,調用 JavaBean 激活業(yè)務邏輯或修改模型狀態(tài),根據用戶動作和模型處理的結果,控制器選擇一個視圖作為用戶請求的響應。這樣就形成了清晰的 MVC 設計模式,簡化了 WEB 應用系統(tǒng)的開發(fā)?；?J2EE 和 MVC 設計模式的系統(tǒng)模型借鑒了 Model 2 的思想,其技術原理是：以 MySQL ,SQL SERVER,ORACLE 等企業(yè)級數(shù)據庫系統(tǒng)作為后臺數(shù)據庫,以Servlet 等高性能服務端程序作為后臺總控程序,JSP 頁面在前臺運行,Servlet 接受用戶的輸入,分別調用不同的 JSP 頁面向瀏覽器反饋信息,JSP/Servlet 通過 HTTP 連接在服務器端和瀏覽器端傳遞數(shù)據；JSP/Servlet 并不使用 JDBC 技術直接訪問數(shù)據庫系統(tǒng),而是把參數(shù)傳遞給 EJB 組件,由 EJB 組件對數(shù)據庫進行操作,這樣就可以封裝廣東工業(yè)大學工學碩士學位論文14系統(tǒng)的內部數(shù)據；JAVABEAN 和 EJB 組件還可以把事務分發(fā)到其他組件中進行處理,最后把從數(shù)據庫返回的結果,由 JSP/Servlet 發(fā)送到前端顯示。基于 J2EE 和 MVC 設計模式的系統(tǒng)模型以 WEB 瀏覽器作為客戶端 ,以 WEB服務器和 EJB 服務器作為中間層完成業(yè)務邏輯,數(shù)據層則是傳統(tǒng)的大型企業(yè)級數(shù)據庫服務器。WEB 服務器是 J2EE 體系結構中間層的一個重要組成部分。它在技術上主要是 Servlet 和 JavaBean,其功能是實現(xiàn)用戶界面的表現(xiàn)。由于 JSP 和 Servlet 本質上是服務端的 Java 小程序,因而可以與 Java Applet 及 HTTP 客戶端交互,具有執(zhí)行速度快、用戶界面生成靈活、安全性好等特點,同時還能使用 JAVABEAN 實現(xiàn)一些簡單的業(yè)務邏輯。J2EE 使用 EJB 服務器作為 EJB 組件的部署環(huán)境,在 EJB 服務器中提供了在分布式計算中組件需要的所有服務,如組件生命周期管理、數(shù)據庫連接管理、分布式事務管理、組件命名服務、自動容錯以及負載的自動均衡能力等。實現(xiàn)業(yè)務邏輯的 EJB 組件可以在服務器中高效運行,支持多客戶端訪問。HTTP 的客戶端一般先向運行在 WEB 服務器上的 Servlet 或者 JSP 發(fā)出請求,通過在 JSP 中嵌入的 Java 代碼或是 Servlet 來調用運行在 EJB 服務器中的 EJB 組件,以實現(xiàn)復雜的業(yè)務邏輯。 MVC設計模式的優(yōu)缺點一方面,分離數(shù)據和其表示,使得添加或者刪除一個用戶視圖變得很容易,甚至可以在程序執(zhí)行過程中動態(tài)的進行用戶視圖的更新。模型和視圖能夠單獨的開發(fā)(即業(yè)務邏輯和用戶表現(xiàn)的分離),增加了程序的可維護性、可擴展性,并使測試變得更容易。另一方面,將控制邏輯和表現(xiàn)界面分離,允許程序能夠在運行時根據工作流、用戶習慣或者模型狀態(tài)來動態(tài)選擇不同的用戶界面。最重要的一點是多個視圖能共享一個模型,現(xiàn)在一個應用程序需要用越來越多的方式訪問。在 MVC 設計模式之中,無論用戶想要 flash 界面或是 WAP 界面,用一個模型就能處理它們。因為 MVC 己經將數(shù)據和業(yè)務規(guī)則從表示層分開,模型返回的數(shù)據沒有進行格式化,同樣的構件能被不同界面使用,這當然包含 HTML 的表現(xiàn)方式,也有 flash 和 WAP 的表示處理界面,同時模型也有狀態(tài)管理和數(shù)據持久性處理第三章 相關技術介紹15的功能。例如,基于會話的購物車和電子商務過程也能被 flash 網站或者無線聯(lián)網的應用程序所重用。因而在 MVC 設計模式中應用開發(fā)人員可以最大化的重用他的代碼。因為模型是自包含的,并且與控制器和視圖相分離,所以很容易改變應用程序的數(shù)據層和業(yè)務規(guī)則。如果需要數(shù)據庫從 DB2 移植到 ORACLE,或者改變基于RDBMS 數(shù)據源到 LDAP,開發(fā)人員只需改變它的應用模型即可。一旦開發(fā)人員正確的實現(xiàn)了模型,不管數(shù)據來自數(shù)據庫或是 LDAP 服務器,視圖將會正確的顯示它們。由于運用 MVC 的應用程序的三個部件是相互對立,改變其中一個不會影響其它兩個,所以依據這種設計思想開發(fā)者能構造良好的松偶合的構件。由于 MVC 模式并不是十分簡單,其內部原理比較復雜,所以使用 MVC 模式需要精心設計。盡管 MVC 有許多優(yōu)點,但它并不是對所有應用都適用。對于小型應用,使用 MVC 會帶來額外的工作量,并且會增加應用的復雜性。在選擇 MVC 開發(fā)模式時必須仔細考慮這下問題：(1) JSP 頁面就能實現(xiàn)的應用現(xiàn)在變成了多個步驟的設計和實現(xiàn)過程。(2)所有的頁面和組件必須在 MVC 框架中實現(xiàn),所以必須進行附加地開發(fā)工作。(3) MVC 本身就是一個非常復雜的系統(tǒng),所以采用 MVC 實現(xiàn) WEB 應用時,最好選一個現(xiàn)成的 MVC 框架,在此之下進行開發(fā),從而取得事半功倍的效果?，F(xiàn)在有很多可供使用的 MVC 框架,Struts 就是一個不錯的框架。 UML面向對象的建模語言出現(xiàn)在 20 世紀 70 年代,隨著編程語言的多樣化以及軟件產品在更多領域的應用,當時的軟件工程學者開始分析與設計新的軟件方法論。在這期間出現(xiàn)了超過 50 種面向對象方法,對于這些不同符號體系的開發(fā)方法,軟件設計人員和開發(fā)人員往往很難找到完全適合他們的建模語言,而且這也妨礙了不同公司,甚至是不同項目開發(fā)團隊的交流與經驗共享。因此,有必要確立一款標準統(tǒng)一的、能被絕大部分軟件設計和開發(fā)人員認可的建模語言,在這種情況下,UML 應運而生。1997 年, 被 OMG(對象管理組織)采納,正式成為一款定義明確、功能強大、受到軟件行業(yè)普遍認可的、可適用于廣泛領域的建模語言。如今,UML 已經成為面向對象軟件系統(tǒng)分析設計的必備工具,也是廣大軟件系統(tǒng)設計人員、開發(fā)人廣東工業(yè)大學工學碩士學位論文16員、項目管理人員、系統(tǒng)工程師和分析員必須掌握的基礎知識。模型是對現(xiàn)實的簡化,建模是為了更好地理解系統(tǒng)。模型幫助我們按照實際情況對系統(tǒng)進行可視化,模型允許我們詳細說明系統(tǒng)的結構、行為,模型給出了構造系統(tǒng)的模板,模型對我們做出的決策進行文檔化。選擇創(chuàng)建什么模型對如何動手解決問題和如何形成解決方案具有重要意義。項目越大越復雜,建模業(yè)變得越重要。建模的意義：建?？梢圆蹲綐I(yè)務過程,建模可以捕捉業(yè)務對象和邏輯,建?？梢蕴幚韱栴}的復雜性,建?？梢杂脕矶x軟件架構,建模可以提高程序再用率。建模的 4 項原則：選擇建立什么樣的模型對解決方案的形成有很大影響；沒有哪一個模型或視圖是足夠的,要多個視點；每一個模型可以表示不同等級的細節(jié)；最好的模型總是和現(xiàn)實緊密相聯(lián)結。UML 的定義：(1) UML 代表統(tǒng)一建模語言(Unified Modeling Language)。(2) UML 最好地結合了如下四種建模語言的形式：數(shù)據建模概念(實體關系圖)。業(yè)務建模(工作流) 。對象建模，模塊建模。(3) UML 是一種用于圖示、規(guī)定、建構和歸檔軟件密集型系統(tǒng)的標準語言。它不依賴于具體語言,可以用于所有過程以及整個軟件開發(fā)生命周期。(4) UML 是一種圖形化語言。(5) UML 不僅僅是一組圖形符號,而且是在每一個圖形符號的后面定義了完善的語義。UML 的歷史首先, UML 融合了 Booch、OMT 和 OOSE 方法中的基本概念,而且這些基本概念與其他面向對象技術中的基本概念大多相同,因而,UML 必然成為這些方法以及其他方法的使用者愿意采用的一種簡單一致的建模語言；其次,UML 不僅僅是上述方法的簡單匯合,而是在這些方法的基礎上廣泛征求意見,集眾家之長,幾經修改而完成的,UML 擴展了現(xiàn)有方法的應用范圍；第三,UML 是標準的建模語言,而不是標準的開發(fā)過程。盡管 UML 的應用必然以系統(tǒng)的開發(fā)過程為背景 ,但由于不同的組織和不同的應用領域,需要采取不同的開發(fā)過程。第三章 相關技術介紹17 UML的定義UML 語義：描述基于 UML 的精確元模型定義。元模型為 UML 的所有元素在語法和語義上提供了簡單、一致、通用的定義性說明,使開發(fā)者能在語義上取得一致,消除了表達方法因人而異所造成的影響。此外 UML 還支持對元模型的擴展定義。UML 表示法：定義 UML 符號的表示法,為開發(fā)者或開發(fā)工具提供圖形符號和文本語法,為系統(tǒng)建模提供了標準。這些圖形符號和文字所表達的是應用級的模型,在語義上它是 UML 元模型的實例。 UML的內容第一類是用例圖,從用戶角度描述系統(tǒng)功能,并指出各功能的操作者。畫好用例圖是軟件需求到最終實現(xiàn)的第一步,在 UML 中用例圖用于對系統(tǒng)、子系統(tǒng)或類的行為可視化,以便使用戶更容易理解這些元素的用途,也便于軟件開發(fā)人員最終實現(xiàn)這些元素。UML 中的用例圖描述了一組用例、參與者以及它們之間的關系 ,因此用例圖包括以下 3 方面內容：(1)用例：用例是對一個系統(tǒng)或一個應用的一種單一的使用方式所作的描述,是關于單個活動者在與系統(tǒng)對話中執(zhí)行的處理行為的陳述序列。用例是一個敘述型文檔,用來描述參與者使用系統(tǒng)完成某個事件時的事情發(fā)生順序。用例是系統(tǒng)的使用過程,更確切地說,用例是需求或者功能的規(guī)格說明,但用例也展示和體現(xiàn)出了其描述的過程中的需求情況。從這些定義可知,用例是對系統(tǒng)的用戶需求的描述,用例表達了系統(tǒng)的功能和提供的服務。識別用例最好的辦法就是從分析系統(tǒng)的參與者開始,考慮每個參與者是怎樣使用系統(tǒng)。使用這種策略的過程中可能會找到一個新的參與者,這對完善整個系統(tǒng)建模很有幫助。用例建模的過程就是迭代和逐步細化的過程,系統(tǒng)分析師從用例的名稱開始,開始添加用例細節(jié)。在識別用例的過程中,能過以下幾個問題可以幫助識別用例：特定參與者希望系統(tǒng)提供什么功能；系統(tǒng)是否存儲和檢索信息,如果是,這個行為由哪個參與者觸發(fā)；當系統(tǒng)改變狀態(tài)時,通知參與者嗎存在影響系統(tǒng)的外部事廣東工業(yè)大學工學碩士學位論文18件嗎；是哪個參與者通知系統(tǒng)這些事情。(2)參與者：參與者是系統(tǒng)外部的一個實體,它以某種方式參與了用例的執(zhí)行過程。參與者通過向系統(tǒng)輸入或請求系統(tǒng)輸入某些事件來觸發(fā)系統(tǒng)的執(zhí)行。參與者由他們參與用例時擔當?shù)慕巧珌肀硎?。可以根據以下的一些問題來確定系統(tǒng)的參與者：誰或為什么使用該系統(tǒng)；交互中,它們扮演什么角色；誰安裝系統(tǒng)；誰啟動和關閉系統(tǒng)；誰維護系統(tǒng)；與該系統(tǒng)交互的是什么系統(tǒng)；誰從系統(tǒng)獲取信息；誰提供信息給系統(tǒng)；有什么事發(fā)生在固定事件。(3)參與者之間的關系：泛化關系,包含關系,擴展關系,應用這些關系是為了制取出系統(tǒng)的公共行為和變體。第二類是靜態(tài)圖(Stat