軟件概要設計-模板

 

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 尚待解決的問題

暫無...