【文章內(nèi)容簡介】 、支 票或者其他付款方式，一旦定單被輸入，系統(tǒng)向客戶發(fā)送一個確認 消息，并附上定單的細節(jié)，在等待商品送到的時候，客戶可以在任何時候在線查到定單的狀態(tài)。 后端定單處理包含下面所需的步驟：驗證客戶的信任度和付款方式、向倉庫請求所 訂購的商品、打印發(fā)票并且請求倉庫將商品運送給客戶 。 其中主要實現(xiàn)的功能： 功能模塊 功能描述 用戶登錄，注冊 主要是對不同權限的瀏覽者的服務功能的區(qū)分 產(chǎn)品信息的展示 主要展示商城的銷售產(chǎn)品信息 購物車信息的展示 會員購買商品放在購物車中的實現(xiàn) 搜索功能 主要對本站商品信息進 行簡單的搜索！ 用戶信息的管理 主要是管理員對于會員信息的刪除等管理操作 商品信息管理 主要是管理員對于商品信息的添加，刪除，修改。 訂單信息處理 主要是對于會員下完訂單后的訂單操作。 類別信息處理 商品信息類別的添加和修改！ 銷售統(tǒng)計信息 對于整個商品的銷售情況進行統(tǒng)計 建立業(yè)務用例 參與者； 表：參與者 (actor) 參與者 描述 Customer 一般的瀏覽者實體，可以查看網(wǎng)站的大部分信息，但是有些《管理信息系統(tǒng)》課程設計 —— 《 ShoppingMall System 管理信息系統(tǒng)》 7 信息不能夠獲??！ Member 注冊會員的實體，享 受商品的折扣價購買商品！并且有更多的權限！ Adminstractor 統(tǒng)一的網(wǎng)站管理者實體，具有后臺管理商品信息功能！ (use case) (1) 產(chǎn)品信息用例 : 用 例 ： ProductsInformationCase 簡 述 ： 該用例允許用戶查詢選擇 正價商品 ，包括價格及 商品 清單 。 參 與 者 ： Customer 前提條件 ： Customer 點擊一個 商品類型 進入 此類商品 的選購的 Web 頁面，該頁面顯示 每個商品 的價格以及 商品 說明 。用例開始 。 主 流 ： 用戶查詢標準計算機配置，將選中的計算機標準配置加入購物車，用戶可隨時增減購物車內(nèi)商品 ， web 頁面動態(tài)對累積價格進行更新 。 其 他 流 ： 無 后置條件 ： 如果用例成功，將購物車內(nèi) 商品名稱 及數(shù)量存入臨時數(shù)據(jù)庫 。 (2) 會員信息用例 用 例： CustomersInformationCase 簡 述： 該用例是用于 Customer 修改個人信息，管理員修改會員信息 參 與 者： Customer, Administractor 前提條件： Member 要先注冊！管理員進行查看確認！ 主 流： Member 注冊后，會員對于個人信心可以進行查看與修改！ 其 他 流： 若會員沒有注冊，提示會員注冊。 后置條件： 如果用例成功， 會員信息將 存入數(shù)據(jù)庫 。 (3)訂單信息用例 用 例： OrdersInformationCase 簡 述： 該用例允許 Customer 輸入一份購物定單，該定單包括提供運送和發(fā)票地址 等 情況 。 參 與 者： Customer 前提 條件： Customer 點擊一個 某一商品類型 進入 商品選擇 的定單輸入Web 頁面，該 商品名稱說明 及其價格的詳細情況 。 當 Customer 在定單信息已經(jīng)顯示在屏幕上時選擇 確認 （或相似命名的）功能鍵來確定訂購 商品 時，該用例開始 。 《管理信息系統(tǒng)》課程設計 —— 《 ShoppingMall System 管理信息系統(tǒng)》 8 主 流： 系統(tǒng)請求 Customer 輸入購買細節(jié)，包括銷售人員的名字（如果知道的話）、運送信息（客戶的名字和地址）、發(fā)票細節(jié)（如果與運送地址不同的話）、付款方法（信用卡或支票）以及任何其他注釋 。 Customer 選擇 確認下單 （或相似命名的）功能來發(fā)送 定單給制造廠商 。 系統(tǒng)給購買定單賦予一個唯一的定單號碼和一個客戶賬號，系統(tǒng)將定單信息存入數(shù)據(jù)庫 。 系統(tǒng)將定單號和客戶號與所有定單細節(jié)一起 給Customer，作為對接收定單的確認 。 其 他 流： Customer 在提供所有要求錄入的信息之前，激活 Purchase（或相似命名的）功能，系統(tǒng)顯示錯誤信息，它要求提供所漏掉的信息 。 Customer 選擇 Reset（或相似命名的）功能來恢復一個空白的購物表格，系統(tǒng)允許 Customer 重新輸入信息 。 后置條件： 如果用 例成功，購物定單記錄進系統(tǒng)的數(shù)據(jù)庫，否則系統(tǒng)的狀態(tài)不變 。 (4)訂單狀態(tài)處理 用 例： Update Order Status 簡 述： 該用例用于描述定單狀態(tài)（定單交付狀態(tài)，定單確認狀態(tài)，付款狀態(tài)） 。 參 與 者： Administractor 前提條件： Customer 交付定單，查詢定單狀態(tài)， Salesperson修改定單狀態(tài)，該用例開始 。 主 流： Customer 填寫定單訂購商品成功，進入定單交付狀態(tài) 。 Administractor 檢查定單，發(fā)送 給客戶，進入定單確認狀態(tài)。 其 他 流： 若定單不符合要求，則向用戶發(fā)送定購失敗信息。 若銷售人員檢查定單有誤，則向用戶發(fā)送定購失敗信息 。 若用戶付款金額不對，則向用戶發(fā)送付款失敗信息 。 后置條件： 如果用例成功，則將定單所處狀態(tài)存入數(shù)據(jù)庫 。 (5) 帳戶信息用例 : 用 例： AccoutInformationCase 簡 述： 該用例是用于描述用戶賬號信息！ 參 與 者： Member， Administractor 前提 條件： 用戶注冊成功后，開通自己的賬號信息，該賬號信息室用于在本網(wǎng)站購買商品儲蓄包！當會員確認支付后， 該用例開始 。 《管理信息系統(tǒng)》課程設計 —— 《 ShoppingMall System 管理信息系統(tǒng)》 9 主 流： 會員注冊后，可以向賬戶中轉一定的錢款用于購買商品，也可以暫時不轉，購買商品時選擇直接用網(wǎng)銀支付。 其 他 流： 若會員購買上商品時，賬戶余額不足時，系統(tǒng)提示轉入相應的金額。 若賬戶信息有誤時，可以向網(wǎng)站 管理員聯(lián)系，解決問題！ 若不能夠轉賬，可以直接用網(wǎng)銀來支付！ 后置條件： 如果用例成功，則將定單所處狀態(tài)存入數(shù)據(jù)庫 。 ShoppingMall System Author (s): __肖俊毅 __________ Date__202128_________Version: USE CASE NAME: 下新訂單 USE CASE TYPE USE CASE ID: 001 Business Requirements: ? PRIORITY: 高 System Analysis: ? SOURCE: 需求 —— 002 需求用例 —— 003 PRIMARY BUSINESS ACTOR 一般瀏覽者 PRIMARY SYSTEM ACTOR 會員 OTHER PARTICIPATING ACTORS: ? 倉庫（別名 —— 分銷中心）（外部接收者） ? 應付帳 /應收帳（外部服務者） OTHER INTERESTED STAKEHOLDERS: ? 市場部 —— 對銷售活動感興趣，為了計劃新得促銷 ? 采購部 —— 對銷售活動感興趣，為了補充庫存 ? 管理層 —— 對銷售活動感興趣，為了評估公司性能和顧客滿意度 DESCRIPTION: 該用例描述會員通過因特網(wǎng)提交一個產(chǎn)品的訂單。會員選擇他想購買的項目。一旦會員完成了采購，會員的資料信息以及他的賬號被驗 證。一旦驗證產(chǎn)品有庫存，就向倉庫發(fā)出一個發(fā)貨訂單準備發(fā)貨。對于沒有庫存的產(chǎn)品，生成一個退單。一旦完成，會員將得到一份訂單證實。 PRECONDITION: 提交訂單的一方（個人或公司）必須是網(wǎng)站的會員。 會員必須登陸到系統(tǒng)中（提供身份認證）輸入訂單。 TRIGGER: 當會員選擇輸入新訂單時，用例被觸發(fā)。 OF EVENTS: Step 1:會員請求輸入新訂單 Step 2: 系統(tǒng)做出響應，顯示產(chǎn)品目錄 Step 3：會員瀏覽可得到的條目，選擇他想購買的項及數(shù)量。 Step 4：一旦會員完成了選 擇，系統(tǒng)訪問文件，顯示會員的個人信息（發(fā)貨和收費地址） Step 5：會員驗證個人信息（發(fā)貨和收費地址）。如果沒有變化，會Step 6：對于訂單的每個產(chǎn)品，系統(tǒng)驗證產(chǎn)品可用《管理信息系統(tǒng)》課程設計 —— 《 ShoppingMall System 管理信息系統(tǒng)》 10 員響應地響應（繼續(xù)）。 性，決定發(fā)貨日期，決定向會員收取的價格，決定訂單的總價格。如果某項不能馬上得到，推出產(chǎn)品退單，或者還沒有發(fā)貨（對于預定）。如果某項不再可得到，也需要指出。系統(tǒng)然后給會員顯示一個訂單總結供確認。 Step 7：會員驗證訂單。如果沒有變化，會員相應地響應（繼續(xù)）。 Step 8： 系統(tǒng)檢查會員賬號的狀態(tài)。如果滿足 ，系統(tǒng)提示會員選擇期望的支付方式（以后支付還是使用信用卡支付） Step9：會員選擇期望的支付方式 Step 10：系統(tǒng)顯示訂單總結，包括期望的支付方式，供會員確認。 Step 11：會員驗證訂單，如果沒有變化，會員相應地響應（繼續(xù)） Step 12：系統(tǒng)記錄訂單信息（如果需要還包括退單）。 Step 13:調(diào)用抽象用例0001（確定合適的分銷中心并分發(fā)填寫的訂單） Step 14： 一旦訂單被處理，系統(tǒng)生成一個訂單確認，把它顯示給會員，并通過電子郵件發(fā)送給會員。 ALTERNATE COURSES: 替代第 3 步 ：會員輸入查詢條件獲取特定的項目，或者顯示一個縮減的列表以便于瀏覽和購買。 替代第 5 步 ：如果需要修改，會員修改相應的發(fā)貨地址、收費地址或電子郵件，并告訴系統(tǒng)相應地存儲。系統(tǒng)將驗證修改，如果成功，將把新信息存儲到文件中。 替代第 7 步 ：如果訂單要修改，會員可以刪除不再想要的項目，或者修改訂購數(shù)量。一旦會員完成了訂單修改，系統(tǒng)繼續(xù)處理訂單（轉到第 6 步）。如果會員請求繼續(xù)購買，（轉到第 3步）。如果會員需要修改個人信息，轉到第 5步。 替代第 11 步 ：如果要修改訂單，會員可以刪除不再 想要的項目，或者修改訂購數(shù)量。一旦會員完成了訂單修改，系統(tǒng)繼續(xù)處理訂單（轉到第 6 步）。如果會員請求繼續(xù)購買 替代第 12 步： 如果所有的訂購項目都被退單，訂單就步發(fā)送到分銷中心。 CONCLUSION: 當會員收到訂單確認時，該用例結束。 POSTCONDITION: 訂單被記錄下來，如果訂單的產(chǎn)品有貨，將發(fā)貨。對于缺貨的產(chǎn)品，生成一個延遲交貨單。 BUSINESS RULES ? 會員必須擁有一個有效的電子郵件地址用于提交聯(lián)機訂單 ? 只有當產(chǎn)品發(fā)貨時，才向俱樂部會員收費 IMPLEMENTATION CONTRAINTS AND SPECIFICATIONS ? 用例必須對會員 24*7可用 ? 頻率 —— 估計用例每天執(zhí)行 3500 次，應支持最多 50 格并發(fā)會員 ASSUMPTIONS: ? 產(chǎn)品能夠通過分銷中心發(fā)送以履行訂單 ? 將在日報告中通知采購部門延遲交貨單（獨立的用例） 《管理信息系統(tǒng)》課程設計 —— 《 ShoppingMall System 管理信息系統(tǒng)》 11 ? 會員響應促銷或者使用信用卡可能會影響每個訂購項目的價格 ? 會員可以在任何時候取消訂單 OPEN ISSUES: 無 3. 系統(tǒng)中的類 對象類 用戶類 商品類 訂單類 商品類別類 賬戶類 折扣類 留言類 庫存類 控制類 查詢類 添加類 修改類 刪除類 數(shù)據(jù)庫類 數(shù)據(jù)庫類 外部接口類 其他接口類 邏輯設計（ UML面向對象設計） 用例圖： 通過上述的分析，我們可以找出用例 模型，具體的用例圖如下： ShoppingMall [Use Case] S h o p p i n g M a l lS ys t m sS u p M a n a g e r sM a n a g e r sC u st o m e r sM e ssa g e B o a r dM a n a g e r sI n f o r m t i o n C a seI n v e n t r o