【正文】 智的選擇。理論和實踐已證明將以下兩種類型的事件區(qū)分開來是有價值的：1) 查詢事件的目標是顯示信息，通常不會修改IT系統(tǒng)中的任何東西。查詢事件的結果就是已經顯示的信息。2) 轉換事件的目標是對IT系統(tǒng)中的信息進行存儲、修改或刪除操作。轉換事件的結果取決于轉變是否成功，如果成功，信息將被存儲、修改或刪除；如果失敗，那么對用戶和系統(tǒng)而言就沒有任何東西發(fā)生改變。在UML中并沒有對查詢事件和轉換事件的支持，因為我們將使用UML擴展構造型，它是UML中一種用來表示自定義元素的擴展機制。我們將對該語言進行擴展，創(chuàng)建兩種特定的事件類型：在事件名稱之前添加構造型《Q》表示該事件是查詢事件；在事件名稱之前添加構造型《M》表示該事件是轉換事件。在簡明用例順序圖中，我們能夠清楚地了解其涉及的是什么類型的事件，但并沒有將IT系統(tǒng)對這些事件的應答描述成一個獨立的事件，因為每個事件都有其固有的反饋。本系統(tǒng)共有11個用例，每個用例都對應有一個簡明用例順序圖，分別為：源站點收貨簡明用例順序圖、源站點倉儲簡明用例順序圖、配貨簡明用例順序圖、發(fā)貨簡明用例順序圖、目的站點收貨簡明用例順序圖、目的站點倉儲簡明用例順序圖、送貨簡明用例順序圖、注冊登陸簡明用例順序圖、客戶信息服務簡明用例順序圖、貨物跟蹤簡明用例順序圖和系統(tǒng)管理簡明用例順序圖。鑒于篇幅限制，這里只列出其中的5個，如下圖所示。 源站點收貨簡明用例順序圖 源站點收貨簡明用例順序圖 the Concise Sequence Diagram of the Pickup Use Case at Source Site 源站點倉儲簡明用例順序圖 源站點倉儲簡明用例順序圖 the Concise Sequence Diagram of the Storage Use Case at Source Site 配貨簡明用例順序圖 配貨簡明用例順序圖 the Concise Sequence Diagram of the Distribution Use Case 發(fā)貨簡明用例順序圖 發(fā)貨簡明用例順序圖 the Concise Sequence Diagram of the Delivery Use Case 注冊登陸簡明用例順序圖 注冊登陸簡明用例順序圖 the Concise Sequence Diagram of the Registration and Login Use Case 問題域分析對系統(tǒng)進行需求分析后，接下來的工作就是問題域分析。該分析活動應該沒有任何技術或實現(xiàn)細節(jié)，因為它是對將要解決的問題的確切陳述，所以分析應該包含一個理想的模型，另外，分析還涉及到那些與問題域有關的必備知識[31]。問題域分析將產生問題域的模型：類、對象，以及根據(jù)真實世界中各實體之間關系進行建模的交互模型。這里將利用交互視圖、類圖和狀態(tài)圖對問題域進行分析，其中交互視圖包括順序圖和協(xié)作圖[13]。(1) 交互視圖交互視圖和用例之間存在著很緊密的關系。用例展開的是外部視圖，它將系統(tǒng)看成一個黑盒子。而在交互視圖中，這個黑盒子將被打開，顯示出IT系統(tǒng)內部發(fā)生的事情。交互視圖展示了處理特定任務所需的對象，以及這些對象相互通信的機制。UML使用兩種圖來進行交互視圖建模：順序圖和協(xié)作圖。順序圖表示對象之間傳送消息的時間順序，每一個對象用一條生命線來表示，用垂直線代表整個交互過程中對象的生命周期。生命線之間的箭頭連接代表信息。順序圖可以用來進行一個場景說明，即一個事務的歷史過程。順序圖關注的焦點是時間。這里的順序圖和簡明用例順序圖是不同的，簡明用例順序圖是外部視圖的范疇，而順序圖著眼于系統(tǒng)內部，將系統(tǒng)展開進行分析。協(xié)作圖是對在一次交互中有意義的對象和對象間關系的建模。它也可以描述對象之間是如何交互的，但協(xié)作圖中的主要焦點是空間。將焦點集中于空間意味著協(xié)作圖對對象之間的空間關系特別感興趣，因而會在圖中明確地顯示它們。順序圖和協(xié)作圖結合起來，從不同角度來看待交互過程，因此可以完整的描述一個用例中對象間完整的交互過程。問題域分析中的順序圖和協(xié)作圖是對系統(tǒng)需求分析中的簡明用例順序圖的具體化和細化，它通過對IT系統(tǒng)分解為各個具體的實體對象，對參與者與系統(tǒng)的交互進行可視化建模，即它描述了系統(tǒng)如何實現(xiàn)用戶所需的服務或系統(tǒng)需要提供的功能。本系統(tǒng)共有11個用例，同簡明用例順序圖一樣，分析順序圖和分析協(xié)作圖 這里的分析順序圖和分析協(xié)作圖，是對系統(tǒng)需求分析中的簡明用例順序圖的細化和具體化，通過對系統(tǒng)分解為各個實體對象，對參與者和系統(tǒng)的交互進行可視化建模。這里是為了與前者區(qū)分而采用的叫法。也分別應有11個，鑒于篇幅所限，這里僅列出其中的10個，分別為：源站點收貨分析交互視圖、源站點倉儲分析交互視圖、配貨分析交互視圖、發(fā)貨分析交互視圖和注冊登陸分析交互視圖。 源站點收貨分析順序圖 源站點收貨分析順序圖 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) 問題域類圖（分析類圖）類是具有相同特征（屬性）和相同行為（方法）的對象的集合，類的名稱、屬性和方法是描述一個類的三個最基本的方面。類圖是面向對象系統(tǒng)的建模中最常見的圖，顯示了一組類、接口、協(xié)作以及他們之間關系[1]。在抽象模型中表述現(xiàn)實世界，可以分為兩個步驟：第一步，將個別人或事物抽象成對象；第二步，把類似的對象組合成類。通過對快遞物流管理信息系統(tǒng)用例視圖、簡明用例順序圖和交互視圖分析，尋找對象，定義對象，將功能分配到對象上，并歸納各對象應記錄的屬性，對這些對象進行抽象，描述過程中的類。對順序圖的消息進行分析，消息的傳遞轉化為類的操作。上節(jié)中順序圖和協(xié)作圖描述了快遞物流基本工作流程，顯示了描述事件流過程中的對象（順序圖和協(xié)作圖的矩形），對這些對象進行抽象，描述出業(yè)務處理過程中的類。對順序圖和協(xié)作圖的消息（對象之間的通信，即圖中的箭頭）進行分析，每個消息都轉化為類的操作[33]。通過對系統(tǒng)需求分析和細化用例可以發(fā)現(xiàn)快遞物流管理信息系統(tǒng)的問題域類有：源站點、源站點客戶、源站點倉庫、源站點倉儲單、源站點車輛、目的站點、目的站點客戶、目的站點倉庫、目的站點倉儲單、目的站點車輛、貨物、配貨單、發(fā)貨單、已達貨物列表和送貨單。通過對上述類分析，可以發(fā)現(xiàn)上述類之間是有某種關系的。在UML中類之間的關系有關聯(lián)（Association）、泛化（Generation）、依賴（Dependency）和精化（Refinement）四種[1]。只有定義和描述了類之間的關系，各個類才能構成一個整體、有機的靜態(tài)模型即類圖。關聯(lián)是類之間的一種連接。在UML中，關聯(lián)關系定義為描述一組鏈接的一種關系，其中，鏈接定義為一組對象之間的一種語義連接。在關聯(lián)關系中，也存在著一種稱為“聚合”的關系，它是關聯(lián)的一種特殊情況。泛化是一種在一般元素和特殊元素之間存在的關系。其中，特殊元素可以只包含那些附加信息。允許使用一般元素的實例的任何地方，都可以使用特殊元素的實例來代替。依賴是元素之間存在的一種關系，其中，一個是依賴元素，一個是被依賴元素。對后者的影響將影響到前者。精化是同一事物的兩種描述之間的一種關系，這兩種描述是在不同抽象層次進行的。對上述類的分析，快遞物流管理信息系統(tǒng)所涉及的類之間的關系包括關聯(lián)、泛化和聚合三種，其中關聯(lián)關系這里不單獨列出，將在問題域類圖中列出。其中。 類泛化關系示例圖Figure the Diagram of Generalization Relationship between Classes源站點倉庫和目的站點倉庫是相對的概念，源站點與目的站點之間是可以角色互換的，二者本質是相同的，如都具有名稱、所屬站點、體積和狀態(tài)等屬性，同時都具有添加、刪除和更新狀態(tài)等操作，因此，可以將兩者相同的部分抽象出一個新的類，即父類。二者都是該父類的特殊形式，可以繼承父類，同時在父類的基礎上添加自己獨有的屬性和操作。其他類之間的泛化關系與上述類似，在此不作贅述。快遞物流管理信息系統(tǒng)中的類之間的關系除了泛化外，還有一種聚合關系。 類聚合關系示例圖Figure the Diagram of Aggregation Relationship between Classes聚合關系是關聯(lián)關系的一種特殊形式。它指出了類之間的關系是“整體與部分”的關系。上圖中的配貨單是由發(fā)貨單組成的，發(fā)貨單是針對每個車輛生成一個發(fā)貨單，而配貨單是對所有車輛的配貨情況的匯總，因此，二者是聚合的關系。該系統(tǒng)涉及的問題域類有多個。 快遞物流管理信息系統(tǒng)分析類圖 the Analytic Class Diagram of Express Logistics MIS。 快遞物流管理信息系統(tǒng)分析類圖(含類之間的關系) the Analytic Class Diagram of Express Logistics MIS (with Relationship)(3) 狀態(tài)圖一般來說，狀態(tài)圖（State Diagram）是對類的描述的補充。它用于顯示類的對象可能具備的所有狀態(tài)，以及那些引起狀態(tài)改變的事件[1]。在實際建模時，并不需要為所有的類都繪制狀態(tài)圖，僅對那些具有多個明確狀態(tài)的類，并且類的這些不同狀態(tài)會影響和改變類的行為時才繪制類的狀態(tài)圖。對該系統(tǒng)進行分析，貨物和車輛兩個類都有多個明確的狀態(tài)，并且狀態(tài)的不同會影響類的行為。貨物類有已收貨、配貨中、發(fā)貨中和送貨中四種狀態(tài)，不同的事件會對貨物的狀態(tài)有不同的影響。 貨物類狀態(tài)圖 the State Diagram of Goods Class車輛類有閑置中、使用中、維修中和報廢中四個狀態(tài)。 車輛類狀態(tài)圖 the State Diagram of Vehicle Class第4章 快遞物流管理信息系統(tǒng)的系統(tǒng)設計 系統(tǒng)設計目標和原則 系統(tǒng)設計目標系統(tǒng)的設計目標：可擴展性，靈活性，可插入性[19]。(1) 可擴展性：新的功能很容易集成到現(xiàn)有的系統(tǒng)中去，而不影響到系統(tǒng)的其他模塊；(2) 靈活性：允許代碼修改平穩(wěn)的發(fā)生。當修改一處時不至于影響到另一處，這樣可以縮小維護的代價；(3) 可插入性：容易用一個類替換已經存在的類。只要接口一致，更改實現(xiàn)類不影響類的使用者。 系統(tǒng)設計原則在系統(tǒng)設計階段，分析階段的結果被擴展為一個技術解決方案。新類被加入進來，以提供以下一些技術基礎結構：用戶界面、處理對象存儲的數(shù)據(jù)庫、與其他系統(tǒng)的通信、與系統(tǒng)中各種設備的接口等[7]。設計階段的目標是為待解決系統(tǒng)指定一個可行的技術解決方案，該方案能夠很容易地轉變?yōu)槌绦虼a。在設計階段，不僅會細化那些在分析階段定義的類，還會加入一些新的類，以便處理技術領域的問題，如數(shù)據(jù)庫、用戶界面、通信和設備等[1]。在本系統(tǒng)的設計過程中，應遵循以下原則：(1) 統(tǒng)一各種原始單據(jù)的格式，統(tǒng)一帳目和報表的格式；(2) 刪除不必要的管理冗余，實現(xiàn)管理規(guī)范化、科學化；(3) 界面盡量簡單化，做到實用、方便，滿足企業(yè)不同員工的需要；(4) 系統(tǒng)設計考慮到系統(tǒng)的各種角色，對使用本系統(tǒng)的用戶設計合理的使用權限。設計階段分為兩個部分： 總體設計（Architecture Design）：這是一個高層的設計，包括體系結構設計和總體功能設計，前者用來定義包（子系統(tǒng)），包括包之間的依賴關系和主要的通信機制；后者從功能的角度宏觀設計系統(tǒng)。 詳細設計（Detailed Design）：此部分進一步細化包內的內容，對所有的類都詳盡地進行描述，為編寫代碼的程序員提供一份清晰的規(guī)格說明。同時，可以用UML中的動態(tài)模型來說明對象如何在特定的情況下做出相應的行為。 總體設計 體系結構設計良好的體系結構是一個可擴展和可修改的系統(tǒng)的基礎。在進行體系結構設計時，包可以專注于一個特定的功能領域的處理，或者專注于一個特定的技術領域的處理[1]。本系統(tǒng)中的包，有以下幾個：用戶界面包：該包的內容描述整個用戶界面所使用的類，這些類提供的操作允許用戶查看系統(tǒng)中的數(shù)據(jù)，并允許用戶輸入新數(shù)據(jù)。這些類是基于Java AWT包設計的，后者是Java中用來編寫用戶界面應用程序的一個標準庫。用戶界面包和下面要介紹的業(yè)務對象包合