商務參考體系結構：企業對消費者

摘要：本章將說明 Microsoft 解決方案框架 (MSF) 設計過程的概念階段。在這一階段，設計小組將從潛在使用者和業務的角度來確定主要的解決方案概念和目標。該階段結束時，設計小組將編寫功能說明文件，此文件是以後所有應用程式設計工作的基礎。

簡介

在概念設計階段中，設計小組將根據以前所確定的業務和使用者需求來確定一個完整的專案前景並將其記錄下來。基於這些需求，該小組將準備“應用方案”（源自“用例”），然後建立一個功能說明文件，以便從電子商務應用程式的使用者及供應方的角度來詳細解釋該應用程式的工作原理。該功能說明文件是在概念階段結束時所提交的文件。

應用方案和用例

應用方案通過詳細分析“用例”來建立。用例只是一個說明文字，用於描述外部“操作者”（操作者可以是使用者或現有系統）與所設計的應用程式（或元件）之間的互動。除了使用者之外，操作者還可以是服務、元件等。

建立用例時主要應確定兩方面資訊：一是操作者的操作，二是預期的結果。用例通常是在白板（也稱集體討論）討論中草擬出來的，這種討論將簡要地概括用例，併為其提供描述性名稱。然後將制定出用例的詳細內容，並對其進行某種線性排序。

本章的其餘部分將介紹為 ConsolidatedRetail.com 應用程式開發的各種應用方案，並提供各種方案所述內容的操作用例圖。

應用方案參考體系結構

在概念設計階段中，參考體系結構應用的設計人員會確定如下應用方案：

應用方案 1：客戶登入到站點

客戶導航至登入頁並輸入其使用者名稱和密碼。系統將驗證使用者名稱和密碼。如果使用者輸入了有效的使用者名稱和密碼，則會顯示出一個頁面，它所包含的連結將使使用者能夠更新其使用者配置檔案資訊並檢視其訂單歷史記錄（如“應用方案 6”所述）。

如果客戶將使用者名稱欄位留為空，則提示該使用者必須填寫使用者名稱欄位。

如果客戶將密碼欄位留為空，則提示該使用者必須填寫密碼欄位。

如果客戶輸入的使用者名稱無效，將重新顯示登入頁，並出現錯誤訊息，指出該使用者名稱無效。

如果客戶輸入的使用者名稱有效而密碼無效，將重新顯示登入頁，並出現錯誤訊息，指出該密碼無效。

如果客戶表示已忘記密碼，則將向該客戶提供一個選項，讓其輸入使用者名稱，然後在電子郵件訊息中接收密碼。

圖 2-1 是一個用例圖，用以說明登入功能。

圖 2-1：登入功能

應用方案 2：客戶搜尋產品

客戶可以通過輸入產品的標題、文字或說明來搜尋產品，系統將顯示所有匹配產品，這些產品的說明中都包含使用者在搜尋框中輸入的索引關鍵字。

客戶可以導航至搜尋框，通過輸入產品名的一部分來搜尋產品。系統將顯示與搜尋標準最匹配的產品。

圖 2-2 是一個用例圖形，用以顯示客戶所執行的搜尋。

圖 2-2： 客戶執行搜尋

如果客戶輸入的產品名沒有匹配的產品，或者客戶輸入的產品名有誤，搜尋結果將顯示一則訊息，指出沒有產品與搜尋標準匹配。

如果客戶輸入的關鍵字與產品說明不匹配，系統將顯示一條訊息，指出沒有產品與搜尋標準匹配。

應用方案 3：客戶瀏覽要購買的產品

在這種情況下，客戶選擇要瀏覽的目錄。顯示所選目錄的根中的各類別和各產品。然後，使用者可以選擇要檢視細節的產品，或選擇一個類別，檢視所選類別中的產品集和子類別集。

圖 2-3 是一個用例圖形，用以說明瀏覽方案。

圖 2-3：客戶瀏覽

應用方案 4：客戶管理購物籃

當客戶顯示購物籃時，購物籃可能是空的，也可能包含在本次會話或上次訪問中未購買或已刪除的產品。

如果購物籃為空，應用程式將顯示一條訊息，向該客戶提示購物籃是空的。

如果購物籃包含一種或多種產品，應用程式將顯示一個列表，其中包括每種產品的產品名、價格、數量和總計，以及購物籃中所有產品的總計。

如果客戶選擇刪除某種產品，應用程式將從購物籃中刪除該產品。

如果客戶選擇刪除購物籃中的所有產品，應用程式將刪除購物籃中的所有產品。

如果客戶更改了某一產品的數量，應用程式將對購物籃進行更新，以反映該產品的數量。

如果客戶更新了購物籃，應用程式將重新計算購物籃中每種產品的產品數量和總計，並重新計算購物籃中所有產品的總計。

