【正文】 這些類是基于Java AWT包設(shè)計的，后者是Java中用來編寫用戶界面應(yīng)用程序的一個標準庫。同時，可以用UML中的動態(tài)模型來說明對象如何在特定的情況下做出相應(yīng)的行為。在設(shè)計階段，不僅會細化那些在分析階段定義的類，還會加入一些新的類，以便處理技術(shù)領(lǐng)域的問題，如數(shù)據(jù)庫、用戶界面、通信和設(shè)備等[1]。只要接口一致，更改實現(xiàn)類不影響類的使用者。 貨物類狀態(tài)圖 the State Diagram of Goods Class車輛類有閑置中、使用中、維修中和報廢中四個狀態(tài)。它用于顯示類的對象可能具備的所有狀態(tài)，以及那些引起狀態(tài)改變的事件[1]。上圖中的配貨單是由發(fā)貨單組成的，發(fā)貨單是針對每個車輛生成一個發(fā)貨單，而配貨單是對所有車輛的配貨情況的匯總，因此，二者是聚合的關(guān)系。其他類之間的泛化關(guān)系與上述類似，在此不作贅述。對上述類的分析，快遞物流管理信息系統(tǒng)所涉及的類之間的關(guān)系包括關(guān)聯(lián)、泛化和聚合三種，其中關(guān)聯(lián)關(guān)系這里不單獨列出，將在問題域類圖中列出。允許使用一般元素的實例的任何地方，都可以使用特殊元素的實例來代替。在UML中，關(guān)聯(lián)關(guān)系定義為描述一組鏈接的一種關(guān)系，其中，鏈接定義為一組對象之間的一種語義連接。通過對上述類分析，可以發(fā)現(xiàn)上述類之間是有某種關(guān)系的。對順序圖的消息進行分析，消息的傳遞轉(zhuǎn)化為類的操作。 源站點收貨分析順序圖 源站點收貨分析順序圖 the Analytic Sequence Diagram of the Pickup at Source Site 源站點收貨分析協(xié)作圖 源站點收貨分析協(xié)作圖 the Analytic Collaborative Diagram of the Pickup at Source Site 源站點倉儲分析順序圖 源站點倉儲分析順序圖 the Analytic Sequence Diagram of the Storage at Source Site 源站點倉儲分析協(xié)作圖 源站點倉儲分析協(xié)作圖 the Analytic Collaborative Diagram of the Storage at Source Site 配貨分析順序圖 配貨分析順序圖 the Analytic Sequence Diagram of the Distribution 配貨分析協(xié)作圖 源站點配貨分析協(xié)作圖 the Analytic Collaborative Diagram of the Distribution 發(fā)貨分析順序圖 發(fā)貨分析順序圖 the Analytic Sequence Diagram of the Delivery 發(fā)貨分析協(xié)作圖 發(fā)貨分析協(xié)作圖 the Analytic Collaborative Diagram of the Delivery 注冊登陸分析順序圖 注冊登陸分析順序圖 the Analytic Sequence Diagram of the Registration and Login 注冊登陸分析協(xié)作圖 注冊登陸分析協(xié)作圖 the Analytic Collaborative Diagram of the Registration and Login(2) 問題域類圖（分析類圖）類是具有相同特征（屬性）和相同行為（方法）的對象的集合，類的名稱、屬性和方法是描述一個類的三個最基本的方面。問題域分析中的順序圖和協(xié)作圖是對系統(tǒng)需求分析中的簡明用例順序圖的具體化和細化，它通過對IT系統(tǒng)分解為各個具體的實體對象，對參與者與系統(tǒng)的交互進行可視化建模，即它描述了系統(tǒng)如何實現(xiàn)用戶所需的服務(wù)或系統(tǒng)需要提供的功能。協(xié)作圖是對在一次交互中有意義的對象和對象間關(guān)系的建模。生命線之間的箭頭連接代表信息。而在交互視圖中，這個黑盒子將被打開，顯示出IT系統(tǒng)內(nèi)部發(fā)生的事情。問題域分析將產(chǎn)生問題域的模型：類、對象，以及根據(jù)真實世界中各實體之間關(guān)系進行建模的交互模型。本系統(tǒng)共有11個用例，每個用例都對應(yīng)有一個簡明用例順序圖，分別為：源站點收貨簡明用例順序圖、源站點倉儲簡明用例順序圖、配貨簡明用例順序圖、發(fā)貨簡明用例順序圖、目的站點收貨簡明用例順序圖、目的站點倉儲簡明用例順序圖、送貨簡明用例順序圖、注冊登陸簡明用例順序圖、客戶信息服務(wù)簡明用例順序圖、貨物跟蹤簡明用例順序圖和系統(tǒng)管理簡明用例順序圖。轉(zhuǎn)換事件的結(jié)果取決于轉(zhuǎn)變是否成功，如果成功，信息將被存儲、修改或刪除；如果失敗，那么對用戶和系統(tǒng)而言就沒有任何東西發(fā)生改變。由于快遞物流管理信息系統(tǒng)的目標之一就是實現(xiàn)信息或數(shù)據(jù)收集、加工和處理的方便和快捷，因此，對于以信息為主要處理對象的系統(tǒng)來說，利用簡明用例順序圖是明智的選擇。送貨送貨員對要送達的貨物進行派件處理，即送貨到門，同時要求客戶填寫到貨確認。目的站點收貨目的站點收貨員接收送達本站點的貨物，同時填寫已達貨物清單。每個倉庫倉儲要送達其他某個或某些站點的貨物。事件是用戶通過用戶界面發(fā)起的，例如單擊搜索按鈕或按Enter鍵，這些都將執(zhí)行系統(tǒng)內(nèi)部的某些東西[34]。簡明用例順序圖是用來描述每個用例中用戶與IT系統(tǒng)之間的交互過程，它仍屬于從系統(tǒng)外部來看待系統(tǒng)所能提供的功能，因此屬于外部視圖的范疇，是系統(tǒng)需求分析的內(nèi)容之一。 創(chuàng)建用例圖用例圖被稱為參與者的外部用戶所能觀察到的系統(tǒng)功能的模型圖，是描述需求分析中的業(yè)務(wù)需要IT系統(tǒng)參與的工作。通過對系統(tǒng)的分析和上述角色的分析，確認用例如下：1) 源站點收貨2) 倉儲3) 配貨4) 發(fā)貨5) 目的站點收貨6) 目的站點倉儲7) 送貨8) 客戶附加服務(wù)9) 系統(tǒng)管理其中，源站點收貨與目的站點收貨是兩個不同的概念。它描述的是用戶在使用IT系統(tǒng)時可以扮演的角色，而不一定是一個具體的人。來表示[13]。盡管通常不可能在這樣的文檔中定義所有的事情，但還是應(yīng)該盡可能地細化系統(tǒng)需求[31]。本課題要研究的是快遞物流管理信息系統(tǒng)，因此從系統(tǒng)類型上應(yīng)屬于IT系統(tǒng)。因此，一般來說，分析都是通過與用戶或客戶的協(xié)作完成的[13]。在活動圖中可以明確地看出參與者們（業(yè)務(wù)工人和業(yè)務(wù)角色）是并行執(zhí)行某個業(yè)務(wù)用例還是各自獨立地執(zhí)行。通過上述分析。 業(yè)務(wù)用例圖業(yè)務(wù)用例是描述機構(gòu)中一組相關(guān)的工作流。通過用戶調(diào)研和資料搜集，我們發(fā)現(xiàn)下列幾類業(yè)務(wù)工人是快遞物流業(yè)務(wù)系統(tǒng)必不可少的： 源站點收貨員； 目的站點收貨員； 配貨員； 司機； 送貨員。 確定參與者業(yè)務(wù)系統(tǒng)的外部用戶(例如客戶或業(yè)務(wù)伙伴，在UML中稱為業(yè)務(wù)角色)將使用業(yè)務(wù)系統(tǒng)的輸出，這些外部用戶無需了解業(yè)務(wù)用例具體如何執(zhí)行詳細信息。UML利用業(yè)務(wù)用例圖和高層活動圖來捕獲客戶的需求，這里的客戶需求是全方位的，它既包括手動形式執(zhí)行的業(yè)務(wù)也包括基于IT系統(tǒng)執(zhí)行的業(yè)務(wù)。信息化規(guī)劃必須正確識別這些關(guān)鍵業(yè)務(wù)和流程，正確識別物流戰(zhàn)略對這些業(yè)務(wù)和流程的信息化需求，并從滿足戰(zhàn)略需求著眼，有重點、有針對性地進行規(guī)劃。為了達成以上戰(zhàn)略目標，快遞物流企業(yè)的信息化建設(shè)是重中之重。公司戰(zhàn)略目標如下本民營快遞企業(yè)是沈陽的一家快遞公司，公司主要以國內(nèi)異地快遞和同城快遞為業(yè)務(wù)，目前規(guī)模較小，但發(fā)展勢頭強勁。它為企業(yè)運作、電子商務(wù)和移動計算提供了廣泛的可伸縮性的解決方案，提供一個綜合平臺。從而使用戶能連接到數(shù)據(jù)庫、Web服務(wù)和舊式系統(tǒng)[11]。通過在軟件開發(fā)周期內(nèi)使用同一種建模工具可以確保更快更好的創(chuàng)建滿足客戶需求的可擴展的、靈活的并且可靠的應(yīng)用系統(tǒng)。Rational Rose包括了統(tǒng)一建模語言(UML)，OOSE，以及ＯＭＴ。 數(shù)據(jù)庫管理系統(tǒng)(Database Management System, DBMS)是一種操縱和管理數(shù)據(jù)庫的大型軟件，是用于建立、使用和維護數(shù)據(jù)庫，簡稱DBMS。(2) 概念數(shù)據(jù)層它是數(shù)據(jù)庫的中間一層，是數(shù)據(jù)庫的整體邏輯表示。當某個系統(tǒng)中存在結(jié)構(gòu)上完全分開的若干個數(shù)據(jù)庫時，則該系統(tǒng)包含一個“數(shù)據(jù)庫集合”[8]。用JDBC寫的程序能夠自動地將SQL語句傳送給相應(yīng)的數(shù)據(jù)庫管理系統(tǒng)(DBMS)。(3) JDBCJDBC是一種可用于執(zhí)行SQL語句的JavaAPI(Application Programming Interface應(yīng)用程序設(shè)計接口)，它由一些Java語言編寫的類和界面組成。JavaBean通過提供符合一致性設(shè)計模式的公共方法將內(nèi)部域暴露稱為屬性。從只有一個小的jar文件就可以運行Server/JSP到由多臺服務(wù)器進行集群和負載均橫，到多臺Application進行事務(wù)處理、消息處理，一臺服務(wù)器到無數(shù)以服務(wù)器，Java顯示了一個巨大的生命力。 優(yōu)點1) 一處編寫隨處運行。JSP頁面具有了Serverlet的所有優(yōu)點，如良好的性能和擴展性，對HTTP會話提供嵌入式支持等。當Web服務(wù)器收到瀏覽器訪問JSP網(wǎng)頁請求時，它首先執(zhí)行其中的程序片斷，然后將執(zhí)行的結(jié)果以HTML頁面的形式返回給瀏覽器端[2]。 JSP、JavaBean、JDBC技術(shù)(1) JSPJSP (Java Server Page)它是由SUN公司倡導(dǎo)的由許多公司參與共同建立起來的一種動態(tài)網(wǎng)頁技術(shù)標準。JSP最大的好處就是開發(fā)效率較高，JSP可以使用JavaBeans或者EJB(Enterprise JavaBeans)來執(zhí)行應(yīng)用程序所要求的更為復(fù)雜的處理，但是這種網(wǎng)站架構(gòu)因為其業(yè)務(wù)規(guī)則代碼與頁面代碼混為一團，不利于維護，因此并不適應(yīng)大型應(yīng)用的要求，取而代之的是基于MVC的Web架構(gòu)。JSP技術(shù)是以Java語言作為腳本語言的，熟悉JAVA語言的人可以很快上手。ASP是這幾種腳本語言中最簡單易學(xué)的開發(fā)語言。它大量地借用C和Perl語言的語法，并結(jié)合PHP自己的特性，使Web開發(fā)者能夠快速地寫出動態(tài)產(chǎn)生頁面。因此，許多單位都備有數(shù)據(jù)庫存儲服務(wù)器，以防萬一。所有的操作只需要針對服務(wù)器進行，而無須對客戶端的瀏覽器進行升級和維護。在這種結(jié)構(gòu)下，用戶工作界面是通過IE瀏覽器來實現(xiàn)的。 C/S架構(gòu)的劣勢是高昂的維護成本且投資大首先，采用C/S架構(gòu)，要選擇適當?shù)臄?shù)據(jù)庫平臺來實現(xiàn)數(shù)據(jù)庫數(shù)據(jù)的真正“統(tǒng)一”，使分布于兩地的數(shù)據(jù)同步完全交由數(shù)據(jù)庫系統(tǒng)去管理，但邏輯上兩地的操作者要直接訪問同一個數(shù)據(jù)庫才能有效實現(xiàn)，網(wǎng)絡(luò)管理工作人員既要對服務(wù)器維護管理，又要對客戶端維護和管理，這需要高昂的投資和復(fù)雜的技術(shù)支持，維護成本很高，維護任務(wù)量大。與B/S模式相比，C/S模式的應(yīng)用系統(tǒng)最大的好處是不依賴企業(yè)外網(wǎng)環(huán)境，即無論企業(yè)是否能夠上網(wǎng)，都不影響應(yīng)用[17]。UML從邏輯上包含五種視圖：用例視圖(Use Case View)、邏輯視圖(Logical View)、組件視圖(Component View)、并發(fā)視圖(Concurrency View)和部署視圖(Deployment View)。開發(fā)人員、系統(tǒng)集成人員和測試人員部署圖其中順序圖和協(xié)作圖統(tǒng)稱為交互圖(Interactive Diagram)。客戶、設(shè)計人員、開發(fā)人員以及測試人員用例圖、活動圖邏輯視圖描述如何實現(xiàn)用例視圖中提出的那些系統(tǒng)功能，可以細分為靜態(tài)視圖和動態(tài)視圖。 組件圖(Component Diagram)：組件圖表示了系統(tǒng)中的各種組件。 類圖(Class Diagram)：類圖是以類為中心來組織的，類圖中的其他元素或?qū)儆谀硞€類或與類相關(guān)聯(lián)。每一個對象用一條生命線來表示，即用垂直線代表整個交互過程中對象的生命周期。參與者是系統(tǒng)的主體，是一種角色，表示提供或接收系統(tǒng)信息的人或系統(tǒng)。UML圖形是建模的可視化表示，通過繪制UML圖形，可以從不同的抽象角度使系統(tǒng)可視化。任何一種建模方法都包括兩部分內(nèi)容：建模過程和建模語言。 面向?qū)ο箝_發(fā)方法的開發(fā)過程在面向?qū)ο箝_發(fā)方法的發(fā)展過程中形成了許多復(fù)雜的開發(fā)過程，不利于向一致的方向發(fā)展，妨礙技術(shù)交流，也給用戶的選擇帶來困惑[6]。 面向?qū)ο箝_發(fā)方法 面向?qū)ο蟮拈_發(fā)思想面向?qū)ο蠓椒ㄊ菑默F(xiàn)實世界中客觀存在的事物出發(fā)來構(gòu)造軟件，并在系統(tǒng)構(gòu)造中盡可能運用人類的自然思維方式。(3) 倉儲管理在物流業(yè)務(wù)活動中，由儲存業(yè)務(wù)部門進行有關(guān)儲存計劃、統(tǒng)計資料、物品入庫清單，物品出庫通知，物品在存盤點記錄，儲存中損失、損耗的處理等管理信息工作。物流管理信息系統(tǒng)的具體功能因物流服務(wù)系統(tǒng)的對象不同而差異很大?！奥?lián)合國臨時主要產(chǎn)品分類”(UN Provisional central Product classification，以下簡稱：臨時CPC)中將快遞服務(wù)(CPC7512)定義為：“除國家郵政當局提供的服務(wù)以外，由非郵政速遞公司利用一種或多種運輸方式提供的服務(wù)，包括提取、運輸和遞送信函和大小包裹的服務(wù)，無論目的地在國內(nèi)或國外。還可以方便物流信息的實時采集與追蹤，提高整個物流系統(tǒng)的管理和監(jiān)控水平等。因此，現(xiàn)代物流具有以下幾個特點[5]：(1) 信息化物流信息化表現(xiàn)為物流信息的商品化，物流信息收集的數(shù)據(jù)庫化和代碼化，物流信息處理的電子化和計算機化，物流信息傳遞的標準化和實時化，物流信息存儲的數(shù)字化等。第2章 相關(guān)理論及技術(shù) 物流基礎(chǔ)理論 物流概念和現(xiàn)代物流特點物流來源于英文Logistics System，Logistics的主要含義是后勤保障。第三章，業(yè)務(wù)需求分析、系統(tǒng)分析，利用UML語言和Rational Rose建模工具對其進行全面、系統(tǒng)的分析。在需求分析階段，論文綜合企業(yè)與客戶兩方面的需求，利用UML統(tǒng)一建模語言中的業(yè)務(wù)用例圖與業(yè)務(wù)活動圖對快遞物流企業(yè)的整體業(yè)務(wù)流程進行分析與建模；在系統(tǒng)分析階段，利用UML統(tǒng)一建模語言中的用例圖、簡明用例順序圖、順序圖、協(xié)作圖、類圖以及狀態(tài)圖對系統(tǒng)的功能性需求進行建模；在系統(tǒng)設(shè)計階段，將對系統(tǒng)分析階段產(chǎn)生的順序圖、協(xié)作圖和類圖等進一步的細化，同時對系統(tǒng)的非功能性需求進行建模，對快遞物流管理信息系統(tǒng)的數(shù)據(jù)庫、輸入輸出和界面也進行了較為系統(tǒng)、全面的設(shè)計，即著重從技術(shù)實現(xiàn)角度設(shè)計系統(tǒng)；在系統(tǒng)的實現(xiàn)階段，利用功能強大的JS