1 引言
1.1 編寫目的
本說明書目的在於明確說明系統各功能的實現方式，指導開發員進行編碼。
本說明書的預期讀者為：系統設計者、系統開發員。
1.2 背景
待開發軟件系統的名稱：物流配送管理系統
此軟件系統任務提出者：客戶（從事物流業）
此軟件系統任務開發者：IT_MOB小組
此軟件系統任務用戶：需要提供配送的客戶、配送點和物流總公司
1.3 基線
物流配送管理系統需求分析說明書 v1.0
1.4 特殊名詞定義
客戶：客戶分為已達成交易的實際客戶和未交易的潛在客戶，本文檔涉及到的所有客戶都是已注冊並登陸客戶端的用戶。
1.5 參考資料
屬於本項目的其他已發表的文件。
本文件中引用的其他文獻、資料以及軟件開發標准。
2 總體設計
2.1 概述
2.2 系統環境描述
系統包括的范圍：物流配送管理系統。
2.2.1 運行環境
2.2.1.1 軟件環境
| 分類 |
名稱 |
版本 |
語種 |
| 操作系統 |
Windows XP |
2000 |
簡體中文 |
| 操作系統的附加功能 |
SP4 |
3 |
簡體中文 |
| 數據庫平台 |
oracle |
92 |
簡體中文 |
| 應用平台 |
tomcat |
5.0 |
簡體中文 |
| 郵件系統 |
Foxmail |
4.2.0 |
簡體中文 |
| 客戶端軟件 |
MS IE |
7.0 |
簡體中文 |
2.2.1.2 硬件環境
| 服務器 |
最低配置 |
推薦配置 |
| 應用和數據庫服務器 |
1CPU：P4 2.0G |
1CPU：P4 2.8G |
| Mem：512M |
Mem：2G |
|
| HD：40G |
HD：120G |
|
|
|
|
|
| 郵件服務器 |
Webmail |
2CPU core2 2.4GB |
2.2.2 開發環境
2.2.2.1 服務器軟件環境
| 分類 |
名稱 |
版本 |
語種 |
| 操作系統 |
Windows server |
2003 |
簡體中文 |
| 數據庫平台 |
oracle |
92 |
簡體中文 |
| 應用平台 |
tomcat |
5.0 |
簡體中文 |
| 郵件系統 |
Foxmail |
4.2.0 |
簡體中文 |
2.2.2.2 服務器硬件環境
| 服務器 |
最低配置 |
推薦配置 |
| 應用服務器、數據庫服務器、郵件服務器、目錄服務器 |
1CPU：P4 2.0G |
1CPU：P4 2.8G |
| Mem：512M |
Mem：2G |
|
| HD：40G |
HD：120G |
2.2.2.3 開發機器軟件環境
| 分類 |
名稱 |
版本 |
語種 |
| 操作系統 |
Windows XP |
2000 |
簡體中文 |
| 數據庫平台 |
oracle |
92 |
簡體中文 |
| 應用平台 |
tomcat |
5.0 |
簡體中文 |
| 開發平台 |
JDK |
1.5 |
英文 |
2.2.2.4 開發機器硬件環境
| 分類 |
最低配置 |
推薦配置 |
| 開發機器 |
1CPU：P4 2.0G |
1CPU：P4 2.8G |
| Mem：512M |
Mem：2G |
|
| HD：40G |
HD：120G |
2.3 系統總體結構設計
2.3.1 系統業務層次圖
內容描述：物流管理系統是應當前物流發展趨勢的產物，旨在為物流組成的各項業務提供一個完整、統一的平台，具有信息共享，資源合理分配，業務協調統一的特點。它分為前台客戶端、后台總公司與分公司端共三個子系統。
圖例：
功能簡介（類似需求分析）：
客戶端：查詢運費，下訂單和訂單進度查詢；
分公司：訂單管理（下訂單，訂單審核，訂單修改，訂單狀態修改），訂單異常處理（訂單異常處理登記，訂單異常處理查詢），訂單發貨（待發訂單查詢，加開班次申請，交接單生成，交接單綁定，緊急訂單提醒，班次查詢），交接單管理（交接單生成，交接單綁定，交接單確認，交接單修改），訂單收獲（交接單確認，交接單修改，班次查詢），貨物配送（庫存訂單查詢，訂單確認），本地信息設置（中轉路線選擇，配送價格申報）；
總公司：配送點管理（添加新配送點，審核各配送點申報的配送費方案），財務管理（統計各部門收益，制定和調整利潤分配方案），信息查詢（交接單查詢，訂單查詢），線路設置（建立基本線路，管理線路，提供線路查詢），運費管理（制定和修改運費方案，提供運費查詢），車輛管理（維護車輛基本信息），班次管理（設置班次，為配送點提供班次查詢，處理配送點加急班次申請），權限管理（權限分配，后台用戶的管理）。
2.3.2 系統架構說明
說明整個系統的軟硬件架構層次:
圖例如下：
2.3.3 軟件架構說明（選作）
書寫要求：根據系統設計的功能層次逐一說明（與需求分析中的“系統功能總體說明
”部分的內容基本一致）
2.2.1.2系統架構設計說明
書寫要求：根據系統的功能需求設計並說明系統開發所采用的軟件開發架構。
書寫樣例：
Jsp & Servlet & JavaBean架構
架構結構
具體架構層次如圖4.1所示。
圖 4.1 Jsj架構結構
各層實現功能說明
View層是與客戶的交互層，負責提交用戶請求和數據，並將后台的響應結果返回給客戶層。同時提供客戶提交信息的javasript驗證功能。
Control層負責項目中業務功能實現流程的管理工作。如：具體的業務功能由哪些類來實現，實現結果有誰來顯示等等，必須由Control層來決定。同時Control層還要負責與其它兩層的通信，這個過程還需要一些bean類來協助傳遞信息，另外Control層還要負責請求的轉發與從定向。從Control層所負責的功能上不難想象的到在業務邏輯相對復雜的時候此層代碼編寫會略顯繁重和復雜。
Model層主要是一些實現具體業務功能的類，在這里可以統一簡稱為Business類。也可以將架構中除了Servlet控制器之外的所有類統一叫做Javabean類。從這種命名方式上可以看出，model層在實現業務功能是具體的實現方式比較自由，但在業務邏輯比較復雜的情況下model層職能的划分會出現問題，可能會造成一定混亂和不便。設想一下如果可以更明確的將model層進一步划分使之變得更有條理，這樣就會增強該層的可維護性了。
特別說明，圖4.1 中的“bean”可以看作數據封裝類，它以實例對象的形式作為各層之間數據通信的載體，實際上這些對象也屬於業務對象，如User對象、Book對象。
Jsp & Servlet & JavaBean架構特點說明
1.架構的優點
結構簡單明了，搭建時配制信息很少只有一個文件“web.xml”，該文件主要用來映射Servlet。Control層的應用一定程度上將Jsp中的Java代碼分離出來，使得jsp文件的復雜程度有所降低。另外該架構涉及到的架構知識較少，很容易上手。基於Java語言的Web開發技術掌握難易順序大致可參見圖4.2所示。
圖4.2 基於Java語言的Web開發技術掌握難易順序
通過圖4.2 可見Jsp+Servlet+JavaBean 這種架構技術組合難度是很低的。
2.架構的缺點
不能將Java代碼完全從頁面上脫離，頁面中會用Js驗證代碼，使Jsp頁面結構相對復雜，不易維護。Control層讀取客戶提交的信息要逐條操作，代碼書寫比較麻煩，Controler層要定義處理響應的分支和model層類的調用，使得Controler本身內容較多不便開發和維護。
另外Jsp+Servlet+JavaBean架構技術組合層次簡單，各層的代碼開發較隨意自主，尤其是在JavaBean實現的Model層由於完成的業務功能多種多樣，如果開發人員沒有很好的遵循一定開發規范或是開發思路不清晰，那么代碼開發會變得混亂。為了解決這些問題，引入一定的架構技術來調理代碼開發就變得很必要了。下面一節將Struts、Spring、Hibernate三種比較流行的架構技術引進架構設計中來構建一種較為復雜卻層次清晰得的開發模式。
具體架構層次如圖4.3所示。
SSH架構結構圖（圖例1）
n 各層實現功能及開發技術說明
1.四層結構的優勢
1）通過成熟的開源產品實現各層功能開發，比起自己開發能縮短開發周期，且架構所用到的開源產品均有很廣泛的用戶群，經受過實踐的考驗，質量和性能更有保障。
2）層與層之間松散偶合，增加代碼重用率。
3)各層分工明確，這樣也利於團隊的明確分工。
2.表示層
這一層是面向用戶的界面，是用戶與系統之間交互的媒介。如：用戶在界面發送請求，系統接收請求，進行處理，然后通過界面將結果呈現於用戶。這一過程包括了用戶動作、數據傳遞、界面顯示。大家熟悉的MVC模式就是將這三者分離，減少三者耦合。我們在該層借助了Struts來實現。
2）Struts的實現的功能:
管理用戶的請求，做出相應的響應。
提供一個Controller，委派調用業務邏輯和其它上層處理。
處理異常，拋給Struts Action.
為顯示提供一個模型。
UI（User interface）驗證。
以下部分則不該在Struts顯示層的編碼中經常出現。因為在表示層引入這些代碼，則會帶來高偶合和非常麻煩的維護代價。
直接的與數據庫通信，如JDBC調用。
與你應用程序相關聯的業務邏輯以及校驗。
3.業務層
業務層在實際的項目開發中，每個領域都會有自己獨特的業務邏輯，正因為這樣，致使項目中代碼高度偶合，原本有可能被重用的代碼或功能，因為與具體的業務邏輯綁定在一塊而導致很難被重用。因此我們將實現這些具體邏輯的代碼抽取出來分為單獨的一層，其目的是希望通過分層，來降低它與系統其他部分的偶合度。
現實中世界是變化的，既然該層實現的是現實中具體的業務邏輯，那該層的實現代碼不可避免的會發生變更。怎樣讓該層適應最大的變化，做到最小的改動?通常我們在編碼的時候會盡量考慮到同一業務多種實現的兼容和可擴展的能力。因此我們在該層借助了Spring，通過依賴注入、AOP應用、面向接口編程，來降低業務組件之間的偶合度，增強系統擴展性。
2）Spring實現的功能:
處理應用程序的業務邏輯和業務校驗。
管理事務。
提供與其它層協同工作的接口。
管理業務層級別的對象的依賴。
在顯示層和持久層之間增加了一個靈活的機制，使得他們不直接的聯系在一起。
通過揭示從顯示層到業務層之間的Context來得到business services。
管理程序的執行（從業務層到持久層)。
4.數據持久層
數據持久層在開發中與數據庫進行數據交互必不可少，通常我們歸為CRUD（添加、讀取、修改、刪除)，這些操作占據了系統開發中大部分的時間，同時我們還需要考慮與數據庫交互的性能問題，如連接池、數據緩存等等。系統內部的持續層不但需要大量調試時間，而且還經常缺少功能使之變得難以控制。針對這點我們引入ORM開源架構Hibernate。
2）Hibernate實現的功能:
查詢對象的相關信息的語句。
存儲，更新，刪除數據庫記錄。
支持大部分主流數據庫，並且支持Parent/Child關系，事物處理，繼承和多態。
5.各層中的封裝類
各層的封裝類的主要功能都是一致的，就是將有一定聯系的數據集合裝載在其實力對象中，這樣做的道路是顯而易見的，通過對象來傳遞數據集合的效率會更高更方便。
顯示層的FormBean類是用封裝來自頁面form提交的信息的，一般情況下這個類的私有變量是與頁面form的元素一一對應的。另外FormBean封裝類的對象還負責將要顯示的信息傳遞到顯示層，其作用是雙向的。
業務邏輯層的ValueObject類是用來封裝一定業務功能實現過程中需要的數據集合的，也就是說要封裝的數據都是由業務功能的需要決定的。
持久層的PersistObject類，其實例化對象所封裝的數據集是與數據庫中表相對應的，即表項對應要封裝的數據項。
我們根據上面封裝類的說明可以看出，FormBean、ValueObject、PersistObject、三者的作用相似都是為了封裝數據信息，不同的是這些對象所在的是不同架構層面，這樣做的好處是數據的處理和轉遞比較有條理，層次清晰易於維護。封裝類在架構中的情況如圖4.4所示。
各層封裝類的情況（圖例2）
2.3.4 關鍵技術與算法
書寫要求：
對系統中比較復雜的功能的實現方式或應用的特殊技術加以說明要求通俗直觀便於客戶參考。
書寫樣例：
查詢統計（科學項目的查詢和統計，科學成果的查詢和統計，科學獎勵的查詢和統計，科技人才的查詢和統計）
組合檢索：組合檢索由擁有搜索權限的用戶在組合類別的下拉框中選擇需要查詢的項目，如科技項目的檢索：項目類別+項目資金+項目所屬公司+時間；沒有選擇的項，下拉框默認為空白。點擊搜索，系統將對數據庫的字段進行模糊搜索，搜索結果列表顯示於組合搜索下面，分頁顯示搜索結果。
注：其它的科技成果搜索，科技獎勵搜索，科技人才搜索采用統一的組合搜索形式
統計圖表：各分公司統計：根據用戶在科技項目申請，科技成果申請，科技獎勵申請，科技人才的輸入的數據，當擁有該權限的用戶點擊各分公司統計，系統將從數據庫中讀取以上的部分數據，進行統計，然后以統計圖形的形式顯示出來，對各分公司進行比較，方便領導制定企業決策。
某分公司統計：當擁有權限的用戶點擊某分公司統計，系統將從數據庫中讀取這對該公司的數據進行統計，顯示統計圖，該統計主要面向集團和分公司領導。
注：其它的科技成果搜索，科技獎勵搜索，科技人才搜索采用統一的統計形式
2.2.3關鍵數據結構（選作）
書寫要求：
簡要說明本系統中的最主要的數據結構。
書寫樣例：
3 系統功能設計
3.1 分公司
3.1.1 訂單管理
3.1.1.1 功能描述
訂單的填寫可以由用戶通過web前台完成，也可以由收貨員在配送點完成，在用戶填寫的情況下，需要收貨員對物品的重量及體積進行審核，經過審核后確認訂單完成並收取貨物，最后將貨物入庫。如圖3.1.1_1和3.1.1_2。
圖3.1.1_1
圖3.1.1_2
3.1.1.2 接口設計
輸入操作：客戶或管理員輸入訂單詳細信息並提交。
輸出效果：訂單成功進入待審列表。
管理員對待審列表中的訂單進行審核，填寫相關審核結果。
3.1.1.3 功能流程圖
3.1.2 訂單發貨
3.1.2.1 功能描述
配送點理貨員通過查詢當天該配送點的可用班次可以為倉庫內貨物安排發貨，通過查詢庫存內訂單的目的地以及需要中轉的訂單列表進行安排訂單，並生成交接單，在貨物裝貨后，將交接單與班次綁定從而完成一次發貨，同時系統提供緊急貨物提醒功能，如果訂單即將到達收貨承諾日期，則進行提醒，理貨員可以根據實際情況向總部提交加開班次申請，見圖3.1.2_1,3.1.2_2,3.1.2_3,3.1.2_4,3.1.2_5,3.1.2_6。
圖3.1.2_1
圖3.1.2_2
圖3.1.2_3
圖3.1.2_4
圖3.1.2_5
圖3.1.2_6
3.1.2.2 接口設計
輸入操作：輸入查詢班次的條件，點擊查詢按鈕。
輸出效果：以列表形式詳細列出當日班次情況。
輸入操作通過界面進行。
輸入操作：輸入交接單生成信息，並確定生成交接單。
輸出效果：生成交接單。
輸入操作通過界面進行。
輸入操作：選擇交接單編號和訂單編號，綁定操作。
輸出效果：成功綁定交接單。
輸入操作通過界面進行。
輸入操作：輸入查詢條件，查詢待發訂單。
輸出效果：以列表形式顯示待發訂單。
輸入操作通過界面進行。
輸入操作：輸入查詢條件，查詢加急訂單。
輸出效果：以列表形式顯示加急訂單。
輸入操作通過界面進行。
輸入操作：輸入加開班次的往返配送點等信息，申請加開班次。
輸出效果：成功向總公司申請加開班次。
輸入操作通過界面進行。
3.1.2.3 功能流程圖
3.1.3 訂單發貨
3.1.3.1 功能描述
配送點的理貨員通過查看到達的班次來安排收貨，收貨的過程中需要對本地卸貨的交接單內的訂單進行檢查，同時將本地裝貨的交接單進行裝貨，對於訂單有缺損的情況，先將訂單從交接單中刪除，對訂單單獨進行異常處理，然后標記交接單完成，最后將訂單分類入庫即可，見圖3.1.3_1,3.1.3_2和3.1.3_3。
圖3.1.3_1
圖3.1.3_2
圖3.1.3_3
3.1.3.2 接口設計
輸入操作：輸入查詢抵達班次的條件，點擊查詢按鈕。
輸出效果：以列表形式詳細列出抵達班次情況。
輸入操作通過界面進行。
輸入操作：輸入查詢抵達交接單條件。
輸出效果：以列表形式顯示抵達本配送點的交接單。
輸入操作通過界面進行。
輸入操作：查詢異常交接單。
輸出效果：列表形式顯示異常交接單。
輸入操作通過界面進行。
3.1.3.3 功能流程圖
3.1.4 貨物配送
3.1.4.1 功能描述
配送點管理員可查詢庫存訂單，然后根據系統生成的待配送訂單（依據訂單優先級自動生成）組織配送人員及時准確的將貨物送到收貨人手中，見圖3.1.4_1和3.1.4_2。
圖3.1.4_1
圖3.1.4_2
3.1.4.2 接口設計
輸入操作：輸入查詢庫存訂單條件，查詢庫存。
輸出效果：以列表形式顯示庫存訂單。
輸入操作通過界面進行。
輸入操作：輸入查詢待配送訂單條件，並查詢。
輸出效果：列表形式顯示待配送訂單。
輸入操作通過界面進行。
3.1.4.3 功能流程圖
3.1.5 訂單異常處理
3.1.5.1 功能描述
訂單和貨物在入庫、出庫和運輸等過程中可能會出現破損丟失等情況，配送點管理員需要對這些異常訂單記錄並作出相應的處理辦法。見圖3.1.5_1和3.1.5_2。
圖3.1.5_1
圖3.1.5_2
3.1.5.2 接口設計
輸入操作：填寫異常訂單登記表信息，並提交。
輸出效果：異常訂單被成功記錄。
輸入操作通過界面進行。
輸入操作：輸入查詢異常訂單條件，並查詢。
輸出效果：列表形式顯示異常訂單。
輸入操作通過界面進行。
3.1.5.3 功能流程圖
3.1.6 本地信息設置
3.1.6.1 功能描述
配送點在配送貨物前，需要設置統一的配送費方案，要綜合考慮自身及客戶的利益，然后向總公司申報，經審核批准后，方可按次配送費方案運營。
配送貨物時，因條件限制，有些訂單不能直達。配送點需要選擇合適的中轉路線，以保證訂單的及時到達。
配送點同時也要設置一些用戶權限，保障系統安全穩定的運行。見圖3.1.6_1,3.1.6_2和3.1.6_3。
圖3.1.6_1
圖3.1.6_2
圖3.1.6_3
3.1.6.2 接口設計
輸入操作：分別填寫以質量和以體積為單位收費的配送費方案。
輸出效果：系統得到一待審核的配送費方案。
輸入操作通過界面進行。
輸入操作：將設置的配送費方案提交給總公司審核。
輸出效果：待審核方案成功被提交給總公司。
輸入操作通過界面進行。
輸入操作：輸入查詢中轉路線及班次，選擇合適中轉路線。
輸出效果：列表顯示可選擇中轉路線及班次。
輸入操作通過界面進行。
3.1.6.3 功能流程圖
3.1.7 財務管理
3.1.7.1 功能描述
配送點作為一個營利性的單位，需要定期對財務進行統計和匯報，以檢驗當前的運營制度。見圖3.1.7_和3.1.7_2。
圖3.1.7_1
圖3.1.7_2
3.1.7.2 接口設計
輸入操作：查詢並選擇待統計訂單，計算月收益。
輸出效果：得到每月收益。
輸入操作通過界面進行。
輸入操作：輸入一時間段。
輸出效果：顯示該時間段內匯報的統計列表。
輸入操作通過界面進行。
3.1.7.3 功能流程圖
3.2 客戶端
3.2.1 運費查詢
3.2.1.1 功能描述
客戶通過輸入待配送貨物的配送地、質量和體積估算需要的費用。見圖3.2.1_1。
圖3.2.1_1
3.2.1.2 接口設計
輸入操作：輸入貨物收發地，貨物質量和體積，進行估算。
輸出效果：輸出估算出的費用。
輸入操作通過界面進行。
3.2.1.3 功能流程圖
3.2.2 下訂單
3.2.2.1 功能描述
客戶決定接受此配送服務后，可以進如下訂單界面，填寫相關訂單信息，提交后即達成交易。
見圖3.2.2_1。
圖3.2.2_1
3.2.2.2 接口設計
輸入操作：填寫點單詳細信息。
輸出效果：訂單成功進入待審核列表中。
輸入操作通過界面進行。
3.2.2.3 功能流程圖
3.2.3 訂單進度查詢
3.2.3.1 功能描述
客戶需要隨時了解已下訂單的狀態，所以系統應當提供查詢訂單進度的功能。見圖3.2.3_1。
圖3.2.3_1
3.2.3.2 接口設計
輸入操作：填寫訂單編號。
輸出效果：顯示訂單進度。
輸入操作通過界面進行。
3.2.3.3 功能流程圖
3.3 總公司
3.3.1 線路管理
3.3.1.1 功能描述
總公司建立配送點間基本線路，管理運輸線路，為配送點提供線路查詢。見圖3.3.1_1和3.3.1_2。
圖3.3.1_1
圖3.3.1-2
3.3.1.2 接口設計
輸入操作：輸入配送點相關信息。
輸出效果：增加配送點間線路。
輸入操作通過界面進行。
輸入操作：查詢配送點間線路。
輸出效果：返回配送點間線路。
輸入操作通過界面進行。
3.3.1.3 功能流程圖
3.3.2 車輛管理
3.3.2.1 功能描述
往返配送點間的車輛由總公司提供，其所有權為總公司的。總公司需對其基本信息進行維護。見圖3.3.2_1。
圖3.3.2_1
3.3.2.2 接口設計
輸入操作：輸入車牌號，檢索車輛信息。
輸出效果：顯示車輛基本信息。
輸入操作通過界面進行。
3.3.2.3 功能流程圖
3.3.3 班次管理
3.3.3.1 功能描述
總公司設置班次，為配送點提供班次查詢，處理配送點加急班次。見圖3.3.3_1和3.3.3_2。
圖3.3.3_1
圖3.3.3_2
3.3.3.2 接口設計
輸入操作：輸入起始地和目的地，查看班次信息。可以新增，刪除班次。
輸出效果：顯示配送點間班次信息。
輸入操作通過界面進行。
輸入操作：點擊處理，選擇待加急班次。
輸出效果：新增加急班次。
輸入操作通過界面進行。
3.3.3.3 功能流程圖
3.3.4 配送點管理
3.3.4.1 功能描述
總公司添加新配送點，審查各配送點配送費計算方案。見圖3.3.4_1和3.3.4_2。
見圖3.3.4_1
圖3.3.4_2
3.3.4.2 接口設計
輸入操作：選擇配送點，點擊新增。
輸出效果：新增配送點。
輸入操作通過界面進行。
輸入操作：輸入配送點，查詢並審查配送費方案。
輸出效果：顯示配送費方案。
輸入操作通過界面進行。
3.3.4.3 功能流程圖
3.3.5 財務管理
3.3.5.1 功能描述
總公司制定利潤分配方案，統計各部門收益。見圖3.3.5_1、3.3.5_2
和3.3.5_3。
圖3.3.5_1
圖3.3.5_2
圖3.3.5_3
3.3.5.2 接口設計
輸入操作：分別輸入以質量和以體積為標准的收費方案，點擊修改。
輸出效果：成功設置運費方案。
輸入操作通過界面進行。
輸入操作：分別輸入總公司、收獲配送點和發送配送點占運費、收發配送費的比列。
輸出效果：成功設置利潤分成。
輸入操作通過界面進行。
輸入操作：輸入收益統計中涉及到的部門和時間等條件。
輸出效果：返回收益統計。
輸入操作通過界面進行。
3.3.5.3 功能流程圖
4 尚待解決的問題
暫無...
參考：軟件概要設計-模板