一.問題描述
基於Web的“在線購物系統”中，客戶可向供應商請求購買一件或多件商品。客戶提供個人信息，例如地址和信用卡信息。這些信息被存儲在客戶賬戶中。如果信用卡是有效的，那麼系統創建一個配送訂單並且發給供應商。供應商檢查可用的庫存，確認訂單，並且輸入一個計劃號的配送日期。當訂單完成配送後，系統通知客戶並且向客戶的信用卡賬戶收費。
二.用例建模
2.1 瀏覽目錄用例
概述：客戶瀏覽萬維網目錄，從供應商的目錄中查看各種各樣的商品項，並且從目錄中選擇商品
參與者：客戶
前置條件：客戶的瀏覽器鏈接到供應商的目錄網站
主序列：
1.客戶請求瀏覽目錄
2.系統向客戶顯示目錄信息
3.客戶從目錄中選擇商品
4.系統顯示商品列表，包括商品描述、價格及總價
可替換序列：
步驟3：客戶沒有選擇商品並且退出
後置條件：系統顯示了所選擇的商品列表
2.2 下單請求用例
用例名稱：下單請求
概述：客戶輸入一個訂單請求來購買目錄商品。客戶的信用卡被檢查其有效性和是否有足夠的額度來支付請求的目錄商品
參與者：客戶
前置條件：客戶選擇了一個或多個目錄商品
主序列：
1.客戶提供訂單請求和客戶賬戶ID來支付購買
2.系統檢索客戶賬戶信息，包括客戶的信用卡詳細信息
3.系統根據購買總額檢查客戶信用卡，如果通過，創建一個信用卡購買授權號碼
4.系統創建一個配送訂單，包括訂單細節、客戶ID和信用卡授權號碼
5.系統確認批准購買，並向客戶顯示訂單信息
可替換序列：
步驟2：如果客戶沒有賬戶，系統提示客戶提供信息來創建一個新賬戶。客戶可輸入賬戶信息或取消訂單
步驟3：如果客戶的信用卡授權被拒絕（例如，無效的信用卡或客戶的信用卡賬戶資金不足），系統提示客戶輸入一個不同的信用卡號碼。客戶可輸入一個不同的信用卡號碼或取消訂單
後置條件：系統爲客戶創建了一個配送訂單
2.3 處理配送訂單用例
用例名稱：處理配送訂單
概述：供應商請求一個配送訂單；系統確定庫存對於滿足訂單是可用的，並且顯示訂單
參與者：供應商
前置條件：供應商需要處理一個配送訂單並且一個配送訂單存在
主序列：
1.供應商請求一個配送訂單
2.系統檢索並顯示配送訂單
3.供應商爲配送訂單請求商品庫存檢查
4.系統確定庫存中的商品對於滿足訂單是可用的，並且保留這些商品
5.系統給供應商顯示庫存信息，並且確認商品被保留
可替換序列：
步驟4：如果庫存不足，系統顯示警告
後置條件：系統爲配送訂單保留了庫存商品
2.4 確認配送和給客戶開賬單用例描述
用例名稱：確認配送和給客戶開賬單
概述：供應商手工地準備配送並且確認配送訂單已經準備好。系統通知客戶訂單正在配送。系統通過客戶的信用卡收取購買商品的款項並且更新相關庫存商品的庫存
參與者：供應商
前置條件：庫存商品已經爲客戶的配送訂單進行了預留
主序列：
1.供應商手工地準備配送並且確認配送訂單已經準備好配送
2.系統檢索客戶的賬戶信息，包括發貨單和客戶的信用卡細節
3.系統更新庫存，確認購買
4.系統通過客戶信用卡收取購買商品款項並且創建一個信用卡收費確認號碼
5.系統用信用卡收費確認號碼更新配送訂單信息
6.系統給客戶發送確認郵件
7.系統向供應商顯示確認信息來完成配送訂單的配送
後置條件：系統提交了庫存，向客戶收費，並且發送了確認信息
三.靜態建模
- 軟件系統上下文建模。
- 考慮外部類與系統之間的交互關係。
- 本例中外部類對應於用例圖中的參與者，上下文圖與用例圖相似。
問題域的靜態實體類建模：
- 客戶類，包括“客戶”、“客戶賬戶”
- 供應商類，包括"供應商"、“庫存”、“目錄”
- 處理訂單的類，例如“配送訂單”
四.類和對象組織
沒有一個統一的方式將一個系統分解爲對象，因爲做出這些決策都是基於分析員的判斷和問題的特性！
上文確定的實體類可通過服務類的形式整合到面向服務的體系結構中
- 目錄服務：使用了“目錄”和“供應商”實體
- 客戶賬戶服務：使用了“客戶賬戶”和“客戶”實體類
- 配送訂單服務：使用了“配送訂單”和“商品”實體類
- 庫存服務：使用了“庫存”實體類
還有一類服務類，不操作實體，但爲其他類提供一種服務能力：
- “信用卡服務”：處理信用卡的授權和付費
- “電子郵件訪問”：發送郵件
五.動態建模
對於每一個用例我們需要開發一個通信圖，用於描述該用例的對象以及這些對象之間消息傳遞的順序。
5.1 瀏覽目錄
- 用戶通過用戶交互發出目錄請求。
- “客戶協調者”被實例化來幫助客戶。
- “客戶協調者”向目錄服務請求信息。
- “目錄服務”發送目錄給客戶協調者。
- “客戶協調者”把信息轉發給“客戶交互”。
- “客戶交互”向客戶顯示目錄信息。
- 客戶通過“客戶交互選擇一個目錄。
- ”客戶交互“傳遞請求給”客戶協調者“。
- ”客戶協調者向”目錄服務”請求目錄選擇。
- “目錄服務”確認目錄商品的可用性並且發送商品價格給“客戶協調者”。
- “客戶協調者”轉發信息給“客戶交互”。
- “客戶交互”向客戶展示目錄信息，包括商品價格和總價。
5.2 下單請求
5.3 處理配送訂單
- 供應商請求一個新的配送訂單。
- “供應商間交互”向“供應商協調者”發送供應商請求。
- “供應商協調者”請求“配送訂單服務”選擇一個配送訂單。
- “配送訂單服務”發送配送訂單給“供應商協調者”。
- “供應商協調者管理者”請求檢查商品庫存。
- “庫存服務”返回商品信息。
- “供應商協調者”發送訂單信息給“供應商交互”。
- “供應商交互”向供應商顯示配送訂單信息。
- 供應商請求系統在庫存中保留商品。
- “供應商交互”發送供應商的請求給“供應商協調者”保留庫存。
- “供應商協調者”請求“庫存服務”來保留庫存中的商品。
- “庫存服務向“供應商協調者”確認商品的保留。
- ”供應協調者“發送庫存狀態給”供應商交互“。
- ”供應商交互“向供應商顯示庫存信息。
5.4 確認配送和給客戶開賬單
5.5 查看訂單
六.設計建模
6.1 分層軟件體系結構
構建被組織到分層的體系結構中，使得每個構件處於依賴所處位置的下層而不是上層的構建層次。這種分層的體系結構便於在線購物軟件體系結構在將來的適應性變化。用戶交互層的用戶交互構件只與協調者構建通信，而協調者構件與服務通信。可以按照如下分層：
服務層：信用卡服務、電子郵件服務屬於“外部服務”其餘服務爲應用內部服務。
協調層：共3個協調者構件。
用戶層：共有3個用戶交互構件
6.2 體系結構通信模式
- 帶回復消息的同步通信模式：當客戶端需要服務的信息並且在接受響應之前不能繼續執行的時候使用這個模式。該模式用於用戶交互客戶端和協調者之間，也可被用於協調者和各種服務之間。
- 代理者句柄：每個服務向代理者註冊服務信息，包括服務名稱、服務描述和位置。“代理者模式”允許客戶查詢代理者來確定它們應該連接的服務。
- 服務發現：“服務發現”模式被服務請求者使用來發現新的服務。
- 雙向異步消息通信：被用於“供應商協調者”和“賬單協調者”之間的雙向異步通信。
- 兩階段提交：這個模式被用於確認庫存、信用卡和配送訂單的更新是原子的，即所有的提交不是被提交就是被終止。
6.3 服務接口設計
每個服務一個供給接口，通過這個接口訪問數據的操作。服務操作是通過考慮在基於用例的交互圖中各個服務是如何被訪問來設計的。服務是基於用例圖中各個服務十日如何被訪問來設計的。
6.4 面向服務的軟件體系結構設計
每個服務有一個帶有供給接口的端口，每個協調者構件有一個或多個供給接口、或者請求接口。在三層體系結構中，每個客戶端-用戶交互構件有一個請求端口，每個服務有一個供給端口，協調者帶有請求和供給接口，因爲它們作爲客戶端和服務之間的中介者需要與多個服務通信。
6.5 構件端口和端口設計
“用戶交互構件”和“供應商交互構件”有一個請求接口；客戶協調者有5個請求端口和1個供給端口，5個請求端口包括“目錄服務”、“客戶賬戶服務”、“配送訂單服務”、“電子郵件服務”、“信用卡服務”的請求接口，1個供給端口與“客戶交互通信”。
6.6 服務複用
利用面向服務的體系結構開發範例，一旦完成了服務的設計以及接口規範，服務的接口信息就可以註冊到一個服務代理者。服務可以被組合爲新的應用。例如其他的電子商務系統也可以複用這個“在線購物系統提供的服務，如“目錄服務”、“配送訂單服務”以及“庫存服務”。