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

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

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

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