“京北”網(wǎng)上購物商城項目需求與設(shè)計文檔修訂版

“京北”網(wǎng)上購物商城項目需求與設(shè)計文檔該文檔作為一個案例，讀者可參看系統(tǒng)分析、設(shè)計主要達到什么目的；需求分析和設(shè)計方案如何表達、描述。一個實際系統(tǒng)的需求分析和設(shè)計文檔比該案例文檔要更加細致、全面。該文檔案例的目的是使讀者了解需求分析和設(shè)計要完成哪些工作、需求分析和設(shè)計文檔應(yīng)包括什么內(nèi)容。該文檔作為一個案例，讀者可參看系統(tǒng)分析、設(shè)計主要達到什么目的；需求分析和設(shè)計方案如何表達、描述。一個實際系統(tǒng)的需求分析和設(shè)計文檔比該案例文檔要更加細致、全面。該文檔案例的目的是使讀者了解需求分析和設(shè)計要完成哪些工作、需求分析和設(shè)計文檔應(yīng)包括什么內(nèi)容。實際項目中需求和設(shè)計文檔的撰寫要求非常嚴格，內(nèi)容要全面、表述準確。該文檔的設(shè)計部分不包含詳細設(shè)計。作者：中國石油大學(xué)（華東）計算機科學(xué)與技術(shù)學(xué)院軟件21級樊穎

1系統(tǒng)愿景 41.1概述 41.2定位 41.2.1問題描述 41.2.2項目定位 41.3用戶概述及目標 41.3.1用戶概述 41.3.2目標 41.3.3用戶環(huán)境 51.4項目說明 51.5系統(tǒng)特性 61.5.1關(guān)鍵特性 61.5.2其他特性 61.6其他需求和約束 71.6.1質(zhì)量屬性 71.6.2約束 72需求分析 82.1用例建模 82.1.1參與者和用例 82.1.2用例優(yōu)先級 132.1.3關(guān)鍵用例 132.2補充規(guī)約 162.2.1非功能性需求 162.2.2約束 162.3術(shù)語表 163面向?qū)ο蠓治瞿Ｐ?173.1業(yè)務(wù)建模 173.1.1上下文描述 173.1.2識別類 173.1.3類間關(guān)系的確定 173.1.4類圖 183.2分析層——職責確定及分配 183.3分析層——關(guān)鍵用例實現(xiàn) 203.3.1提交訂單用例實現(xiàn) 203.3.2售后處理用例實現(xiàn) 233.3.3話題廣場管理用例實現(xiàn) 264面向?qū)ο笤O(shè)計模型 294.1架構(gòu)設(shè)計 294.2用例設(shè)計 324.2.1提交訂單用例設(shè)計 324.2.2售后處理用例設(shè)計 344.2.3話題廣場管理用例設(shè)計 354.3子系統(tǒng)設(shè)計 364.4類的設(shè)計 365精化設(shè)計與模式應(yīng)用 385.1創(chuàng)建型模式 385.1.1單例模式 385.1.1工廠方法模式 385.2結(jié)構(gòu)型模式 395.2.1門面模式 395.2.2適配器模式 405.3行為型模式 415.3.1觀察者模式 415.3.2狀態(tài)模式 425.3.3策略模式 43