圖 2-4 是一個用例圖形，用以說明購物籃管理方案：

圖 2-4：客戶管理購物籃

應用方案 5：客戶結帳

客戶表示願意結帳，並願意購買購物籃中產品。

如果客戶當前未登入，將要求該客戶按照“應用方案 1”所述輸入有效的使用者名稱和密碼。然後，應用程式將顯示與當前使用者相關聯的送貨地址列表。客戶可以指定將訂單發往其中一個地址，也可以編輯地址或新增新地址。客戶還可以指定將購物籃中的不同產品發運到不同的地址。

如果客戶指定了單個送貨地址，應用程式將提示該客戶從可用的送貨方式列表中選擇一種送貨方式。

如果客戶指定使用多個地址，應用程式將提示客戶為購物籃中的每一產品選擇地址和送貨方式。

如果客戶選擇新增或編輯地址，應用程式會將客戶重定向到“應用方案 6”中所述的送貨資訊頁之一。

當客戶提供了送貨地址和送貨方式資訊後，應用程式將提示該客戶確認付款地址並提供信用卡型別、帳戶持有人姓名、帳號、到期月和到期年。

如果客戶未指定付款地址，應用程式將顯示一個頁面，讓客戶按照“應用方案 6”所述指定付款地址。

圖 2-5 是一個用例圖形，用以說明結帳功能。

圖 2-5：客戶結帳

下一步，應用程式將顯示訂單、送貨和付款的概要資訊頁。客戶可以確認該訂單或修改其中的資訊。

如果客戶選擇修改訂單，則將回到“應用方案 4”中所述的購物籃頁。

如果客戶確認該訂單，則將顯示感謝訊息和唯一的訂單號。

最後，應用程式將向用戶傳送訂單確認電子郵件，以確認此次訂購。

應用方案 6：客戶提供帳戶和送貨資訊

如果客戶正在以匿名方式瀏覽該站點，則必須按照“應用方案 1”所述輸入使用者名稱和密碼。

“我的帳戶”頁包含指向多個頁面的連結，以便於客戶更改帳戶資訊，更改送貨地址資訊，更改付費地址資訊，更改密碼並檢視訂單歷史記錄。

如果客戶選擇更改其帳戶資訊，應用程式將顯示一個頁面，讓該客戶編輯其帳戶的使用者姓名、電子郵件地址、電話號碼和傳真號碼。

如果客戶選擇編輯地址資訊，應用程式將顯示一個頁面，列出與該帳戶相關聯的所有地址。客戶可以新增新的地址，也可以編輯或刪除現有地址。

如果客戶選擇新增新的地址，應用程式將顯示一個頁面，提示使用者提供此地址項的名稱、收件人姓名、街區地址資訊（兩行）、城市、省份、郵政編碼以及電話號碼。

如果客戶將“列為”、“收件人姓名”、“地址行 1”、“城市”、“省份”、“郵政編碼”欄位留為空，應用程式將提示客戶填寫缺失的資料。如果客戶選擇編輯地址，應用程式將顯示地址欄位，該客戶即可對其進行修改。如果客戶選擇刪除地址，應用程式將刪除帳戶的地址記錄。

如果客戶選擇更改其付款地址，應用程式將顯示一個頁面，提示使用者提供此特定地址項的名稱、收件人姓名、街區地址資訊（兩行）、城市、省份、郵政編碼以及電話號碼。

如果“收件人姓名”、“地址行 1”、“城市”、“省份”、“郵政編碼”或“列為”欄位留為空，應用程式將提示客戶填寫缺失的資料。

如果客戶選擇檢視其訂單歷史記錄，應用程式將顯示一個頁面，其中包含該客戶以前訂單的詳細資訊。

如果客戶選擇更改其密碼，應用程式將顯示一個頁面，提示該客戶輸入舊密碼和新密碼，並確認新密碼。當用戶提交這些資料後，應用程式將檢查舊密碼是否與帳戶中的密碼相匹配，新密碼是否與確認資訊中的密碼相匹配。如果密碼全部匹配，系統將更改與該客戶相關聯的密碼。如果不匹配，應用程式將顯示錯誤訊息，提示客戶重新更改密碼。

圖 2-6 是一個用例圖形，用以說明此方案：

圖 2-6：客戶提供帳戶和送貨資訊

總結

本章介紹了為電子商務應用程式確定應用方案並制定概念設計的過程。圖 2-7 是一個用例圖形，用以顯示已定義的累積應用方案：

圖 2-7：累積應用設計圖

應用方案及其基礎用例都應該說明該應用程式在多種業務過程中的預期行為。應用方案還應從概念上說明應用程式的功能，併為應用程式中元件的邏輯設計提供基礎。另外，因為設計過程具有迭代性，所以如果稍後在開發過程中發現了先前未發現的互動，則可以在設計中包括新的用例。