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