1系統(tǒng)愿景1.1概述在科技飛速發(fā)展的今天，互聯(lián)網(wǎng)已日益成為提供信息的最佳渠道并逐步進入傳統(tǒng)的流通領(lǐng)域，只依賴線下專賣店銷售的模式跟不上時代進步，幾乎所有的傳統(tǒng)行業(yè)都面臨向信息時代轉(zhuǎn)型的挑戰(zhàn)。民眾的購買習慣也在漸漸地朝著“配送到戶；隨時、自由購買”的方向發(fā)展。網(wǎng)絡(luò)購物在“實地消費、網(wǎng)絡(luò)下單”的基礎(chǔ)上依靠網(wǎng)絡(luò)極大地豐富了商品銷售行業(yè)的服務(wù)手段，充分利用了互聯(lián)網(wǎng)“時效性強、客戶端普及”的特點，增加了利潤的來源空間，擴大了受利群體。1.2定位1.2.1問題描述“京北”網(wǎng)上購物商城系統(tǒng)，該系統(tǒng)致力于滿足用戶能享受商品及時配送等多元化的需求，提升用戶的使用體驗，給更多的商家提供機會，使其利用線上銷售的模式拓展自身的業(yè)務(wù)范圍。1.2.2項目定位“京北”網(wǎng)上購物商城系統(tǒng)致力于用科技打造人們的生活服務(wù)平臺，推動商品銷售行業(yè)的數(shù)字化進程。它能解決傳統(tǒng)商品線下購買難計算、難查找、難更改、易出錯、效率低等問題，為用戶提供便捷的服務(wù)和極致的體驗，為店鋪提供一體化的運營方案。系統(tǒng)面向大眾群體，覆蓋了當前購物系統(tǒng)的基本功能，并在此基礎(chǔ)上進行了優(yōu)化，為用戶提供更豐富與更貼心的使用體驗。1.3用戶概述及目標1.3.1用戶概述該系統(tǒng)的主要用戶為全球范圍內(nèi)的登錄者，具體包括顧客、商家、職員等。其中，顧客可以進行購物、訂單信息管理、收藏管理、修改個人信息、舉報投訴等操作，商家可以進行商品信息管理、訂單信息管理、舉報投訴管理、交流論壇管理等操作。1.3.2目標該系統(tǒng)的短期目標為占據(jù)中國及周邊國家的網(wǎng)上購物系統(tǒng)市場，長遠目標為占據(jù)全球網(wǎng)上購物系統(tǒng)市場。1.3.3用戶環(huán)境PC端推薦使用Windows、Linux系統(tǒng)，用戶可以根據(jù)自己的需要選擇，沒有特殊的平臺限制。手機端APP支持Android4.0以上及ios8以上的任何手機系統(tǒng)。財務(wù)人員喜歡使用Excel等工具來處理財務(wù)事務(wù)，他們希望能夠方便、快捷地查看和導(dǎo)出訂單數(shù)據(jù)、銷售數(shù)據(jù)以及其他相關(guān)的財務(wù)數(shù)據(jù)。希望該系統(tǒng)能夠提供簡潔明了的報表功能，支持導(dǎo)出數(shù)據(jù)為Excel格式，方便進行數(shù)據(jù)分析和處理。商家希望能夠輕松管理和監(jiān)控自己的店鋪和商品銷售情況，希望能夠?qū)崟r查看店鋪的訪客流量、訂單量以及銷售額等關(guān)鍵指標，并可以方便地對商品進行上下架、價格調(diào)整等操作。同時，他們也希望能夠及時收到訂單和處理退換貨的申請等通知。1.4項目說明1.4標題改為“項目需求說明”1.4標題改為“項目需求說明”該系統(tǒng)的用戶主要分為三類，分別為：顧客、商家和職員。顧客通過賬號登陸系統(tǒng)后臺，可以執(zhí)行購物該段中對顧客、商家、職員需求的說明與“用戶概述部分重復(fù)”用戶概述部分可以移到項目說明部分，單列一個三級標題。、收藏管理、修改個人信息、舉報投訴等操作，并可以查看訂單信息、個人信息、購物車信息等內(nèi)容。商家通過賬號登陸系統(tǒng)，可以執(zhí)行商品信息管理、訂單信息管理、舉報投訴管理等操作，同時可以通過系統(tǒng)查詢店鋪信息、商品信息、訂單信息等內(nèi)容。職員可以執(zhí)行廣告發(fā)布、公告發(fā)布、消費者保護等操作。該段中對顧客、商家、職員需求的說明與“用戶概述部分重復(fù)”用戶概述部分可以移到項目說明部分，單列一個三級標題。該系統(tǒng)可與其他外部系統(tǒng)進行交互，例如：通過微信、QQ等第三方登錄系統(tǒng)進行身份驗證登錄該系統(tǒng)；從第三方支付系統(tǒng)進行訂單支付；從第三方文件系統(tǒng)查看和導(dǎo)出特定格式的訂單數(shù)據(jù)、銷售數(shù)據(jù)以及其他相關(guān)的財務(wù)數(shù)據(jù)等，方便進行數(shù)據(jù)分析和處理。圖圖1-1京北網(wǎng)上購物系統(tǒng)語境圖該系統(tǒng)由眾多的功能模塊構(gòu)成，如商品管理、訂單管理、購物車管理等。這些功能模塊并不是固定的，而是可以根據(jù)實際需要進行增刪，具有充分的靈活性。部分功能模塊介紹：商品管理：商品信息的增、刪、改查等。評價管理：進行商品評價等。購物車管理：添加商品到購物車、從購物車中移出商品等。因為該圖只是描述了該系統(tǒng)可能具有的功能模塊，并不表示拓撲關(guān)系。所以圖名為“拓撲結(jié)構(gòu)圖”不妥，改為“功能構(gòu)成圖”因為該圖只是描述了該系統(tǒng)可能具有的功能模塊，并不表示拓撲關(guān)系。所以圖名為“拓撲結(jié)構(gòu)圖”不妥，改為“功能構(gòu)成圖”圖圖1-2京北網(wǎng)上購物系統(tǒng)功能結(jié)構(gòu)圖1.5系統(tǒng)特性1.5.1關(guān)鍵特性商品搜索和過濾：提供高效的搜索功能，支持關(guān)鍵詞搜索，也支持商品分類、價格范圍等多種過濾方式，幫助用戶快速找到所需商品。個性化推薦引擎：基于用戶的歷史購買記錄、瀏覽行為和偏好，提供個性化的商品推薦，增加購買轉(zhuǎn)化率。社交互動：話題廣場允許用戶發(fā)表關(guān)于美食、餐廳、出行、本地生活等主題的帖子，與其他用戶互動，分享經(jīng)驗和建議。1該段對各種特性的說明不夠明確、詳細。.5.2其他特性該段對各種特性的說明不夠明確、詳細。美觀性：該系統(tǒng)的界面由眾多專業(yè)的美工人員設(shè)計，且聽取了部分用戶的建議，對界面布局等進行了專門優(yōu)化。計劃使用Element-ui界面開發(fā)工具，Element-ui囊括了眾多小巧美觀的組件，可開發(fā)出靈動而富有現(xiàn)代氣息的界面。易用性：考慮到使用系統(tǒng)的用戶遍布各個年齡段且認知水平不同，需要進行易用性設(shè)計。界面設(shè)計人員分析了不同用戶的常用功能，并將它們放置在界面的主要區(qū)域，從而做到了一點即達，減少不必要的操作。不同類別用戶的界面因功能不同略有差別，均應(yīng)做到簡潔易用。此外，界面應(yīng)提供白天/夜間模式切換、長輩關(guān)懷模式等功能，充分考慮不同用戶人群的需要。完備性：在設(shè)計系統(tǒng)時，充分考慮了用戶的各種功能訴求，據(jù)此構(gòu)建出功能完備的系統(tǒng)。該系統(tǒng)可以滿足用戶的各種需求，并且還將根據(jù)情況變化不斷完善豐富。靈活性：考慮到不同地區(qū)不同國家購物訴求不盡相同，系統(tǒng)功能模塊間的耦合度較低，可以根據(jù)實際需要進行功能模塊的刪減，以滿足實際的需要。此外，系統(tǒng)采用前后端分離的模式開發(fā)，便于進行靈活的調(diào)整維護。1.6其他需求和約束1.6.1質(zhì)量屬性性能：響應(yīng)快——該系統(tǒng)需要能在用戶請求后的500ms內(nèi)做出響應(yīng)，及時地反饋結(jié)果給用戶，不能讓用戶長時間等待。如果某些功能確實需要較長時間返回結(jié)果，則應(yīng)考慮將其分拆成更小的功能模塊，或者在界面的醒目位置適時給予用戶提示，告知當前事務(wù)的處理情況。頁面加載快—該系統(tǒng)需要能在2s內(nèi)加載完成所需頁面，以保證用戶體驗。高吞吐量—該系統(tǒng)支持每秒處理1000個并發(fā)請求。高可靠：該系統(tǒng)需要支持高并發(fā)，并且能穩(wěn)定運行，不能因為各種原因輕易崩潰。該系統(tǒng)需要在99.9%的時間內(nèi)保持可用狀態(tài)，最多只允許每月1小時的不可用時間。高安全：考慮到網(wǎng)上購物系統(tǒng)與用戶的私密息息相關(guān)，該系統(tǒng)必須具有很強的安全性。主要體現(xiàn)在以下幾個方面：數(shù)據(jù)庫中的數(shù)據(jù)加密存儲，不能被輕易篡改，且保持有多份備份，定期更新；系統(tǒng)能防御常見的網(wǎng)絡(luò)攻擊和入侵，如DDOS攻擊、SQL注入攻擊等；系統(tǒng)運行時需要保存運行日志，便于發(fā)現(xiàn)問題后及時處理。合規(guī)性：該系統(tǒng)需要遵守各種法律法規(guī)的要求，不能逾越制度紅線。1.6.2約束開發(fā)過程約束：要求本軟件系統(tǒng)開發(fā)方要組建一支專業(yè)的開發(fā)團隊，在客戶現(xiàn)場進行開發(fā)。運行環(huán)境及技術(shù)約束：為節(jié)省軟件運行、維護的成本，要求未來軟件運行環(huán)境盡量采用開源軟件。交付及部署約束：要求必須在三個月內(nèi)完成開發(fā)。部署時要利用客戶已有的硬件資源，包括web服務(wù)器和數(shù)據(jù)庫服務(wù)器。2需求分析該部分建議增加活動圖，把業(yè)務(wù)模型描述得更清晰。再分析和表述業(yè)務(wù)內(nèi)容和流程后再給出用例圖。該部分建議增加活動圖，把業(yè)務(wù)模型描述得更清晰。再分析和表述業(yè)務(wù)內(nèi)容和流程后再給出用例圖。2.1用例建模2.1.1參與者和用例通過先找外部環(huán)境的參與者，再通過找參與者需要的功能、參與者需要知道的消息以及系統(tǒng)內(nèi)部需要的維護、設(shè)置等功能，確定的參與者和用例如下。本系統(tǒng)的參與者為顧客、商家和職員。顧客、商家和職員與用戶之間是繼承關(guān)系。所有用戶均可以執(zhí)行注冊、登錄、個人信息管理、話題廣場管理和交互管理等操作。顧客可以執(zhí)行搜索商品、購物車管理、提交訂單、優(yōu)惠卡辦理和評價等操作。商家可以執(zhí)行商品管理、倉庫管理、銷售管理、訂單管理、售后處理和店鋪信息管理等操作。職員可以執(zhí)行廣告發(fā)布、公告發(fā)布和消費者保護等操作。圖圖2-1京北網(wǎng)上購物系統(tǒng)頂層用例圖用戶可以根據(jù)自己的需要修改賬號密碼；身份認證，用于提升賬號的安全性和信任級別，認證后的有商家記錄的賬號不能修改認證信息；設(shè)置安全保護郵箱，不同于登錄郵箱，當用戶選擇“安全保護問題”找回密碼時，填寫正確的問題答案后，系統(tǒng)會將新密碼發(fā)到用戶的安全郵箱；設(shè)置手機綁定，綁定手機后，用戶即可享受京北豐富的手機服務(wù)，如手機登錄，手機找回密碼、開通手機動態(tài)密碼等。圖圖2-2京北網(wǎng)上用戶用例圖顧客把所需的商品加入購物車，后進入到查看購物車頁面，顯示購物車中所有商品名稱、數(shù)量、單價、金額、積分、優(yōu)惠、以及總價，可以修改商品的數(shù)量、刪除商品、清空購物車等；選定商品或加入購物車完畢，即可進入提交訂單狀態(tài)，成功，便可執(zhí)行確認訂單信息收貨地址、確認訂單信息（數(shù)量，送貨方式、顧客留言）、配置付款方式等操作；購買商家的商品以后，給出評分；只要成功購買過商家的商品，就有可能獲得該商家的會員卡，會員卡可以打折，商家可以通過設(shè)定會員卡標準將顧客設(shè)定為高級會員，VIP會員或者至尊VIP會員。圖圖2-3京北網(wǎng)上購物系統(tǒng)顧客用例圖待交易狀態(tài)為“顧客已付款”，可以根據(jù)顧客留下的收貨地址聯(lián)系快遞公司進行發(fā)貨，待貨物發(fā)出后，需要在發(fā)貨頁面填寫正確的發(fā)貨信息，交易狀態(tài)將更改為“商家已發(fā)貨”，待顧客收到貨物確認打款給商家后，商家的支付寶賬戶就會收到該筆交易的款項，雙方也就完成該筆交易，如顧客未主動操作確認付款給商家，且也未在交易超時打款之前申請退款，那么等交易超時后，系統(tǒng)將自動打款給商家；在未發(fā)貨狀態(tài)下點擊“同意退款申請”，同意退款，并填寫支付密碼、在已發(fā)貨狀態(tài)下點擊“同意退款申請”，選擇“同意顧客退款協(xié)議”，并選擇退貨地址（必選）、或者在顧客退貨后同意退款協(xié)議點擊“同意退款”，并填寫支付密碼可退款成功；綁定的支付寶賬戶已經(jīng)通過實名認證，商家可以點擊我是商家，我要賣，選擇商品類目，編輯商品信息，進行商品的發(fā)布；商家可以點擊我是商家，倉庫里的商品，待您處理的違規(guī)商品，查看被下架的違規(guī)商品，如果這些違規(guī)商品已經(jīng)被您重新編輯并上架，則會在出售中的商品顯示，如已刪除，則不會再顯示。圖圖2-4京北網(wǎng)上購物系統(tǒng)商家用例圖職員可以分別對沒有如實描述、假一賠三、30天維修、7天退換等情況進行處理，以對消費者進行保護。把“假一賠三”改為“賠償管理”把“假一賠三”改為“賠償管理”圖圖2-5京北網(wǎng)上購物系統(tǒng)職員用例圖2.1.2用例優(yōu)先級注：為了便于比較，僅描述頂層用例圖的用例優(yōu)先級。優(yōu)先級數(shù)值越低表明該用例優(yōu)先級越高。用例優(yōu)先級往往與用例功能所涉及到的進程優(yōu)先級和用例開發(fā)的安排有關(guān)，此處的優(yōu)先級給得很隨意。用例優(yōu)先級往往與用例功能所涉及到的進程優(yōu)先級和用例開發(fā)的安排有關(guān)，此處的優(yōu)先級給得很隨意。用例名稱用例概述用例優(yōu)先級搜索商品按某種條件搜索特定商品。0商品管理增加、刪除、修改商品等。1個人信息管理設(shè)置、修改個人信息等。2提交訂單顧客提交訂單信息以生成訂單請求。3訂單管理接受顧客訂單請求、查詢所有訂單信息等。4售后處理訂單結(jié)束后，處理顧客發(fā)起的退換貨等請求。5購物車管理查看購物車、加入購物車、修改購物車等。6話題廣場管理發(fā)布話題、發(fā)布帖子、回復(fù)帖子、查看帖子等。7交互管理用戶發(fā)出消息，與其他用戶進行實時交互。8倉庫管理商品上架、查詢賣完商品、違規(guī)處理等。9銷售管理特定時間段采用特殊策略進行銷售。10店鋪信息管理設(shè)置店鋪信息、修改店鋪信息等。11注冊為不同目的登錄系統(tǒng)的用戶注冊為不同的角色。12登錄用戶進入系統(tǒng)時驗證用戶身份。13評價訂單結(jié)束后，顧客對商品做出評價。14優(yōu)惠卡辦理顧客提交訂單時的優(yōu)惠處理。15消費者保護職員對處于不同情況的消費者采取不同的保護方式。16廣告發(fā)布在頁面?zhèn)葯谶M行廣告發(fā)布以達到宣傳的目的。17公告發(fā)布將平臺的特殊情況公告給每個用戶。182.1.3關(guān)鍵用例1提交訂單用例生成訂單用例描述用例名稱：生成訂單用例編號：001用例簡述：顧客選好商品后發(fā)起生成訂單請求?；臼录鳎海?）顧客將商品加入購物車后，點擊生成訂單。（2）系統(tǒng)進行結(jié)算，選擇支付方式進行付款。（3）付款成功，生成訂單信息。主要參與者：顧客前置條件：顧客成功進入購物車業(yè)務(wù)功能界面。后置條件：系統(tǒng)向商家發(fā)送提醒信息，當前交易狀態(tài)更改為“顧客已付款”。查看訂單用例描述用例名稱：查看訂單用例編號：002用例簡述：在訂單生成后，顧客查看訂單信息?；臼录鳎海?）顧客進入查看訂單信息界面。（2）系統(tǒng)顯示該用戶提交訂單的最新詳細信息。主要參與者：顧客前置條件：顧客成功進入查看訂單信息業(yè)務(wù)功能界面。后置條件：界面顯示訂單最新詳細信息。取消訂單用例描述用例名稱：取消訂單用例編號：003用例簡述：顧客在訂單狀態(tài)變更之前取消訂單?；臼录鳎海?）顧客在查看訂單信息界面點擊取消訂單。（2）訂單被取消，刪除該訂單相關(guān)信息。主要參與者：顧客前置條件：顧客成功進入查看訂單信息業(yè)務(wù)功能界面。后置條件：將該訂單信息在商家的訂單列表中刪除。修改訂單用例描述用例名稱：修改訂單用例編號：004用例簡述：顧客在訂單狀態(tài)變更之前修改訂單?；臼录鳎海?）顧客在查看訂單信息界面點擊修改訂單。（2）顧客在修改訂單信息界面重新輸入需要修改的訂單信息。（3）顧客重新輸入訂單信息完畢后點擊確定。（4）系統(tǒng)根據(jù)重新提交的訂單信息更新訂單信息，自動刷新查看訂單信息界面。主要參與者：顧客前置條件：顧客成功進入查看訂單信息業(yè)務(wù)功能界面。后置條件：將該訂單信息在商家的訂單列表中更新。2售后處理用例退貨處理用例描述用例名稱：退貨處理用例編號：005用例簡述：顧客發(fā)起退貨請求?；臼录鳎呵闆r一，若商品狀態(tài)為“未發(fā)貨”：（1）顧客在查看訂單信息界面點擊退貨。（2）第三方支付系統(tǒng)直接退款。（3）第三方支付系統(tǒng)通知商家退款信息，商家修改商品狀態(tài)。情況二，若商品狀態(tài)為“已發(fā)貨”：（1）顧客在查看訂單信息界面點擊退貨。（2）顧客提交退貨訂單和退貨相關(guān)信息（運費哪方支付等）給第三方支付系統(tǒng)。（3）第三方支付系統(tǒng)再發(fā)送給商家，商家是否接受退貨相關(guān)信息。（4）商家不接受則繼續(xù)協(xié)商；商家接受則顧客在指定地點寄出商品，商家收到顧客的商品并確認退貨處理，第三方支付系統(tǒng)自動把付款退回顧客。主要參與者：顧客、商家前置條件：顧客成功進入查看訂單信息業(yè)務(wù)功能界面。后置條件：將該訂單信息更新。3話題廣場管理用例查看帖子用例描述用例名稱：查看帖子用例編號：006用例簡述：用戶發(fā)起查看帖子請求?；臼录鳎海?）用戶進入話題廣場，選擇感興趣的某一話題。（2）用戶點擊該話題下的某篇帖子。（3）系統(tǒng)顯示該被選中帖子的詳細信息。主要參與者：用戶前置條件：用戶成功進入話題廣場業(yè)務(wù)功能界面。后置條件：界面顯示被選中帖子的詳細信息。發(fā)布帖子用例描述用例名稱：發(fā)布帖子用例編號：007用例簡述：用戶發(fā)起發(fā)布帖子請求?；臼录鳎海?）用戶進入話題廣場，選擇感興趣的某一話題。（2）用戶點擊發(fā)布帖子。（3）用戶輸入要發(fā)布的帖子內(nèi)容，點擊發(fā)布。（4）系統(tǒng)顯示最新發(fā)布的帖子信息。主要參與者：用戶前置條件：用戶成功進入話題廣場業(yè)務(wù)功能界面。后置條件：界面顯示最新發(fā)布的帖子信息。刪除帖子用例描述用例名稱：刪除帖子用例編號：008用例簡述：用戶發(fā)起刪除帖子請求。基本事件流：（1）用戶進入自己發(fā)布的且需要刪除的一篇帖子。（2）用戶點擊刪除帖子。（3）系統(tǒng)刪除該帖子的相關(guān)信息。主要參與者：用戶前置條件：用戶成功進入話題廣場業(yè)務(wù)功能界面。后置條件：將該帖子信息刪除。評論帖子用例描述用例名稱：評論帖子用例編號：009用例簡述：用戶發(fā)起評論帖子請求。基本事件流：（1）用戶進入選擇感興趣的某一帖子。（2）用戶點擊發(fā)布評論。（3）用戶輸入要發(fā)布的評論內(nèi)容，點擊發(fā)布。（4）系統(tǒng)顯示最新發(fā)布的評論信息。主要參與者：用戶前置條件：用戶成功進入話題廣場業(yè)務(wù)功能界面。后置條件：界面顯示最新發(fā)布的評論信息。2.2補充規(guī)約2.2.1非功能性需求性能：響應(yīng)快——該系統(tǒng)需要能在用戶請求后的500ms內(nèi)做出響應(yīng)，及時地反饋結(jié)果給用戶，不能讓用戶長時間等待。如果某些功能確實需要較長時間返回結(jié)果，則應(yīng)考慮將其分拆成更小的功能模塊，或者在界面該部分內(nèi)容與《1.6.1質(zhì)量屬性》部分重復(fù)。系統(tǒng)愿景部分屬于需求分析部分的內(nèi)容建議移到需求分析部分。該部分內(nèi)容與《1.6.1質(zhì)量屬性》部分重復(fù)。系統(tǒng)愿景部分屬于需求分析部分的內(nèi)容建議移到需求分析部分。高可靠：該系統(tǒng)需要支持高并發(fā)，并且能穩(wěn)定運行，不能因為各種原因輕易崩潰。該系統(tǒng)需要在99.9%的時間內(nèi)保持可用狀態(tài)，最多只允許每月1小時的不可用時間。高安全：考慮到網(wǎng)上購物系統(tǒng)與用戶的私密息息相關(guān)，該系統(tǒng)必須具有很強的安全性。主要體現(xiàn)在以下幾個方面：數(shù)據(jù)庫中的數(shù)據(jù)加密存儲，不能被輕易篡改，且保持有多份備份，定期更新；系統(tǒng)能防御常見的網(wǎng)絡(luò)攻擊和入侵，如DDOS攻擊、SQL注入攻擊等；系統(tǒng)運行時需要保存運行日志，便于發(fā)現(xiàn)問題后及時處理。合規(guī)性：該系統(tǒng)需要遵守各種法律法規(guī)的要求，不能逾越制度紅線。2.2.2約束開發(fā)過程約束：要求本軟件系統(tǒng)開發(fā)方要組建一支專業(yè)的開發(fā)團隊，在客戶現(xiàn)場進行開發(fā)。運行環(huán)境及技術(shù)約束：為節(jié)省軟件運行、維護的成本，要求未來軟件運行環(huán)境盡量采用開源軟件。交付及部署約束：要求必須在三個月內(nèi)完成開發(fā)。部署時要利用客戶已有的硬件資源，包括web服務(wù)器和數(shù)據(jù)庫服務(wù)器。2.3術(shù)語表讀者可能不熟悉用例描述或其他項目文檔，術(shù)語表用于定義該問題域的術(shù)語。通常，這個表格可以用作非正式的數(shù)據(jù)字典，捕獲數(shù)據(jù)定義，以便用例描述和其他項目文檔可以關(guān)注系統(tǒng)必須處理的信息。術(shù)語定義顧客在本系統(tǒng)中注冊、登錄，并且可能在本系統(tǒng)購買商品的對象。商家網(wǎng)上銷售商品的對象，可以上架下架商品，可以調(diào)整商品價格，可以查看訂單信息。賬號用戶登錄本系統(tǒng)的唯一標識，在本系統(tǒng)中用手機號或郵箱號作為注冊、登錄賬號。商品商家上傳到平臺網(wǎng)店的實物信息或者虛擬貨物。商品信息對商品的詳細說明，包括商品的價格和折扣、商品的規(guī)格、商品適用范圍或者使用方法等詳細信息。購物車用來給顧客存儲商品，顧客可以通過對購物車的操作來滿足自己對商品的管理需求。在購物車中，顧客可以修改商品數(shù)量、刪除商品等。原金額購買的商品原價格的總金額，沒有減去優(yōu)惠、折扣的金額加上郵費。實付金額購買的商品經(jīng)過優(yōu)惠價、折扣的處理后得到的金額，加上郵費（有可能免郵郵費）。支付系統(tǒng)現(xiàn)行網(wǎng)絡(luò)上擁有金融牌照且有合作關(guān)系的網(wǎng)絡(luò)支付系統(tǒng)。商品評價指的是顧客收到商品之后，通過使用對比商品之后，對自己主觀感受的表達，同時評價的內(nèi)容有助于幫助其他顧客更好了解商品。3面向?qū)ο蠓治瞿Ｐ徒ㄗh增加狀態(tài)圖，使主要對象的狀態(tài)變化過程更清晰。例如：訂單狀態(tài)圖。建議增加狀態(tài)圖，使主要對象的狀態(tài)變化過程更清晰。例如：訂單狀態(tài)圖。3.1業(yè)務(wù)建模建議給出業(yè)務(wù)模型和詳細的業(yè)務(wù)說明，包括業(yè)務(wù)內(nèi)容和業(yè)務(wù)流程，可利用活動圖表達業(yè)務(wù)模型。建議給出業(yè)務(wù)模型和詳細的業(yè)務(wù)說明，包括業(yè)務(wù)內(nèi)容和業(yè)務(wù)流程，可利用活動圖表達業(yè)務(wù)模型。3.1.1上下文描述“京北”網(wǎng)上購物商城系統(tǒng)的店鋪售賣商品和用戶購買商品2條服務(wù)主線展開所涉及到的類的上下文：1.店鋪售賣商品：商城里有店鋪，店鋪里有商家賣的各種商品，店鋪有自己已成交的相關(guān)訂單記錄。2.用戶購買商品：商城里有注冊的用戶，顧客有一個屬于自己的購物車，購物車里有顧客考慮購買的商品。顧客有自己已提交的相關(guān)訂單記錄，訂單記錄里有用戶購買的商品。用戶有自己發(fā)起的供交流的消息隊列。商城里有話題，各話題下有用戶關(guān)于購買體驗的帖子，帖子下有評論。3.1.2識別類從3.1.1上下文中，識別出可能用作類的名詞或名詞短語，下面列表展示篩選出的類：名稱解釋商城一個網(wǎng)上購物平臺。店鋪供應(yīng)商品或服務(wù)的虛擬場所。商品被銷售的產(chǎn)品或服務(wù)。訂單記錄買方需求的交易記錄。用戶使用該系統(tǒng)購物的人。購物車虛擬的存放商品的容器。消息記錄用戶交流內(nèi)容的地方。話題用戶在平臺上交流討論的主題。帖子用戶在平臺上發(fā)布的一篇文章。評論對某篇帖子表達的意見。3.1.3類間關(guān)系的確定通過對系統(tǒng)進行分析得各類之間關(guān)系有：商城有多家店鋪，是一對多的聚合關(guān)系；店鋪可以有一個或多個商品，是一對多的聚合關(guān)系；店鋪接受零個或多個訂單，是一對多的關(guān)聯(lián)關(guān)系。商城有零個或多個用戶，是一對多的聚合關(guān)系；一個用戶確定唯一購物車，是一對一的關(guān)聯(lián)關(guān)系；購物車可以有零個或多個商品，是一對多的聚合關(guān)系。用戶下可以有零個或多個訂單，是一對多的關(guān)聯(lián)關(guān)系；一個訂單可以僅購買一個商品，也可以同時購買多個商品，是一對多的聚合關(guān)系。用戶可以發(fā)起零個或多個消息隊列，是一對多的關(guān)聯(lián)關(guān)系。商城有零個或多個話題，是一對多的聚合關(guān)系；話題下發(fā)布零個或多個帖子，是一對多的聚合關(guān)系；帖子下發(fā)布零個或多個評論，是一對多的組合關(guān)系。3.1.4類圖對類的成員和屬性應(yīng)更加明確、細化。對類的成員和屬性應(yīng)更加明確、細化。類圖以反映類的結(jié)構(gòu)(屬性、操作)以及類之間的關(guān)系為主要目的，描述了軟件系統(tǒng)的結(jié)構(gòu)，是一種靜態(tài)建模方法。下圖是從項目的業(yè)務(wù)功能抽象出的“京北”網(wǎng)上購物商城系統(tǒng)的類圖。圖圖3-1京北網(wǎng)上購物系統(tǒng)的類圖3.2分析層——職責確定及分配UML將職責定義為分類器的契約或義務(wù)—由元素（如類或子系統(tǒng)）提供的knowing或doing的服務(wù)或服務(wù)組。關(guān)于軟件對象和大型組件的設(shè)計，一種流行的思考方式是從職責、角色和協(xié)作的角度來考慮，也就是職責驅(qū)動設(shè)計RDD。在RDD中，職責與對象在其角色方面的的義務(wù)或行為相關(guān)。將職責分配給對象的基本原則是：將職責分配給擁有完成該職責所需信息的類。所以我們可以先確定職責，再由職責驅(qū)動確定完成該職責所需的概念類，是對從業(yè)務(wù)模型篩選出的類的一個驗證。CRC代表Class-Responsibility-Collaborator。CRC卡每個類一個，顯示其職責以及它必須與哪些其他類協(xié)作才能履行每個職責。下面就用各CRC卡片展示在“京北”網(wǎng)上購物商城系統(tǒng)中的職責確定及其分配給各類的情況。類名：商城協(xié)作者：用戶店鋪話題職責：注冊登錄類名：用戶協(xié)作者：訂單商品店鋪職責：個人信息管理廣告發(fā)布公告發(fā)布消費者保護類名：話題協(xié)作者：商城用戶帖子評論商品店鋪職責：話題廣場管理類名：消息協(xié)作者：用戶店鋪職責：交互管理類名：商品協(xié)作者：店鋪用戶職責：搜索商品商品管理類名：購物車協(xié)作者：用戶商品職責：購物車管理類名：訂單協(xié)作者：用戶店鋪商品職責：提交訂單優(yōu)惠卡辦理類名：店鋪協(xié)作者：訂單商品用戶職責：評價倉庫管理銷售管理訂單管理售后處理店鋪信息管理3.3分析層——關(guān)鍵用例實現(xiàn)用例實現(xiàn)描述某個用例基于協(xié)作對象如何在設(shè)計模型中實現(xiàn)。用例實現(xiàn)是UP術(shù)語，用以提示我們在表示該段文字可刪除。為用例的需求和滿足需求的對象之間的聯(lián)系。該段文字可刪除。分析類代表了“系統(tǒng)中具有責任和行為的事物”的早期概念模型。分析類主要處理功能需求，它們從業(yè)務(wù)模型中獲取建模對象。一個系統(tǒng)有三個方面可能會發(fā)生變化：1.系統(tǒng)與其參與者之間的邊界；2.系統(tǒng)的使用信息；3.系統(tǒng)的控制邏輯。為了隔離系統(tǒng)中將發(fā)生變化的部分，不同類型的分析類被標識為一組“固定”的職責：邊界類—界面和系統(tǒng)外事物之間的中介；實體類—系統(tǒng)的關(guān)鍵抽象；控制類—用例行為協(xié)調(diào)器。實體類需要從業(yè)務(wù)模型中篩選出的分析類實現(xiàn)全覆蓋，控制類不僅決定了參與用例實現(xiàn)的實體類，還決定了實體類之間的關(guān)系，是對從業(yè)務(wù)模型篩選出的類及其之間關(guān)系的驗證。3.3.1提交訂單用例實現(xiàn)1分析類挖掘邊界類：在提交訂單用例中，只有顧客會與系統(tǒng)發(fā)生交互，在分析模型的構(gòu)造中，其是獨立于設(shè)計模型和最后實現(xiàn)的。故而，在此使用提交訂單頁面類來抽象顧客與系統(tǒng)交互的圖形界面或者瀏覽器頁面?？刂祁悾捍砹艘粋€特定用例的控制器，一般來說，在分析模型階段，由這個控制類實現(xiàn)與它綁定的用例所有的業(yè)務(wù)邏輯控制，如果業(yè)務(wù)邏輯過于復(fù)雜，在構(gòu)建分析模型的后期或者構(gòu)建設(shè)計模型的前期可以將其分化為多個控制類。在此用例中，提交訂單類就被賦予控制類的職責。實體類：代表了系統(tǒng)中各個模塊之間流動數(shù)據(jù)信息的抽象。每一個實體類的實例都代表和抽象了一個實物的存在。根據(jù)生活常識，不難得出，顧客在提交訂單時肯定要接觸的實體有：商品、購物車、訂單和店鋪。所以，根據(jù)這些實體，在系統(tǒng)中分別設(shè)計了其相對應(yīng)的實體類來代表系統(tǒng)中關(guān)于這些實體信息的抽象。分析類類名解釋邊界類提交訂單頁面顧客在該頁面發(fā)起提交訂單請求?？刂祁愄峤挥唵斡稍摽刂祁愞D(zhuǎn)去執(zhí)行相應(yīng)的提交訂單操作。實體類商品被銷售的產(chǎn)品或服務(wù)。購物車虛擬的存放商品的容器。訂單記錄買方需求的交易記錄。店鋪供應(yīng)商品或服務(wù)的虛擬場所。2分析類間關(guān)系確定可分析得各分析類之間關(guān)系有：顧客使用的提交訂單頁面只有一個，而控制類也只需一個，如果需要考慮并發(fā)控制，那么只在控制類中加以實現(xiàn)即可，所以提交訂單頁面邊界類和提交訂單控制類，是一對一的關(guān)聯(lián)關(guān)系。同一個控制類可能要同時處理同一個用戶的不同商品、不同用戶的購物車和訂單以及將訂單推送給不同的店鋪，所以提交訂單控制類與商品、購物車、訂單及店鋪實體類，是一對多的關(guān)聯(lián)關(guān)系。購物車可以有零個或多個商品，是一對多的聚合關(guān)系；一個訂單可以僅購買一個商品，也可以同時購買多個商品，是一對多的聚合關(guān)系；店鋪可以有一個或多個商品，是一對多的聚合關(guān)系；店鋪接受零個或多個訂單，是一對多的關(guān)聯(lián)關(guān)系。3結(jié)構(gòu)類圖以反映類的結(jié)構(gòu)以及類之間的關(guān)系為主要目的，下面就用分析類圖展示對該用例中各分析類間結(jié)構(gòu)的分析。圖圖3-2提交訂單用例實現(xiàn)分析類圖4交互我們可以分析出整個提交訂單過程的業(yè)務(wù)流程為：（1）顧客由提交訂單頁面邊界類通知提交訂單控制類獲取所有商品信息，提交訂單控制類控制商品實體類從數(shù)據(jù)庫中獲取這些信息，將這些信息交付給提交訂單頁面邊界類顯示給顧客。（2）顧客選中一件商品后，由提交訂單頁面邊界類通知提交訂單控制類獲取這件商品的詳細信息，提交訂單控制類控制商品實體類從數(shù)據(jù)庫中獲取這件商品的詳細信息，將其交付給提交訂單頁面邊界類顯示給顧客。（3）顧客由提交訂單頁面邊界類通知提交訂單控制類添加欲購買的商品信息到購物車，提交訂單控制類控制購物車實體類在數(shù)據(jù)庫中增加這些商品的信息。（4）顧客由提交訂單頁面邊界類通知提交訂單控制類提交訂單，提交訂單控制類控制提交訂單頁面邊界類向顧客收集訂單信息，提交訂單控制類控制訂單實體類在數(shù)據(jù)庫中增加收集的訂單信息。（5）提交訂單控制類控制店鋪實體類在數(shù)據(jù)庫中增加收集的訂單信息，將這些信息交付給提交訂單頁面邊界類顯示給商家。系統(tǒng)順序圖主要反映了系統(tǒng)中各個類，模塊或者角色之間，交互方法的先后調(diào)用次序，下面就用系統(tǒng)順序圖展示對該用例中各分析類間交互的分析。圖圖3-3提交訂單的順序圖5操作說明操作CO1：獲取所有商品信息操作：獲取所有商品信息（）交叉引用：用例：提交訂單前置條件：顧客成功登入了該系統(tǒng)，進入提交訂單頁面。后置條件：顧客頁面顯示所有商品信息。操作CO2：獲取意向商品信息操作：獲取意向商品信息（商品：商品）交叉引用：用例：提交訂單前置條件：顧客成功登入了該系統(tǒng)，進入提交訂單頁面。后置條件：顧客頁面顯示意向商品信息。操作CO3：加入購物車操作：加入購物車（商品：商品）交叉引用：用例：提交訂單前置條件：顧客成功登入了該系統(tǒng)，進入提交訂單頁面。后置條件：購物車數(shù)據(jù)庫表中增加了選中的商品信息。操作CO4：提交訂單操作：提交訂單（訂單：訂單）交叉引用：用例：提交訂單前置條件：顧客成功登入了該系統(tǒng)，進入提交訂單頁面。后置條件：基于顧客提交的訂單信息，更新了商家的顯示頁面。3.3.2售后處理用例實現(xiàn)1分析類挖掘邊界類：在售后處理用例中，顧客、商家都會與系統(tǒng)發(fā)生交互，在分析模型的構(gòu)造中，其是獨立于設(shè)計模型和最后實現(xiàn)的。故而，在此使用售后處理頁面類來抽象用戶與系統(tǒng)交互的圖形界面或者瀏覽器頁面?？刂祁悾捍砹艘粋€特定用例的控制器，一般來說，在分析模型階段，由這個控制類實現(xiàn)與它綁定的用例所有的業(yè)務(wù)邏輯控制，如果業(yè)務(wù)邏輯過于復(fù)雜，在構(gòu)建分析模型的后期或者構(gòu)建設(shè)計模型的前期可以將其分化為多個控制類。在此用例中，售后處理類就被賦予控制類的職責。實體類：代表了系統(tǒng)中各個模塊之間流動數(shù)據(jù)信息的抽象。每一個實體類的實例都代表和抽象了一個實物的存在。根據(jù)生活常識，不難得出，用戶在售后處理時肯定要接觸的實體有：訂單、商品、店鋪、用戶和消息。所以，根據(jù)這些實體，在系統(tǒng)中分別設(shè)計了其相對應(yīng)的實體類來代表系統(tǒng)中關(guān)于這些實體信息的抽象。分析類類名解釋邊界類售后處理頁面用戶在該頁面發(fā)起售后處理請求。控制類售后處理由該控制類轉(zhuǎn)去執(zhí)行相應(yīng)的售后處理操作。實體類訂單記錄買方需求的交易記錄。商品被銷售的產(chǎn)品或服務(wù)。店鋪供應(yīng)商品或服務(wù)的虛擬場所。用戶使用該系統(tǒng)購物的人。消息記錄用戶交流內(nèi)容的地方。2分析類間關(guān)系確定可分析得各分析類之間關(guān)系有：用戶使用的售后處理頁面只有一個，而控制類也只需一個，如果需要考慮并發(fā)控制，那么只在控制類中加以實現(xiàn)即可，所以售后處理頁面邊界類和售后處理控制類，是一對一的關(guān)聯(lián)關(guān)系。同一個控制類可能要同時處理同一個用戶的不同商品、不同用戶的訂單以及對應(yīng)的不同的店鋪，所以售后處理控制類與訂單、商品及店鋪實體類，是一對多的關(guān)聯(lián)關(guān)系。店鋪可以有一個或多個商品，是一對多的聚合關(guān)系；店鋪接受零個或多個訂單，是一對多的關(guān)聯(lián)關(guān)系；一個訂單可以僅購買一個商品，也可以同時購買多個商品，是一對多的聚合關(guān)系；用戶下可以有零個或多個訂單，是一對多的關(guān)聯(lián)關(guān)系；用戶可以發(fā)起零個或多個消息隊列，是一對多的關(guān)聯(lián)關(guān)系。3結(jié)構(gòu)類圖以反映類的結(jié)構(gòu)以及類之間的關(guān)系為主要目的，下面就用分析類圖展示對該用例中各分析類間結(jié)構(gòu)的分析。圖圖3-4售后處理用例分析類圖4交互整個售后處理過程的業(yè)務(wù)流程為：（1）顧客由售后處理頁面邊界類通知售后處理控制類退貨處理，售后處理控制類控制商品實體類從數(shù)據(jù)庫中獲取商品狀態(tài)信息。（2）若商品狀態(tài)為“未發(fā)貨”，售后處理控制類控制訂單實體類在數(shù)據(jù)庫中修改訂單信息，將其交付給售后處理頁面邊界類顯示給顧客，售后處理控制類控制商品實體類在數(shù)據(jù)庫中修改商品狀態(tài)信息、控制店鋪實體類在數(shù)據(jù)庫中修改店鋪接受的訂單信息，將其交付給售后處理頁面邊界類顯示給商家。（3）若商品狀態(tài)為“已發(fā)貨”，售后處理控制類控制售后處理頁面邊界類向顧客收集退貨相關(guān)信息，售后處理控制類控制訂單實體類在數(shù)據(jù)庫中增加收集的退貨相關(guān)信息，將這些信息交付給售后處理頁面邊界類顯示給商家。顧客由售后處理頁面邊界類通知售后處理控制類與商家發(fā)送消息進行協(xié)商，售后處理控制類控制店鋪實體類和用戶實體類從數(shù)據(jù)庫中獲取創(chuàng)建消息隊列需要的信息、控制消息實體類在數(shù)據(jù)庫中增加新創(chuàng)建的消息隊列信息，將這些信息交付給售后處理頁面邊界類顯示給顧客和商家。商家同意退貨后，由售后處理頁面邊界類通知售后處理控制類同意退貨處理，售后處理控制類控制訂單實體類在數(shù)據(jù)庫中修改訂單信息，將其交付給售后處理頁面邊界類顯示給顧客，售后處理控制類控制商品實體類在數(shù)據(jù)庫中修改商品狀態(tài)信息、控制店鋪實體類在數(shù)據(jù)庫中修改店鋪接受的訂單信息，將其交付給售后處理頁面邊界類顯示給商家。系統(tǒng)順序圖主要反映了系統(tǒng)中各個類，模塊或者角色之間，交互方法的先后調(diào)用次序，下面就用系統(tǒng)順序圖展示對該用例中各分析類間交互的分析。圖3-5圖3-5售后處理順序圖5操作說明操作CO5：獲取商品狀態(tài)信息操作：獲取商品狀態(tài)信息（商品ID：Integer）交叉引用：用例：售后處理前置條件：顧客成功登入了該系統(tǒng)，進入售后處理頁面。后置條件：顧客頁面顯示商品狀態(tài)信息。操作CO6：修改訂單信息操作：修改訂單信息（訂單：訂單）交叉引用：用例：售后處理前置條件：顧客成功登入了該系統(tǒng)，進入售后處理頁面。后置條件：基于顧客提交的退貨相關(guān)信息，更新了顧客的顯示頁面。操作CO7：修改商品狀態(tài)信息操作：修改商品狀態(tài)信息（商品：商品）交叉引用：用例：售后處理前置條件：顧客成功登入了該系統(tǒng)，進入售后處理頁面。后置條件：商品數(shù)據(jù)庫表中的該商品狀態(tài)信息被更新。操作CO8：修改店鋪接受的訂單信息操作：修改店鋪接受的訂單信息（訂單：訂單）交叉引用：用例：售后處理前置條件：顧客成功登入了該系統(tǒng)，進入售后處理頁面。后置條件：基于顧客提交的退貨相關(guān)信息，更新了商家的顯示頁面。操作CO10：增加收集的退貨相關(guān)信息操作：增加收集的退貨相關(guān)信息（訂單：訂單）交叉引用：用例：售后處理前置條件：顧客成功登入了該系統(tǒng)，進入售后處理頁面。后置條件：基于顧客提交的退貨相關(guān)信息，更新了商家的顯示頁面。操作CO11：與商家發(fā)送消息操作：與商家發(fā)送消息（消息：消息）交叉引用：用例：售后處理前置條件：顧客成功登入了該系統(tǒng)，進入售后處理頁面。后置條件：消息數(shù)據(jù)庫表中增加了新創(chuàng)建的消息隊列信息，更新了顧客和商家的顯示頁面。3.3.3話題廣場管理用例實現(xiàn)1分析類挖掘邊界類：在話題廣場管理用例中，只有用戶會與系統(tǒng)發(fā)生交互，在分析模型的構(gòu)造中，其是獨立于設(shè)計模型和最后實現(xiàn)的。故而，在此使用話題廣場管理頁面類來抽象用戶與系統(tǒng)交互的圖形界面或者瀏覽器頁面?？刂祁悾捍砹艘粋€特定用例的控制器，一般來說，在分析模型階段，由這個控制類實現(xiàn)與它綁定的用例所有的業(yè)務(wù)邏輯控制，如果業(yè)務(wù)邏輯過于復(fù)雜，在構(gòu)建分析模型的后期或者構(gòu)建設(shè)計模型的前期可以將其分化為多個控制類。在此用例中，話題廣場管理類就被賦予控制類的職責。實體類：代表了系統(tǒng)中各個模塊之間流動數(shù)據(jù)信息的抽象。每一個實體類的實例都代表和抽象了一個實物的存在。根據(jù)生活常識，不難得出，用戶在話題廣場管理時肯定要接觸的實體有：話題、帖子和評論。所以，根據(jù)這些實體，在系統(tǒng)中分別設(shè)計了其相對應(yīng)的實體類來代表系統(tǒng)中關(guān)于這些實體信息的抽象。分析類類名解釋邊界類話題廣場管理頁面用戶在該頁面發(fā)起話題廣場管理請求。控制類話題廣場管理由該控制類轉(zhuǎn)去執(zhí)行相應(yīng)的話題廣場管理操作。實體類話題用戶在平臺上交流討論的主題。帖子用戶在平臺上發(fā)布的一篇文章。評論對某篇帖子表達的意見。2分析類間關(guān)系確定可分析得各分析類之間關(guān)系有：用戶使用的話題廣場管理頁面只有一個，而控制類也只需一個，如果需要考慮并發(fā)控制，那么只在控制類中加以實現(xiàn)即可，所以話題廣場管理頁面邊界類和話題廣場管理控制類，是一對一的關(guān)聯(lián)關(guān)系。同一個控制類可能要同時處理不同用戶的話題、評論及帖子，所以話題廣場管理控制類與話題、評論及帖子實體類，是一對多的關(guān)聯(lián)關(guān)系。話題下發(fā)布零個或多個帖子，是一對多的聚合關(guān)系；帖子下發(fā)布零個或多個評論，是一對多的組合關(guān)系。3類的結(jié)構(gòu)類圖以反映類的結(jié)構(gòu)以及類之間的關(guān)系為主要目的，下面就用分析類圖展示對該用例中各分析類間結(jié)構(gòu)的分析。圖圖3-6話題廣場管理分析類圖4交互我們可以分析出整個話題廣場管理過程的業(yè)務(wù)流程為：（1）用戶由話題廣場管理頁面邊界類通知話題廣場管理控制類獲取所有話題信息，話題廣場管理控制類控制話題實體類從數(shù)據(jù)庫中獲取所有話題信息，將這些信息交付給話題廣場管理頁面邊界類顯示給用戶。（2）用戶選中一個話題后，由話題廣場管理頁面邊界類通知話題廣場管理控制類獲取這個話題的詳細信息，話題廣場管理控制類控制帖子和評論實體類從數(shù)據(jù)庫中獲取這個話題的所有帖子及其評論信息，將其交付給話題廣場管理頁面邊界類顯示給用戶。（3）用戶由話題廣場管理頁面邊界類通知話題廣場管理控制類發(fā)布帖子，話題廣場管理控制類控制話題廣場管理頁面邊界類向用戶收集帖子信息，話題廣場管理控制類控制帖子實體類在數(shù)據(jù)庫中增加收集的帖子信息，將這些信息交付給話題廣場管理頁面邊界類顯示給用戶。系統(tǒng)順序圖主要反映了系統(tǒng)中各個類，模塊或者角色之間，交互方法的先后調(diào)用次序，下面就用系統(tǒng)順序圖展示對該用例中各分析類間交互的分析。圖圖3-7話題廣場管理順序圖5操作說明操作CO12：獲取所有話題信息操作：獲取所有話題信息（）交叉引用：用例：話題廣場管理前置條件：用戶成功登入了該系統(tǒng)，進入話題廣場管理頁面。后置條件：用戶頁面顯示所有話題信息。操作CO13：獲取選中話題信息操作：獲取選中話題信息（話題：話題）交叉引用：用例：話題廣場管理前置條件：用戶成功登入了該系統(tǒng)，進入話題廣場管理頁面。后置條件：用戶頁面顯示選中話題信息。操作CO14：發(fā)布帖子操作：發(fā)布帖子（帖子：帖子）交叉引用：用例：話題廣場管理前置條件：用戶成功登入了該系統(tǒng)，進入話題廣場管理頁面。后置條件：基于用戶提交的帖子信息，更新了用戶的顯示頁面。4面向?qū)ο笤O(shè)計模型完整的設(shè)計文檔應(yīng)包括部署設(shè)計、用戶界面的設(shè)計、數(shù)據(jù)庫設(shè)計等。該文檔作為一個案例，讀者可參看系統(tǒng)分析、設(shè)計主要達到什么目的；需求分析和設(shè)計方案如何表達、描述。一個實際系統(tǒng)的需求分析和設(shè)計文檔比該案例文檔要更加細致、全面。該文檔案例的目的是使讀者了解需求分析和設(shè)計要完成哪些工作、需求分析和設(shè)計文檔怎么寫。完整的設(shè)計文檔應(yīng)包括部署設(shè)計、用戶界面的設(shè)計、數(shù)據(jù)庫設(shè)計等。該文檔作為一個案例，讀者可參看系統(tǒng)分析、設(shè)計主要達到什么目的；需求分析和設(shè)計方案如何表達、描述。一個實際系統(tǒng)的需求分析和設(shè)計文檔比該案例文檔要更加細致、全面。該文檔案例的目的是使讀者了解需求分析和設(shè)計要完成哪些工作、需求分析和設(shè)計文檔怎么寫。設(shè)計階段的任務(wù)是精化方案并開發(fā)一個明確描述方案的可視化模型，保障設(shè)計模型最終能平滑地過渡到該段文字可刪除程序代碼。設(shè)計活動回答“該怎么做”的問題，工作的重點是適應(yīng)特定的實施環(huán)境和部署環(huán)境。設(shè)計的核心是規(guī)劃方案的構(gòu)造，在揭示實施細節(jié)的基礎(chǔ)上得到方案的詳細對象模型。

