生產指揮系統建模

何嘉樂

1.引言

航運調度是港口物流企業作業的核心和關鍵，直接關系到公司的生產效率，生產指揮系統模型的好壞直接影響著公司調度指揮系統的設計和實現。UML（UNIFIED MODELING LANGUAGE統一建模語言）是一種面向對象的建模技術，是由世界著名的面向對象技術專家Grady Booch，Jim Rumbaugh和Ivar Jacobson發起的，在Booch方法，OMT方法和OOSE方法的基礎上，幾經修改完成的，它是為工業界所廣泛接受的一種標準建模語言，使用UML表達生產系統的模型，概念明確，建模簡潔，結構清晰，容易被程序員和用戶所理解。PowerDesigner是一種CASE工具，支持數據庫建模和面向對象建模，支持UML中的用例圖、包圖、類圖、活動圖、部署圖、協作圖、組件圖、復合結構圖、對象圖、順序圖、狀態圖等，以描述系統的靜態結構和動態結構，我們選擇它作為UML的建模工具進行生產指揮系統的建模。

2.需求模型

在軟件生命周期中，需求分析是其中一個重要的階段。從軟件工程的角度來說，需求分析的質量對軟件的質量影響是巨大的，在后續階段改正需求分析的錯誤要付出高昂的代價，往往導致軟件的功能不是用戶想要的，而用戶的真正需求卻并未實現。PowerDesigner的RQM是一種實用的需求管理工具，可以記錄用戶需求，定義需求的優先級、工作量、風險，管理需求的狀態。經過與業務人員的溝通，我們確定了系統主要解決三個方面的問題：船舶管理、作業管理、系統接口。其中船舶管理包括船舶資料的登記、預確報管理和船舶動態（靠泊、離泊、移泊）管理;作業管理包含作業計劃、配工和作業線管理;系統接口包括與公司雜貨系統的接口、與公司機務系統的接口以及與集團調度系統的接口。

3.系統模型

我們根據前面的功能劃分，將生產指揮系統分為三個相關的子系統，其中作業管理子系統需要接口管理子系統提供的庫場貨物信息和機械信息，船舶管理子系統為作業管理子系統提供船舶資料和動態信息。

3.1業務簡述

調度綜合計劃員與船代溝通，掌握近日預抵的船的動態，并將船舶信息登記在月度船舶登記表中。船舶到港前，綜合計劃員接到集團調度中心的船舶動態，編制靠泊安排，安排船舶靠泊，在船舶在港期間，如因作業需要實施移泊，應編制移泊安排。單日計劃員根據在港船舶的動態和載貨情況、貨物庫存等信息編制晝夜作業計劃表，交給值班調度。值班調度根據晝夜作業計劃表和當班人機情況，制定班作業配工表，發給裝卸隊和機械隊，并簽發作業票給裝卸隊。作業開始后，值班調度掌握各作業線狀態，作業結束后記錄當班作業量。裝卸隊和機械隊接到班作業配工表后，在配工表上實施“挑勾”，各自分配每個隊組或機械的工作，作業開始后，分別記錄作業線上工人變化情況和機械變化情況。

3.2功能定義

我們根據調度業務過程，界定了生產指揮系統的范圍，確定了系統的功能。從系統的執行者的角度出發，只定義功能的內容和功能分工，并不體現出功能的內部實現，便于被系統的用戶所理解，使得用戶了解自己在系統中的角色。

我們經過分析用例，得到了生產指揮系統的系統功能大致如下：

1）船舶資料管理和登記。包括船舶基本資料的增、刪、改，船舶登記表的維護。

2）船舶動態管理。包括船舶靠泊、移泊、停泊的計劃安排。

3）晝夜計劃。晝夜作業計劃表和裝卸要求的增刪改。

4）作業配工。配工表的制定和發布到裝卸隊、機械隊等單位。

5）作業線狀態管理。包括作業線的開工、待工、復工和完工狀態的維護。

6）日作業實際。當班次作業數據的增刪改。

7）挑勾。裝卸隊和機械隊在配工表上選擇自己承擔的工作，并反饋給值班調度員。

8）作業人員的變更和作業機械的調整。包括補人記錄和機械變更記錄。

9）接口功能。從雜貨系統中取得貨物信息，從集團調度系統中獲取船舶預報信息，從機務系統中得到機械信息。

3.3系統設計

我們使用類圖建立了系統模型的靜態結構，以表達組成系統的類及其相互間的關系，通過類間關系的建立，我們可以清楚地了解系統中對象的結構和所處的層次，及各類的屬性和該類執行的主要操作。

3.3.1設計原則

1、系統類模型建立時應該盡量少地考慮實現。系統模型是業務邏輯的抽象，只體現了業務實體在業務流程中的相互作用關系，模型的實現方式、編碼語言和運行平臺等因素不能影響業務模型的設計，過多地考慮系統的實現會束縛模型的設計，影響模型的質量。

2、設計的目標模型應該盡可能地符合開放封閉原則（Open Closed Principle）。當增加功能需求的時候，可以方便地通過擴充新的類來支持新功能的實現，而不能夠修改原有模型的類和類中的方法以支持新加入的功能。

3、類間的關聯要適度，系統類設計應該遵循迪米特法則（Law of Demeter）。迪米特法則，又稱為最少知識原則（Least Knowledge Principle： LKP），對象與其它對象的了解要盡可能少。這樣做的好處是將大大降低類間的耦合，減少類對其他類的依賴，可以使系統的功能模塊相對獨立，相互間少有依賴關系，使得對于類及類的功能擴展不至于導致模型的大面積修改，使模型穩定而增強健壯性。系統的模塊分解和編碼也應該遵循這一原則。

4、盡可能地復用功能相近的類及其方法，一來可以使模型功能的修改相對容易，修改點少，二可以減少模型中的類，使得模型簡單且易于理解。

3.3.2設計思路

我們從用例出發，逐層分解，先找到在業務模型中所作用的類，再通過分析這些類，將密切聯系的類組織到一起，并分組，標記類間的關聯和類的依賴關系，最后填充類的信息，形成類圖，以描述目標業務系統的模型。

3.3.3建立模型

作用于系統中的類主要有CompPlanner（綜合計劃員）、DailyPlanner（單日計劃員）、Watcher（值班調度員）、Vessel（船）、Cargo（貨）、CarriTeam（裝卸隊）、MechanicalTeam（機械隊）、Workline（作業線）、Dailysheet（晝夜計劃表）、MatchSheet（配工表）、DynamicSheet（動態單）。

4.結束語

本文使用了面向對象方法以描述生產指揮系統的建模過程，以PowerDesigner為建模工具，UML為建模語言建立了生產指揮系統的模型。隨著信息技術的逐步深入，面向對象方法在軟件的分析和設計中所發揮的作用越來越大，面向對象分析和設計可復用、易擴展、結構清晰的優點日益突出，在面向對象思想指導下的軟件開發，會提高軟件的效率和質量，保證軟件的健壯性和可維護性。