【正文】 ；第二是因為和別的軟件方法不同的是， ICONIX 更強調(diào)需求到設(shè)計之前的自然、有章可循的，同時也適合迭代的過渡，并且按照它自己的軟件方法思想，它對 UML 符號集在可擴充的前提下作了一定的取舍。圖 21 是 ICONIX 項目管理方法過程的總圖。目前，用于生成動態(tài)網(wǎng)頁較為流行的技術(shù)有 Microsoft 的 ASP、 Tex 的 PHP 和 Sun的 JSP。而 JSP 是一種完全與平臺無關(guān)的開發(fā)新技 術(shù)，它集極高的運行效率，較短的開發(fā)周期，超強的擴展能力，完全開放的技術(shù)標準，自由的開發(fā)方式等眾多完美特性于一身。 DBMS 數(shù)據(jù)庫用于數(shù)據(jù)存儲， JDBC 用于連接數(shù)據(jù)庫并對數(shù)據(jù)庫進行存儲， Servlet 用于處理過程控制， JavaBean 用于封裝業(yè)務(wù)邏輯， JSP用于頁面顯示部分。 MVC 模式基本原理 MVC ModelViewController ，即把一個應(yīng)用的輸入 、處理、輸出流程按照 Model, View, Controller 的方式進行分離，這樣一個應(yīng)用被分成三個層――模型層、視圖層、控制層，其三層之間的關(guān)系和功能如圖 22“ MVC 組件類型關(guān)系和功能圖”。 控制層 Controller 可以理解為從用戶接收請求，將模型與視圖匹配在一起，共同完成用戶的請求?？刂茖硬⒉蛔鋈魏蔚臄?shù)據(jù)處理。因此，一個模型可能對應(yīng)多個視圖，一個視圖可能對應(yīng)多個模型。業(yè)務(wù)流程的處理過程對其它層來說是黑箱操作，模型接受視圖請求的數(shù)據(jù)，并返回最終的處理結(jié)果。 MVC 并沒有提供模型的設(shè)計方法，而只告訴我們應(yīng)該組織管理這些模型，以便于模型的重構(gòu)和提高重用性。隨著應(yīng)用的復(fù)雜性和規(guī)模 性，界面的處理也變得具有挑戰(zhàn)性。業(yè)務(wù)流程的處理交予模型 Model 處理。 Model1 體系十分適合簡單應(yīng)用需要，卻不能滿足復(fù)雜的大型應(yīng)用程序的實現(xiàn)。 圖 23 MVC Model1 體系結(jié)構(gòu)圖 [5] MVC Model2 MVC 模式的 Model2 體系結(jié)構(gòu)是一種把 JSP 與 Servlet 聯(lián)合起來實現(xiàn)動態(tài)內(nèi)容服務(wù)的方法。這是一種有代表性的方法，它清晰地分離了表達和內(nèi)容，明確了角色的定義及開發(fā)者與網(wǎng)頁設(shè)計者的分工。 MVC Model2 的體系結(jié)構(gòu)如圖 24 所示。然后對 MVC 設(shè)計模式基本原理進行了詳細闡述，并介紹了 MVC 的兩種不同的模式 Model1 和 Model2,并確定本系統(tǒng)的設(shè)計模式便是 MVC Model2。需求分析的任務(wù)就是要解決“做什么”的問題，就是要全面地理解用戶的各項需求，并準確地表達所接受的用戶需求。 前臺顯示功能主要針對一般用戶的，當一般用戶在瀏覽新聞系統(tǒng)時，系統(tǒng)應(yīng)該對新聞欄目和新聞條目的顯示。具體需求見表 31 系統(tǒng)前臺顯示需求表。具體需求見表 32 系統(tǒng)后臺管理需求表。他們的行為不受系統(tǒng)控制，但是可以提供輸入信息。所以本系統(tǒng)應(yīng)包括兩個角色：一般用戶和系統(tǒng)管理員用戶。因此，系統(tǒng)角色可以統(tǒng)一為：用戶。 用例識別的目標是在需求描述和系統(tǒng)角色識別的基礎(chǔ)上，識別出角色相映的用例，從而 可以得出系統(tǒng)的用例模型，如圖 31 是“系統(tǒng)用例模型圖”。當用戶點擊某個欄目時，系統(tǒng)顯示相應(yīng)的新聞條目。 （ 2）登錄入口用例文檔： 基本流程：用戶在 前臺顯示頁面提供的登錄后臺系統(tǒng)的登錄入口中輸入用戶信息，系統(tǒng)根據(jù)用戶的登錄信息進行檢驗，然后進入系統(tǒng)后臺管理系統(tǒng)。 如果用戶輸入的信息不正確，系統(tǒng)將控制權(quán)交給“登錄錯誤”頁面，用戶可以在此重新輸入用戶名和密碼進行登錄。 （ 4）新聞管理用例文檔： 基本流程：用戶進入系統(tǒng)后便可瀏覽到新聞條目，在瀏覽過程中，用戶可以修改和 刪除新聞。 分支流程：如果用戶放棄對新聞的相應(yīng)操作，則系統(tǒng)直接將控制權(quán)交給后臺管理用例。 （ 5）添加新聞用例文檔： 基本流程：用戶填寫新聞相關(guān)信息，并確定添加新聞時，系統(tǒng)將存儲此新聞，并將控制權(quán)交給新聞管理用例。 （ 6）欄目管理用例文檔： 基本流程：用戶在后臺管理中選擇欄目管理時，用戶將瀏覽到系統(tǒng)已有欄目，并可對 其進行修改刪除操作，用戶在進行相應(yīng)操作后，系統(tǒng)會存儲新的信息，控制權(quán)將回到欄目管理用例。 如果用戶選擇添加欄目，控制權(quán)將交給添加欄目用例。 分支流程：如果用戶放棄欄目添加，控制權(quán)將直接交回到欄目管理用例。系統(tǒng)根據(jù)用例模型可以對用例進行細化，從而展 現(xiàn)整個用例的活動順序。 圖 32 前 臺 活動 順序 圖 圖 33 用戶登錄活動順序圖 圖 34 后臺新聞管理活動順序圖 圖 35 添加新聞活動順序圖 圖 36 欄目管理活動順序圖 圖 37 添加欄目活動順序圖 小結(jié) 本章從用戶的角度，分析了系統(tǒng)的需求用例，畫出了系統(tǒng)用例模型圖，并得出了相應(yīng)的用例文檔；做出了用例驅(qū)動分析，并得出了相應(yīng)的順序圖。 第 4 章 系統(tǒng)設(shè)計 根據(jù)上一章的需求用例分析，本章從先總體構(gòu)架的角度對系統(tǒng)進行總體設(shè)計，然后根據(jù) MVC 三層模式對系統(tǒng)進行詳細設(shè)計，最后對系統(tǒng)數(shù)據(jù)庫和數(shù)據(jù)庫連接池進行了設(shè)計。具體模式圖如圖 41。本系統(tǒng)具體構(gòu)架如圖 42。 在本系統(tǒng)中，根據(jù)第 3 章中對系統(tǒng)需求用例的分析，可以總結(jié)出如下的需求集 : （ 1）系統(tǒng)應(yīng)該分為前臺和后臺； （ 2）系統(tǒng)前臺應(yīng)該可以顯示新聞欄目和新聞以及用于管理員登錄系統(tǒng)后臺的登錄界面； （ 3）一般用戶應(yīng)該可以在前臺 自由瀏覽新聞，包括選擇性地瀏覽新聞即先選擇新聞欄目再瀏覽新聞欄目下的新聞條目；用戶在瀏覽新聞時，系統(tǒng)應(yīng)該可以將顯示給用戶一個包含新聞具體內(nèi)容的 HTML 文件； （ 4）系統(tǒng)管理員應(yīng)該可以登錄到系統(tǒng)后臺； （ 5）系統(tǒng)管理員應(yīng)該可以對新聞欄目和新聞進行查看、修改、刪除和添加操作。 由以上需求集進一步分析可知： （ 1）詞“系統(tǒng)”太模糊，不能成為一個對象的名稱；同樣，“前臺”和“后臺”為系統(tǒng)的兩個不同的區(qū)域，亦不能成為對象名稱； （ 2）“新聞欄目”和“新聞” 為系統(tǒng)的兩個主要內(nèi)容，所以應(yīng)該分別作為一個類，而新聞欄目和新聞的顯示需要管理類進行管理，系統(tǒng)管理員要對欄目和新聞進行查看、添加、修改和刪除，也需要相應(yīng)的管理類進行管理，所以，系統(tǒng)對于新聞欄目和新聞分別需要“欄目管理類”和 “新聞管理類”； （ 3）要將添加的新聞保存為一個 HTML 文件，需要一個從表單中收集信息并將其轉(zhuǎn)換為一個 HTML 文件的類； （ 4）系統(tǒng)要保存信息，必須用到數(shù)據(jù)庫，所以需要一個數(shù)據(jù)庫連接的類； （ 5）要將系統(tǒng)的各個功能執(zhí)行成功，少不了相應(yīng)的控制類。 視圖層設(shè)計 前臺設(shè)計 當一個用戶瀏覽新聞系統(tǒng)時，首先進入系統(tǒng)前臺界面。前臺界面設(shè)計如圖 43 所示。而對于一般用戶來說，他們也不會感覺這有何不妥，因為此登錄界面比較簡潔，并不會影響用戶正常地閱讀新聞。 再次，在新聞欄目的下方則是新聞條目的顯示，默認的新聞條目的顯示方式是以表格的形式將系統(tǒng)新聞數(shù)據(jù)表中的新聞按發(fā)布時間進行列表（發(fā)布較早的新聞被放在列表的后面，而發(fā)布較 遲的新聞被放在列表的前面，體現(xiàn)了新聞的“新”，即“時效性”）。 然后，用戶可以對自己比較關(guān)心和感興趣的新聞進行有選擇性地瀏覽，這時新聞欄目便起作用了。用戶可以在此瀏覽自己關(guān)心和感興趣的新聞。此界面主要是面向管理員的，界面要設(shè)計得簡潔方便，使得系統(tǒng)管理員在管理系統(tǒng)時容易操作。 圖 44 后臺管理系統(tǒng)主界面設(shè)計圖 當管理員用戶登錄到系統(tǒng)后臺時，呈現(xiàn)到他眼前的是系統(tǒng)后臺管理的主頁面： 首先，系統(tǒng)后臺主頁面左上角是歡迎詞（ Wele+管理員名），對于管理員，他可以感覺到系統(tǒng)的人性化；對于系統(tǒng)本身，系統(tǒng)可以識別此時登錄的是哪個管理員，可以分配管理員的權(quán)限。 再次，再往下就是系統(tǒng)新聞列表，與前臺新聞顯示類似，只是多了對新聞的操作（修改和刪除）。 添加新聞設(shè)計 如果系統(tǒng)管理員在系統(tǒng)后臺主頁面中選擇“添加新聞”，管理員會進入下圖這樣一個頁面進行新聞的添加，添加完新聞標題和新聞?wù)膬?nèi)容后，還必須選擇所添加新聞所屬的新聞欄目。管理員可以在系統(tǒng)后臺主頁面中看到剛剛發(fā)表的新聞，可以對其進行相關(guān)操作，如圖 45。欄目管理頁面上有一些鏈接按鈕，可以讓管理員鏈接到其他頁面。 如果管理員想要添加新聞欄目，只需點擊“添加欄目”，就可以被鏈接到添加新聞欄目頁面（因為此頁面比較簡單，所以并未給出具體設(shè)計圖 ），添加欄目完成后，管理員可以在欄目管理主頁面的欄目列表中找到新添加的欄目，并對其進行相關(guān)操作，如圖 46。模型層的類主要有新聞類 News 和新聞管理類 NewsMgr以及欄目類 Category 和欄目管理類 CategoryMgr。其相應(yīng)的功能模型如下圖 47。 表 41 前臺類責任表 名稱 類型 屬性 責任（或操作） Index page 邊界 無 顯示系統(tǒng)前臺主頁面，并提供管理員登錄 News 實體 新 聞 條目 的屬 性 新聞條目的抽象 NewsMgr 控制 無 根據(jù)新聞 ID得到新聞對象，獲得所有新聞和根據(jù)欄目 ID 得到該欄目的所有新聞 Login Form 邊界 無 提供管理員登錄，并負責客戶端的登錄完整性檢驗 main page 邊界 無 系統(tǒng)后臺管理主頁面 新聞管理 管理員在系統(tǒng)后臺主界面中可以對已有新聞進行管理（修改、刪除和添加），新聞管理模塊中充當模型層的仍然是 News 和 NewsMgr。 圖48 新聞管理靜態(tài)模型圖 根據(jù)上面的新聞管理模型，我們可以對各個類的責任和功能進行說明。 圖 49 欄目管理靜態(tài)模型圖 根據(jù)上面的欄目管理靜態(tài)模型設(shè)計，我們可以對各個類的責任和功能進行說明。所以登錄控制器必須對用戶登錄信息進行識別，判斷其是否有權(quán)限登錄到后臺系統(tǒng)。 圖 410 登錄控制靜態(tài)模型圖 根據(jù)圖 410 登錄控制靜態(tài)模型設(shè)計，對各個類的責任和功能進行說明。新聞管理靜態(tài)類圖如圖411。 表45 新聞管理控制層靜態(tài)類責任表 名稱 類型 屬性 責任（或操作） EditNewsServlet 控制 無 對已有新聞編輯的控制 DeleteNewsServlet 控制 無 對刪除已有新聞的控制 AddNewsServlet 控制 無 對添加新聞的控制 欄目管理 欄目管理模塊主要對新聞欄目進行修改、刪除和添加，此功能模塊控制層由EditCategoryServlet、 DeleteCategoryServlet 和 AddCategoryServlet 完成。 圖 412 欄目管理靜態(tài)模型圖 根據(jù)圖 412欄目管理靜態(tài)模型設(shè)計，對各個類的責任和功能進行說明。所以，數(shù)據(jù)庫需求分析中就要考慮兩方面因素。通過系統(tǒng)功能分析，針對一般新聞用戶的需求，總結(jié)出如下需求信息： （ 1）每個新聞對應(yīng)一個 HTML 文件； （ 2）每個新聞只能對應(yīng)一個新聞欄目； （ 3）每個欄目下可以有多個新聞。 對于系統(tǒng)管理員來說，他們所關(guān)心的是如何對新聞欄目和新聞的添加、修改和刪除。 數(shù)據(jù)庫概念設(shè)計 根據(jù)上面的數(shù)據(jù)庫需求分析，就可以構(gòu)造出各種實體，以及并根據(jù)它們的關(guān)系繪制出實體間的 ER 圖 [8]，為以后的邏輯設(shè)計打下基礎(chǔ)。 圖 413 實體之間關(guān)系的 ER 圖 [8] 數(shù)據(jù)庫邏輯設(shè)計 根據(jù)數(shù)據(jù)庫需求分析和數(shù)據(jù)庫概念設(shè)計，設(shè)計如下所示的數(shù)據(jù)項和數(shù)據(jù)結(jié)構(gòu)： 管理員表（用戶名，密碼），用戶名為主碼； 欄目表（欄目編號，欄目名稱），欄目編號為主碼； 新聞表（新聞編號，新聞標題，新聞內(nèi)容 ，管理員名，所屬欄目，發(fā)布時間），新聞編號為主碼，管理員名和所屬欄目為外碼； 數(shù)據(jù)庫表設(shè)計 數(shù)據(jù)庫邏輯設(shè)計完畢后，現(xiàn)在可以將上面的數(shù)據(jù)庫概念結(jié)構(gòu)轉(zhuǎn)化為某種數(shù)據(jù)庫系統(tǒng)所支持的實際數(shù)據(jù)庫模型。 新聞發(fā)布系統(tǒng)的數(shù)據(jù)庫中各表的設(shè)計結(jié)果如下面幾個表所示。 數(shù)據(jù)庫連接池的必要性 傳統(tǒng)的數(shù)據(jù)庫連接模式開發(fā)，存在很多問題。當有多個用戶連接系統(tǒng)的時候，在同一時間有可能會不止一個用戶需要數(shù)據(jù)庫連接，在這種情況下，系統(tǒng)開銷也是相當大的。