該段文字可刪除4.1架構(gòu)設(shè)計架構(gòu)是一組重要決策，其中涉及軟件系統(tǒng)的組織，對結(jié)構(gòu)元素及其組成系統(tǒng)所籍接口的選擇，這些元素特定于其相互協(xié)作的行為，這些結(jié)構(gòu)和行為元素到規(guī)模更大的子系統(tǒng)的組成，以及指導(dǎo)該組織結(jié)構(gòu)（這些元素及其接口、協(xié)作和組成）的架構(gòu)風格。層是對類、包或子系統(tǒng)的甚為粗粒度的分組，具有對系統(tǒng)主要方面加以內(nèi)聚的職責。同時，層按照“較高”層可以調(diào)用“較低”層的服務(wù)，而反之則不然的方式組織?？偟膩碚f，使用層可以做到關(guān)系分離、高級服務(wù)與低級服務(wù)分離、特定于應(yīng)用的服務(wù)與一般性服務(wù)分離，也即是層可以減少耦合和依賴性、增強內(nèi)聚性、提高潛在的復(fù)用性并且使概念更加清晰?；谝陨戏治?，對于“京北”網(wǎng)上購物商城系統(tǒng)的邏輯架構(gòu)我們選用層次架構(gòu)。分層架構(gòu)決定了層與層之間的組織，同時我們需要對每層確定使用的框架，以此來決定每層的對象及其之間的組織，確定對象之間發(fā)送消息即交互的機制機理。這里我們將整個系統(tǒng)分為三層，分別是表現(xiàn)層、業(yè)務(wù)層及持久化層。前端采用Layui框架，后端采用ssm框架，具體為前端表現(xiàn)層采用Layui框架、后端表現(xiàn)層采用SpringMVC框架、業(yè)務(wù)層采用Spring框架、持久化層采用Mybatis框架。前、后端使用ajax+json進行交互，即前端表現(xiàn)層通過ajax將相應(yīng)的方法傳遞到后端表現(xiàn)層，后端表現(xiàn)層獲取前端表現(xiàn)層請求并將數(shù)據(jù)反饋給前端表現(xiàn)層，處理后的數(shù)據(jù)顯示在前端頁面上反饋給用戶。表現(xiàn)層：負責處理用戶界面和用戶輸入輸出的邏輯，將用戶的請求發(fā)送到下一層。圖圖4-1京北網(wǎng)上購物系統(tǒng)架構(gòu)的表現(xiàn)層業(yè)務(wù)層：負責處理系統(tǒng)主要的功能和業(yè)務(wù)邏輯。層與層之間的依賴是向下的，在分層設(shè)計時，遵循了面向接口設(shè)計的思想，在不改變接口定義的情況下，本系統(tǒng)有良好的可替換性及可復(fù)用性。主要邏輯通過service接口規(guī)定，有較低的耦合性，系統(tǒng)進行二次迭代時可通過替換增強功能，滿足開閉原則。圖圖4-2京北網(wǎng)上購物系統(tǒng)架構(gòu)的業(yè)務(wù)層持久化層：負責對數(shù)據(jù)的訪問，本系統(tǒng)是對數(shù)據(jù)庫的訪問。系統(tǒng)采用OR映射的方式，將實體對象映射為表，從而達到對表的操作。通過dao接口規(guī)定邏輯，降低耦合性。圖圖4-3京北網(wǎng)上購物系統(tǒng)架構(gòu)的持久化層總體邏輯架構(gòu)：圖圖4-4京北網(wǎng)上購物系統(tǒng)總體架構(gòu)圖4.2用例設(shè)計基于以上分層架構(gòu)和每層所使用的框架，將面向?qū)ο蠓治鲭A段關(guān)鍵用例實現(xiàn)里的邊界類細化，但更多的是控制類的按層分解，實體類及其關(guān)系變化也不會太大。4.2.1提交訂單用例設(shè)計1結(jié)構(gòu)因為在分析階段職責確定及分配時我們將提交訂單職責分配給了訂單類，加之上述確定的分層架構(gòu)及每層使用的框架，所以在此可將分析階段的一個提交訂單控制類按層分解為訂單Controller、訂單Service、訂單Dao。類圖以反映類的結(jié)構(gòu)以及類之間的關(guān)系為主要目的，下面就用設(shè)計類圖展示對該用例中各類間結(jié)構(gòu)的分析。圖圖4-5提交訂單設(shè)計類圖2交互這里以提交訂單（訂單：訂單）操作為例描述各類之間的交互：顧客填寫完訂單信息后，點擊“提交訂單”按鈕時，系統(tǒng)通過訂單Controller中的提交訂單（訂單：訂單）方法將顧客所填寫的訂單信息傳遞給訂單Service接口，進而調(diào)用訂單ServiceImpl中的提交訂單（訂單：訂單）方法，訂單ServiceImpl具體實現(xiàn)訂單Service接口；然后訂單ServiceImpl又將信息傳遞給訂單Dao接口，調(diào)用訂單DaoImpl中的提交訂單（訂單：訂單）方法，訂單DaoImpl具體實現(xiàn)訂單Dao接口，系統(tǒng)通過訂單DaoImpl這個類與數(shù)據(jù)庫進行交互，將顧客填寫的訂單信息增加到數(shù)據(jù)庫中。系統(tǒng)順序圖主要反映了系統(tǒng)中各個類，模塊或者角色之間，交互方法的先后調(diào)用次序，下面就用系統(tǒng)順序圖展示對該用例中各類間交互的分析。圖圖4-6提交訂單模塊的順序圖4.2.2售后處理用例設(shè)計1結(jié)構(gòu)因為在分析階段職責確定及分配時我們將售后處理職責分配給了店鋪類，加之上述確定的分層架構(gòu)及每層使用的框架，所以在此可將分析階段的一個售后處理控制類按層分解為店鋪Controller、店鋪Service、店鋪Dao。類圖以反映類的結(jié)構(gòu)以及類之間的關(guān)系為主要目的，下面就用設(shè)計類圖展示對該用例中各類間結(jié)構(gòu)的分析。圖圖4-7售后處理模塊的順序圖2交互這里以增加收集的退貨相關(guān)信息（訂單：訂單）操作為例描述各類之間的交互：顧客點擊“退貨處理”按鈕時，系統(tǒng)通過店鋪Controller中的增加收集的退貨相關(guān)信息（訂單：訂單）方法將顧客所填寫的退貨相關(guān)信息傳遞給店鋪Service接口，進而調(diào)用店鋪ServiceImpl中的增加收集的退貨相關(guān)信息（訂單：訂單）方法，店鋪ServiceImpl具體實現(xiàn)店鋪Service接口；然后店鋪ServiceImpl又將信息傳遞給店鋪Dao接口，調(diào)用店鋪DaoImpl中的增加收集的退貨相關(guān)信息（訂單：訂單）方法，店鋪DaoImpl具體實現(xiàn)店鋪Dao接口，系統(tǒng)通過店鋪DaoImpl這個類與數(shù)據(jù)庫進行交互，將顧客填寫的退貨相關(guān)信息增加到數(shù)據(jù)庫中。系統(tǒng)順序圖主要反映了系統(tǒng)中各個類，模塊或者角色之間，交互方法的先后調(diào)用次序，下面就用系統(tǒng)順序圖展示對該用例中各類間交互的分析。圖圖4-8售后處理模塊的順序圖4.2.3話題廣場管理用例設(shè)計1結(jié)構(gòu)因為在分析階段職責確定及分配時我們將話題廣場管理職責分配給了話題類，加之上述確定的分層架構(gòu)及每層使用的框架，所以在此可將分析階段的一個話題廣場管理控制類按層分解為話題Controller、話題Service、話題Dao。類圖以反映類的結(jié)構(gòu)以及類之間的關(guān)系為主要目的，下面就用設(shè)計類圖展示對該用例中各類間結(jié)構(gòu)的分析。圖圖4-9話題廣場管理用例實現(xiàn)設(shè)計類圖2交互這里以發(fā)布帖子（帖子：帖子）操作為例描述各類之間的交互：用戶填寫完帖子信息后，點擊“發(fā)布帖子”按鈕時，系統(tǒng)通過話題Controller中的發(fā)布帖子（帖子：帖子）方法將用戶所填寫的帖子信息傳遞給話題Service接口，進而調(diào)用話題ServiceImpl中的發(fā)布帖子（帖子：帖子）方法，話題ServiceImpl具體實現(xiàn)話題Service接口；然后話題ServiceImpl又將信息傳遞給話題Dao接口，調(diào)用話題DaoImpl中的發(fā)布帖子（帖子：帖子）方法，話題DaoImpl具體實現(xiàn)話題Dao接口，系統(tǒng)通過話題DaoImpl這個類與數(shù)據(jù)庫進行交互，將用戶填寫的帖子信息增加到數(shù)據(jù)庫中。系統(tǒng)順序圖主要反映了系統(tǒng)中各個類，模塊或者角色之間，交互方法的先后調(diào)用次序，下面就用系統(tǒng)順序圖展示對該用例中各類間交互的分析。圖圖4-10話題廣場管理用例實現(xiàn)系統(tǒng)順序圖4.3子系統(tǒng)設(shè)計子系統(tǒng)實際上是一種特殊的包，這種包僅具有作為公有元素的接口。這些接口提供了一個封裝層，從而使其他模型元素看不到子系統(tǒng)的內(nèi)部設(shè)計。子系統(tǒng)這一概念用于將它和“普通”包區(qū)分開來：“普通”包是無語義的模型元素容器；而子系統(tǒng)則表示具有與類相似的（行為）特征的包的特定用法。是否從一組協(xié)作分析類中創(chuàng)建子系統(tǒng)，這在很大程度上取決于該協(xié)作是否可由單獨的設(shè)計團隊來獨立開發(fā)。如果協(xié)作與協(xié)作類可完全包含在一個包中，子系統(tǒng)就可提供比簡單包更有效的封裝形式。子系統(tǒng)中的內(nèi)容和協(xié)作被一個或多個接口完全隔離起來，因此子系統(tǒng)的客戶只能依賴于接口。這樣，子系統(tǒng)的設(shè)計人員就完全脫離了外部依賴關(guān)系；雖然設(shè)計人員（或設(shè)計團隊）需要指定接口的實現(xiàn)方式，但他們可以充分自由地更改子系統(tǒng)的內(nèi)部設(shè)計，而不會影響外部依賴關(guān)系。在相當獨立的團隊所開發(fā)的大型系統(tǒng)中，這種程度的隔離和由正式接口所提供的架構(gòu)執(zhí)行一同有力證明了應(yīng)選擇子系統(tǒng)而不應(yīng)選擇簡單包?？傊?，子系統(tǒng)設(shè)計就是把會變化的、功能類似的功能區(qū)內(nèi)聚起來形成一個子系統(tǒng)，將其與系統(tǒng)的穩(wěn)定部分隔離開來，以降低系統(tǒng)的耦合性、增加復(fù)用性。4.4類的設(shè)計前面的設(shè)計是類外部的，現(xiàn)在進行最細的設(shè)計，即類內(nèi)部的設(shè)計——為類增加屬性和方法。圖圖4-11類的詳細設(shè)計圖5精化設(shè)計與模式應(yīng)用5.1創(chuàng)