【正文】 否 否 網(wǎng)上售樓系統(tǒng)的設計與實現(xiàn) 15 表 42樓盤信息表 樓盤類型表 (BUILDSTYLE) 樓盤信類對應著樓盤類型，樓盤類型包括樓盤類型名稱，類型介紹。具體字段類型如表 43： 字段描述 字段名稱 字段類型 是否主鍵 是否為空 類型 ID ID 自動編號 是 否 類型名稱 STYLETITLE 字符類型 否 否 類型介紹 CONENT 字符類型 否 否 表 43樓盤類型表 樓盤訂單 表 (BUILDORDER) 用戶可以查看樓盤然后預訂樓盤，生成訂單，訂單具體信息包括樓盤 ID，用戶 ID，添加時間和是否處理。具體字段類型如表 44： 字段描述 字段名稱 字段類型 是否主鍵 是否為空 訂單 ID ID 自動編號 是 否 樓盤 ID BUILDING 整數(shù)類型 否 否 用戶 ID CUSTOMER 整數(shù)類型 否 否 添加時間 ADDTIME 時間類型 否 否 是否提交 SUBMIT 布爾類型 否 否 表 44樓盤訂單表 樓盤交易 表 (CUSTOMER) 用戶訂單處理后，生成交易表，記錄用戶和樓盤的交易信息。具體字段類型如表45： 字段描述 字段名稱 字段類型 是否主鍵 是否為空 交易 ID ID 自動編號 是 否 訂單 ID BUILDORDER 整數(shù)類型 否 否 用戶 ID CUSTOMER 整數(shù)類型 否 否 交易介紹 CONTENT 字符類型 否 否 網(wǎng)上售樓系統(tǒng)的設計與實現(xiàn) 16 添加時間 ADDTIME 時間類型 否 否 表 45樓盤 交易表 管理員信息 表 (ADMIN) 管理員信息不許具體的信息，只包括名稱和密碼。具體字段類型如表 46： 字段描述 字段名稱 字段類型 是否主鍵 是否為空 管理員 ID ID 自動編號 是 否 管理員名稱 NAME 字符類型 否 否 管理員密碼 PASSWD 字符類型 否 否 表 46管理員信息表 第五章 基于 UML 的系統(tǒng)建模 UML 概述及系統(tǒng)分析步驟 UML 概述 統(tǒng)一建模語言（ UML是 Unified Modeling Language的縮寫）是用來對軟 件密集系統(tǒng)進行可視化建模的一種語言。 UML為面向對象開發(fā)系統(tǒng)的產(chǎn)品進行說明、可視化、和編制文檔的一種標準語言。 UML是用面向對象圖的方式來描述任何類型的系統(tǒng)，具有很廣泛的應用領域。特別是在建立軟件系統(tǒng)的模型中，它支持從系統(tǒng)需求、系統(tǒng)分析到系統(tǒng)設計的整個建模過程，提供 UML圖形的編輯和美化工具，保證得到語法正確、語義完整的 UML圖形模型，并提供包括文檔管理和圖形打印等輔助支持。它不僅支持建立系統(tǒng)的靜態(tài)模型，還支持描述系統(tǒng)的動態(tài)模型。 網(wǎng)上售樓系統(tǒng)的設計與實現(xiàn) 17 UML由以下四部分組成： 1)視圖。 視圖是表達系統(tǒng)的某一方面特征的 UML建 模元素的子集，視圖并不是圖，它是由一個或者多個圖組成的對系統(tǒng)某個角度的抽象。在建立一個系統(tǒng)模型時，通過定義多個反應系統(tǒng)不同方面的視圖，才能對系統(tǒng)做出完整、精確的描述。 2)圖。 視圖由圖組成， UML通常提供 9種基本的圖，把這幾種基本圖結合起來就可以描述系統(tǒng)的所有視圖。 3)模型元素。 UML中模型元素包括事物和事物之間的聯(lián)系。事物描述了一般的面向對象的概念，如類、對象、接口、消息和組建等。事物之間的關系能夠把事物聯(lián)系在一起，組成有意義的結構模型。常見的聯(lián)系包括關聯(lián)關系、依賴關系、泛化關系、實現(xiàn)關系和聚合關系。 同一個模型元素可以在幾個不同的 UML圖中使用，不過同一個模型元素在任何圖中都保持相同的意義和符號。 4)通用機制。 UML提供的通用機制可以為模型元素提供額外的注釋、信息和語義。這些通用機制同時提供擴展機制，擴展機制允許用戶對 UML進行擴展，以便適應一個特定的方法和過程、組織或用戶。 UML的各種圖時 UML模型的重要組成部分，在本系統(tǒng)的建模過程中用到了用例圖和活動圖，以下是 9種具體的描述： 1)用例圖 用例圖（ Use Case Diagram）顯示多個外部參與者以及他們與系統(tǒng)提供的用例之間的連接。用例是系統(tǒng) 中的一個描述參與者與系統(tǒng)之間交互作用功能單元。用例僅僅描述系統(tǒng)參與者從外部觀察到的系統(tǒng)功能，并不描述這些功能在系統(tǒng)內(nèi)部的具體實現(xiàn)。用例圖的用途是列出系統(tǒng)中的用例和參與者，并顯示哪個參與者參與了哪些用例的執(zhí)行。 2)類圖 類是對應領域或應用解決方案中概念的描述。類圖（ Class Diagram）以類為中心組織，類圖中的其他元素或屬于某個類，或與類相關聯(lián)。類可以以多種方式相互連接：關聯(lián)、依賴（一個類依賴或使用另一個類）、特殊化（一個類是另一個類的特殊化），這些連接成為類之間的關系。所有的關系連同每個類的內(nèi)部結構 都在類圖中顯示。關系用類框之間的連線表示，不同的關系用連線上和連線端口處的修飾符來區(qū)別。 3)對象圖 對象圖（ Object Diagram）是類圖的變體，它使用與類圖相似的符號描述，不同之網(wǎng)上售樓系統(tǒng)的設計與實現(xiàn) 18 處在于對象圖顯示的是類的多個對象實例而非實際的類。可以說，對象圖是類圖的一個例子，用于顯示系統(tǒng)執(zhí)行時的一個可能的快照，即在某一時間點上系統(tǒng)可能呈現(xiàn)的樣子。對象圖和類圖表示的不同之處在于它用帶下劃線的對象名稱來表示對象，顯示一個關系中所有的實例。 4)狀態(tài)圖 狀態(tài)圖（ State Diagram）是對類描述的補充，它用于顯示類 的的對象可能具備的所有狀態(tài)，以及引起狀態(tài)改變的事件。狀態(tài)的變化稱之為轉換。狀態(tài)圖由對象的各個狀態(tài)和連接這些狀態(tài)的轉換組成。每個狀態(tài)對一個對象在其生命周期中滿足某種條件的一個時間段建模。事件的發(fā)生會觸發(fā)狀態(tài)間的轉換，導致對象從一種狀態(tài)轉換為另一種狀態(tài)。實際建模時，并不需要為所有的類都繪制狀態(tài)圖，僅對那些具有多個明確狀態(tài)并且這些狀態(tài)會影響和改變其行為的類才有繪制狀態(tài)圖的必要。此外，還可以為系統(tǒng)繪制整體狀態(tài)圖。 5)時序圖 時序圖（ Sequence Diagram）顯示多個對象之間的動作狀態(tài)，重點是顯示對象之間發(fā) 送的消息的時間順序。時序圖也是顯示對象之間的交互，就是在系統(tǒng)執(zhí)行時，某個指定時間點將發(fā)生的事情。時序圖的一個用途是用來表示用例中的行為順序，當執(zhí)行一個用理性為時，時序圖中的每條消息對應了一個類操作或狀態(tài)機中引起轉換的觸發(fā)事件。 6)協(xié)作圖 協(xié)作圖（ Collaboration Diagram）對一次交互中有意義的對象和對象間的鏈建模。除了顯示消息的交換以外，協(xié)作圖也是顯示對象以及他們之間的關系。時序圖和協(xié)作圖都可以表示各個對象間的交互關系，但它們的側重點不同。時序圖用消息的幾何排列關系來表達消息的時間順序，各 個角色之間的關系是隱含的。協(xié)作圖用各個角色的幾何排列表示角色之間的關系，并用消息來說明這些關系。在實際運用中可以根據(jù)需要選用這兩種圖：如果需要重點強調(diào)時間或順序，那么選擇時序圖；如果需要重點強調(diào)上下文。那么選擇協(xié)作圖。 7)活動圖 活動圖（ Activity Diagram）是狀態(tài)圖的一個變體，用來描述執(zhí)行算法的工作流程中涉及的活動。動作狀態(tài)代表了一個活動，即一個工作流程步驟或一個操作的執(zhí)行?；顒訄D由多個動作態(tài)組成，當一個動作完成之后，動作態(tài)將會改變，轉換為另一個新的狀態(tài)網(wǎng)上售樓系統(tǒng)的設計與實現(xiàn) 19 （在狀態(tài)圖內(nèi)，狀態(tài)在進行轉換之前需要標 明顯示的事件）。這樣，控制就在這些相互連接的動作狀態(tài)之間流動。此外，在活動圖中還可以顯示決策和條件，以及動作狀態(tài)的并發(fā)執(zhí)行。 8)組件圖 組件圖（ Component Diagram）用代碼來顯示代碼物理結構，組件圖可以是源代碼組件、二進制組件或一個可執(zhí)行的組件。一個組件包含它所實現(xiàn)的一個或者多個邏輯類的相關信息，根據(jù)組件圖中顯示的組件之間的依賴關系，可以容易地分析出某個組件的變化將會對其他組件產(chǎn)生什么樣的影響。通常說來，組件圖用于實際的編程工作中。 9)配置圖 配置圖（ Deployment Diagram） 用于顯示系統(tǒng)中的硬件和軟件的物理結構。配置圖可以顯示實際的計算機和設備（節(jié)點），還可以顯示它們之間的連接和連接的類型。在配置圖中顯示哪些節(jié)點內(nèi)，已經(jīng)分配了可以執(zhí)行的組件和對象，以顯示這些軟件單元分別在那個節(jié)點上運行。 基于 UML 面向對象的系統(tǒng)分析步驟 UML是一個功能強大的、面向對象的可視化系統(tǒng)分析的建模語言，它采用一套成熟的建模技術。它的各個模型可以幫助用戶開發(fā)人員更好地理解業(yè)務流程，建立更可靠、更完善的系統(tǒng)模型，從而使用戶和開發(fā)人員對問題的描述表達到相同的理解，以減少語義差異，保障分析的正確性 。 運用 UML進行面向對象系統(tǒng)分析設計，通常都要經(jīng)過如下 3個步驟。 1)識別系統(tǒng)的用例和角色。首先要對項目進行需求調(diào)研，分析項目的業(yè)務流程圖和數(shù)據(jù)流圖，以及項目中涉及的各級操作人員，識別出系統(tǒng)中的所有用例和角色；接著分析系統(tǒng)中個角和用例間的關系，使用 UML建模工具畫出系統(tǒng)的用例圖；最后，勾畫出系統(tǒng)的概念層模型，借助 UML建模工具描述概念層的類圖和活動圖。 2)進行系統(tǒng)分析并抽象出類。系統(tǒng)分析的任務是找出系統(tǒng)的所有需求并加以描述，同時建立特定領域模型，建立域模型有助于開發(fā)人員考察用例。從實際需求中抽象出類，并 描述各個類之間的關系。 3)設計系統(tǒng)，并設計系統(tǒng)中的類及其行為。設計階段由結構設計和詳細設計組成。結構設計是高層設計，其任務是定義包、包間的依賴關系和主要通信機制。包有利于描網(wǎng)上售樓系統(tǒng)的設計與實現(xiàn) 20 述系統(tǒng)的邏輯組成部分以及各個部分之間的依賴關系。詳細設計主要用來細化包的內(nèi)容，清晰的描述所有的類，同時使用 UNL的動態(tài)模型描述在特定環(huán)境下這些類的實例的行為。 樓房管理模塊的 結構 圖 樓房信息管理員可以查看樓房種類的信息，可以添加、刪除、修改樓房的種類和樓房。 如圖 51 圖 51 樓房信息管理結構圖 購物車模塊的 結構 圖 顧客可以通過購物車模塊購買樓房、下訂單和刪除訂單。 如圖 52 圖 52 購物車結構圖 樓房管理 添加 修改 刪除 樓房種類 樓房 樓房種類 樓房 樓房種類 樓房 購物車 購買樓房 下訂單 刪除訂單 網(wǎng)上售樓系統(tǒng)的設計與實現(xiàn) 21 留言信息管理模塊的 結構 圖 管理員可以查看顧客的留言信息（包括：用戶名、留言主題、留言內(nèi)容、留言時間），同時也可以進行沒用的留言信息的刪除 ，圖 53 為結構圖 圖 53 留言管理結構圖 留言信息管理 查看留言 回復留言 刪除留言 修改留言 網(wǎng)上售樓系統(tǒng)的設計與實現(xiàn) 22 第六章 系統(tǒng)實現(xiàn) 網(wǎng)站總體架構及實現(xiàn) 系統(tǒng)總體結構圖 圖 61 為網(wǎng)站的總體結構 圖 61 網(wǎng)站的總體結構 用戶首頁界面風格 網(wǎng)上樓房銷售系統(tǒng)的主頁面向用戶展示了推薦樓房信息、新上架樓房信息、最暢銷樓房信息、系統(tǒng)的公告信息、對自己喜歡的樓房類別進行投票和查看樓房類別的入口。如果用戶想購買樓房和發(fā)表樓房的評論必須登錄系統(tǒng)，才能進行操作。 圖 61 為網(wǎng)站的首頁截圖 系統(tǒng)入口 樓房瀏覽模塊 樓房管理模塊 購物車模塊 訂單管理模塊 留言信息模塊 顧客留言信息管理模塊 樓房類別信息管理模塊 顧客的注冊、登錄模塊 推薦樓房信息顯示模塊 后臺信息管理的登錄模塊 用戶管理模塊 網(wǎng)上售樓系統(tǒng)的設計與實現(xiàn) 23 圖 61 網(wǎng)站首頁截圖 樓房信息查詢 功能描述 用戶在查詢樓房文本域中輸入樓房名稱，點擊查詢按鈕進行站內(nèi)搜索，然后將搜索結果列出。 模塊流程圖 如圖 62 是樓房信息查詢的流程圖 圖 62 樓房查詢信息流程圖 網(wǎng)上售樓系統(tǒng)的設計與實現(xiàn) 24 界面風格 如圖 63 是樓房查詢模塊截圖 圖 63 樓房查詢模塊截圖 實現(xiàn)算法 String building key=(building key)。//獲取查詢參數(shù) Building Logic building Logic = new Building Logic()。 ArrayList result = null。 //結果集 HttpSession session = ()。 ( _RESULT)。 if(building key==null||building ()){ //調(diào)用業(yè)務邏輯層的 building search() result = (ArrayList) building Search(all)。 ( _RESULT, result)。 // 將結果存到 session 中 }else{ result = (Arra