个性化邮件系统用例设计和实现
??? 本文我們結(jié)合某省郵政局的個性化郵件系統(tǒng)的一些典型用例的實現(xiàn)作一番探討。?
??? 一、 個性化郵件系統(tǒng)需求概述?
??? 個性化郵件系統(tǒng)（以下簡稱Y系統(tǒng)）主要是市郵票公司提供給市民的特種郵票服務(wù)，它能把客戶的個人照片印在特定版面的郵票上，使之具有一種特別的紀念意義。而郵票公司所提供的兩種款式分別是“歲歲平安”和“太陽神鳥”可供客戶不同的喜好選擇。?
??? 經(jīng)過公司的業(yè)務(wù)分析和系統(tǒng)分析人員的流程優(yōu)化后，共同定義了如下的全部頁面流程：?
??? 1 首頁，款式展示和流程說明。?
??? 2 授權(quán)書。?
??? 3 客戶錄入基本信息并上傳身份證.。?
??? 4 客戶下單，輸入所選款式、數(shù)量并上傳相片,系統(tǒng)自動匯總計算訂單金額。?
??? 5 顯示客戶信息和訂單明細信息。?
??? 6 確認訂單。?
??? 7 顯示訂單號和金額。?
??? 8 確認付款。?
??? 9 輸入帳號。?
??? 10 申請成功，提示領(lǐng)取信息。?
??? 總的說來，整個流程就是：?
??? 1 客戶下單?
??? 2 支付?
??? 3 審核?
??? 4 投遞或自取?
??? 從業(yè)務(wù)邏輯上看來，如果我們把提供的款式看成產(chǎn)品，每件款式的單價是確定的，而數(shù)量是需要客戶下達的，只是由于業(yè)務(wù)特點的需求，它的商品“原材料”實際上是由客戶上傳的?！奥槿鸽m小，五臟俱全” ,Y系統(tǒng)（即前文提到的“個性化郵件系統(tǒng)”）規(guī)模不大，但是已經(jīng)涵蓋了企業(yè)客戶、訂單、生產(chǎn)（服務(wù)）、發(fā)貨全部的運營流程。從Y系統(tǒng)的業(yè)務(wù)需求看，它比較類似于購物車的需求實現(xiàn)。從企業(yè)運作流程看，Y系統(tǒng)就是一個迷你版的ERP銷售系統(tǒng)。
??? 二、 重點用例?
??? 按照基于用例的開發(fā)流程，原始業(yè)務(wù)需求一旦確認，我們則進入了確定和提煉用例階段。最終，我們給出了如下的對業(yè)務(wù)起著決定意義的用例。
??? 1. Use Case ID: 創(chuàng)建訂單(Create Order)?
??? 主題 : UC01 創(chuàng)建訂單?
??? 相關(guān)主題 : Create Order?
??? 需求ID : R01
- 目的
使用例參與者能確保創(chuàng)建和提交訂單并能夠添加相關(guān)產(chǎn)品(上傳照片)到訂單行。 - 描述
參與者想通過訂單購買一種或多種產(chǎn)品（服務(wù)）。在受理網(wǎng)站上， 參與者通過類似于購物籃的形式，完成產(chǎn)品的添加和訂單下達, 一旦產(chǎn)品被添加到訂單，訂單將即時更新訂單總金額。 - 前提條件
1) 參與者已經(jīng)登陸到本系統(tǒng)網(wǎng)站，系統(tǒng)首頁已能讓參與者受理個性化郵票業(yè)務(wù)。
2) 參與者必須選擇至少一件產(chǎn)品給訂單，即必須上傳一張照片。 - 參與者
1）客戶
2）管理員 - 基本流程
第1步：當(dāng)參與者決定下達訂單，本用例即開始。
第2步：參與者注冊客戶信息, 系統(tǒng)通過其身份登記和認證。
第3步：參與者創(chuàng)建訂單, 系統(tǒng)返回其訂單創(chuàng)建信息。
第4步：系統(tǒng)處理參與者的創(chuàng)建訂單請求，直到客戶完成該訂單。
a. 參與者選擇一種產(chǎn)品款式(此處可以作為單獨用例UC 08 查看款式目錄)。
b. 參與者鍵入訂購數(shù)量。
c. 參與者添加商品即上傳照片給訂單。
d. 系統(tǒng)更新訂單行資料，包括數(shù)量、款式、商品和總金額。
第5步：參與者確認已完成訂單。
第6步：參與者驗證并確認訂單和客戶明細信息, 系統(tǒng)反饋該參與者的提交的訂單詳情 。
第7步：參與者驗證并確認訂單付款信息, 系統(tǒng)反饋訂單編號和付款總金額。
第8步：參與者確認訂單付款，系統(tǒng)調(diào)用相關(guān)付款接口完成付款流程 (此處可以作為單獨用例UC 09 訂單付款)。
第9步：本用例結(jié)束，當(dāng)系統(tǒng)成功返回給參與者該訂單付款情況，并提示參與者相關(guān)訂單發(fā)貨信息。 - 附加流程
1）如果付款或投遞被延遲進行，則第7步到第9步將被跳過，本用例在訂單被確認和保存時結(jié)束。
2）如果訂單已經(jīng)存在(was previously deferred):
a. 當(dāng)先前下達的訂單被選擇時本用例開始。
b. 第2步則為系統(tǒng)顯示之前創(chuàng)建的訂單。
c.第3步到第9步遵循基本流程的步驟。
3） 如果客戶鍵入了錯誤的付款信息，系統(tǒng)將通知參與者，然后本用例應(yīng)從第7步繼續(xù)。 - 內(nèi)涵/擴展
None - 實施需求
None - 使用頻率
經(jīng)常 - 特別需求
ID
款式
照片
數(shù)量
1 歲歲平安 ? 1 2 太陽神鳥 ? 1 - 問題
無 - 決策點
無 - 未來需求
無 - 修改版本
Date
Author
Description
? ? ? ? ? ? - 用例模型
2. Use Case ID: 審核訂單(Approve Order)?
??? 主題 : UC02 審核訂單?
??? 相關(guān)主題 : Approve Order?
??? 需求ID : R02- 目的
使用例參與者能查看所有訂單并根據(jù)具體情況做出審核決定，如果審核不通過發(fā)出通知給客戶。 - 描述?
參與者審核客戶已經(jīng)付款的訂單。在受理網(wǎng)站上， 參與者通過各種形式將審核結(jié)果通知到客戶。 - ?前提條件
1） 參與者已經(jīng)登陸到本系統(tǒng)網(wǎng)站。
2） 參與者必須選擇一份訂單進行審核動作。 - 參與者
1） 管理員
2） 客戶 - 基本流程
第1步： 當(dāng)參與者“管理員”開始審核已經(jīng)付款的訂單，本用例即開始。
第2步： 參與者“管理員”發(fā)出查詢訂單的請求，系統(tǒng)安裝訂單日期倒排顯示訂單清單。
第3步： 參與者“管理員”按照逐一審核各訂單。
a. 查看訂單基本信息。
b.查看訂單產(chǎn)品照片是否合格。
c.“管理員”發(fā)出審核動作，系統(tǒng)將作出該訂單的審核狀態(tài)提交。
d“管理員”鍵入審核意見，系統(tǒng)將保存該訂單的審核意見。
第4步： 訂單審核完成，本用例結(jié)束。 - 附加流程
1） 第3步, 如果該訂單不能通過審核，“管理員”寫明審核意見，并點擊發(fā)送按鈕，系統(tǒng)將發(fā)送短信息通知相關(guān)參與者“客戶”。用例從第4步繼續(xù)。 - 內(nèi)涵/擴展
無 - 實施需求
無 - 使用頻率
經(jīng)常 - 特別需求
ID
款式
照片
數(shù)量
1 歲歲平安 ? 1 2 太陽神鳥 ? 1 - 問題
無 - 決策點
無 - 未來需求
無 - 修改版本
Date
Author
Description
? ? ? ? ? ? - 用例模型
??? 目前我們已經(jīng)把握了重點用例，現(xiàn)在則要“實現(xiàn)”用例。用例的實現(xiàn)指的是對每個用例所進行的詳細系統(tǒng)過程的說明，在這個過程中，我們以UML的方法給出了類圖設(shè)計、順序圖、狀態(tài)圖，甚至包括UI設(shè)計和E-R設(shè)計等等，目的是為系統(tǒng)進一步的詳細設(shè)計提供概念上的依據(jù)和設(shè)計參照。?
??? 1???? “創(chuàng)建訂單”用例
圖1： Stamp DIY Physical Object Model
??? 圖1中的業(yè)務(wù)關(guān)系類圖，我們有如下描述:?
??? a. 訂單Order和訂單行OrderDetail是組合關(guān)系。訂單Order和OrderDetail構(gòu)成上下級別的一對多關(guān)系，它們擁有著一致的生命周期。?
??? b. 產(chǎn)品目錄Catalog和目錄項Catalogitem也是組合關(guān)系，擁有一致的生命周期。?
??? c. 客戶Customer和Order 形成關(guān)聯(lián)類，二者構(gòu)成強制關(guān)系, 即客戶類Customer不存在的情況下，訂單類Order是不存在的。?
??? d. 客戶Customer從本質(zhì)上是一種角色Role，所以客戶Customer可以視為Role角色的子類，Customer繼承了Role的屬性。?
??? 我們在設(shè)計域類通常會遵循一些基本的設(shè)計準則，如下：?
??? 封裝——封裝是一種設(shè)計準則，規(guī)定了數(shù)據(jù)和程序邏輯包含在一個獨立的單元中。?
??? 導(dǎo)航可見性——是一種設(shè)計準則，指一個對象可以看到另一個對象并與之交互?！?
??? 設(shè)計的任務(wù)之一是說明哪個對象對哪個對象有導(dǎo)航可見性,它可以是單向或雙向的。如圖1，一個Customer對象可以看見一個Order對象，它意味著Customer對象可以知道客戶發(fā)出了哪些訂單。在程序里，Customer類通常會用一個變量或數(shù)組來指向這個客戶的一個或多個Order對象。在設(shè)計類圖中，導(dǎo)航可見性用類之間的箭頭表示，箭頭指向可見的類?！?
??? 耦合——它來自于導(dǎo)航可見性，如圖一，Ｃustomer對Ｏrder是可見性的，則它們是耦合的，同樣，Ｏrder對ＯrderDetail也具導(dǎo)航可見性,它們也是耦合的。?
??? 耦合是對設(shè)計類圖中的類與類之間連接關(guān)系的緊密程度的定性的度量。一種比較容易理解耦合的方法是看設(shè)計了類圖的導(dǎo)航箭頭的個數(shù)，比如Customer對Order是耦合的，Order對OrderDetail是耦合的，這些是正常的設(shè)計。但如果把Customer加入到對OrderDetail的導(dǎo)航可見性則是強耦合的類型，這樣的設(shè)計會降低系統(tǒng)的維護性。?
??? 通常，有經(jīng)驗的分析員會盡量簡化耦合，并減低對新系統(tǒng)設(shè)計的影響。?
??? 聚合與任務(wù)分解——指的是一個類中各種功能的一致性，它是對一個類中目的單元或主題的定性度量。?
??? 我們需要的是高聚合的類設(shè)計， 因為低聚合的類不容易維護，重用度低。在圖1中，我們把客戶，訂單和購物車分解成幾個高聚合的類．為解決低聚合的類通常采用的分成幾個高聚合類的方法是為任務(wù)分解，它是另一個面向?qū)ο笤O(shè)計的準則。
圖2： DB Schema??? 如圖2的數(shù)據(jù)Ｅ－Ｒ設(shè)計，我們可以得出如下描述：
- ? 客戶Customer和Order形成一對多關(guān)系，一個Ｃustomer表可以對應(yīng)零到多個Ｏrder表?！?
- ? 訂單Order和訂單行OrderDetail構(gòu)成了一對多的關(guān)系。
??? 鍵是Ｅ－Ｒ設(shè)計的重要角色，主鍵惟一地表示了數(shù)據(jù)模型內(nèi)一個實體的各實例，而通過外鍵則把各實體連接在一起。?
??? 在圖2中，Ｏrder表的主鍵是ＯrderID,它是自增型整數(shù)序列ＩＤ，它的外鍵是ＣustomerID，映射到了Ｃustomer表；而ＯrderDetail表的主鍵則是通過組合鍵(Composite Key)的ＯrderID和ＤetailLineID來定義的；而Ｃategories表的主鍵是ＧUID,一種唯一性的全球標(biāo)識碼。?
??? 從圖2中，我們已經(jīng)看到了數(shù)據(jù)表的定義主鍵的幾種基本方法?！?
圖3： “創(chuàng)建訂單”順序圖??? 對于圖2的“創(chuàng)建訂單”順序圖 ，我們有如下描述。?
??? 開發(fā)交互圖是面向?qū)ο笤O(shè)計的核心，實現(xiàn)用例的過程就是通過確定哪些類通過發(fā)送消息與其他類交互協(xié)作的過程，順序圖是交互圖的一種。順序圖用于描述進出自動系統(tǒng)的信息流，一個系統(tǒng)順序流記錄了輸入和輸出并且標(biāo)識了參與者和系統(tǒng)之間的交互。在圖3中，已經(jīng)形象地描述了參與者如何通過數(shù)據(jù)和獲得輸出數(shù)據(jù)來和系統(tǒng)進行交互地。?
??? 圖3中，由下劃線對象和一個矩形框組成的是整個系統(tǒng)的各個對象，按照對象出場先后順序排列，它們是Ｃustomer、Website、Account、Product、Order、Order LineItem、Authoriy。?
??? 一旦對象已經(jīng)確定，我們需要給出的是貫穿每個對象生命周期和連接各個對象交互的消息，對于每一條消息，我們有必要列出消息源對象和目的對象。如圖3所示，Customer作為系統(tǒng)參與者，先后給WebSite、Account、Order等對象發(fā)送了消息，而各個對象也各參與者的Customer返回了消息，這樣地消息循環(huán)最終完成了用例所描述的流程。?
??? 比如Customer在本用例中先后發(fā)送了如下消息完成了與系統(tǒng)的整體交互過程：- ? Browses To : 原始消息,從Customer到Web Site,Web Site返回了消息“ Request Credentials” 。
- ? Provide Credentials: 從Customer到Web Site,Web Site返回了消息“ Display homepage” 。
- ? Create Orders: 從Customer到Order。
- ? Find Product : 從Customer到Product.的內(nèi)部消息開始,引發(fā)了從Product到Order的系統(tǒng)主要消息“Add Product to Order”,接著通過發(fā)送源于Order的“Add Order Item:”這一消息的發(fā)送到Order Line Item更顯順理成章,從而完成了用例基本流程的第4步。
- ? Modify Quantity : 從Customer到Product 。
- ? Enter Payment Info:從Customer到Order。
- ? Submit Order:到此Customer已經(jīng)完成了最后一個消息的發(fā)送, 通過本順序圖的完成也以黑匣子的角度模擬了系統(tǒng)的流程。
??? 現(xiàn)在讓我們探討順序圖的設(shè)計規(guī)則：?
??? a) 接受每個輸入消息并確定由這個輸入消息產(chǎn)生的所有內(nèi)部消息。?
??? 確定消息的目標(biāo)。需要什么消息，哪個類（即目的地）需要這條消息，以及哪個類（即消息源）提供這條消息。這種分析有助于理清內(nèi)部消息、源對象和目的地對象。?
??? b) 在處理每個消息的時候，要辨別出受之影響的類的完整集合，即從域類圖中找到需要的所有對象。在用例的前提條件和后續(xù)條件中羅列的任何類都應(yīng)該包含到設(shè)計中去，即被創(chuàng)建的類、創(chuàng)建用例對象的類、用例期間更新的類，以及提供用例需要信息的類。?
??? c) 充實消息的結(jié)構(gòu)，添加迭代、正/誤條件、返回值和傳遞參數(shù)。傳遞參數(shù)應(yīng)該參考域類的屬性。返回值和傳遞參數(shù)可以是屬性，也可以是類中的對象。?
??? 本文行文至此,基本完成了用例“創(chuàng)建訂單”的實現(xiàn),同時探討了交互設(shè)計應(yīng)當(dāng)遵循的準則，希望給讀者有所參考和幫助。 - 目的
轉(zhuǎn)載于:https://www.cnblogs.com/voswin/archive/2008/08/20/1271838.html
總結(jié)
以上是生活随笔為你收集整理的个性化邮件系统用例设计和实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： IP头结构＆其他解析
- 下一篇： .net中用css控制GridView样