[摘要] 統一建模語言UML是一種面向對象的標準建模語言,它融入了軟件工程領域的新思想、新方法和新技術,使用范圍不僅限于支持面向對象的分析與設計,還支持從需求分析開始的軟件開發的全過程。通過對集裝箱管理系統開發過程分析,詳細闡述了UML語言工具在管理系統建模過程中的應用及其對于加速系統開發進程和提高代碼質量的重要性。
[關鍵詞] 統一建模語言 管理系統 建模 應用
一、引言
統一建模語言UML(Unified Modeling Language)是一種用于描述、視化和構架軟件系統以及商業建模的語言。它提供了多種基本的模型圖,并通過對這些圖的綜合運用來全面刻畫整個系統的全貌。UML符號表示法為開發者使用這些圖形符號和文本語法進行系統建模提供了標準,具體可分為5大類,9種圖形。5大類分別是用例圖、靜態圖、行為圖、交互圖和實現圖。靜態圖包括類圖和對象圖,用來描述靜態關系;行為圖包括狀態圖和活動圖,用來描述系統的動態模型和組成對象之間的交互關系;交互圖包括協作圖和順序圖,用來描述對象間的交互關系;實現圖包括組件圖和配置圖,分別用來描述代碼組件的物理結構以及系統中軟硬件的物理體系結構。
二、基于UML 的系統開發過程
UML是一種建模語言而不是方法,UML本身獨立于過程,使用UML進行開發時,仍有統一的過程框架。UML的開發過程是一種柔性開發過程,即在需求牽引下,自頂向下分層細化地建模,然后通過對模型的虛擬執行,由底向上地逐層上移修改,直至各層的模型結果都滿足需求為止。
系統的開發過程包括需求定義、分析、設計、實現幾個階段。需求定義階段建立系統的需求模型,分析階段建立系統的分析模型,這兩個模型是系統設計和實現的基礎。
建立系統需求模型包括:
1.問題陳述。根據用戶初始需求,在用戶幫助下,寫出問題陳述;
2.定義參與者(Actor)。在用戶參與下定義系統的參與者;
3.建立GUI界面原型。在用戶參與下,用可視化編程工具為每個參與者建立GUI界面原型;
4.定義用例。觀察參與者與界面原型的交互過程,導出用例。建立系統分析模型主要包括:
(1)靜態建模。根據問題陳述和用例,對系統的靜態結構建模,靜態模型可以用類圖表示,它概要地描繪了問題域對象類,同時也表示出這些類的基本屬性和類間的關系。
(2)動態建模。根據用例及靜態模型進行動態建模,動態模型可用順序圖、合作圖、狀態圖等表示。動態模型表達了系統的動態特征。
下面以集裝箱管理系統的開發實例闡述如何利用UML 建立系統的需求模型和分析模型。
三、建立CFS 業務信息系統的需求模型
1.問題描述
CFS是集裝箱貨運站(CONTAINER FREIGHT STATION)的縮寫,是處理拼箱貨的場所,它的主要業務分成兩大塊,即進口貨拆箱業務和出口貨裝箱業務。在進口貨拆箱業務中,貨主或其代理先將記錄著集裝箱裝貨信息的箱單送到貨運站,申明有重箱(即裝有進口貨的集裝箱)要送來拆箱。在其后的某一時間,重箱由某車隊送到貨運站,貨運站馬上根據箱單進行拆箱操作,通常,拆出的貨物還要放入倉庫的跺位中,空箱子由車隊及時拉走送到另外的堆箱場地(即集裝箱堆場)。以后,收貨人來提貨時貨運站再從跺位中取出貨物交給收貨人。在出口貨裝箱業務中,貨主或其代理先發出裝箱委托(假定都是整箱貨委托)。其后,貨到時,就將貨放入分配給該委托單位的垛位。此后的某一時間,進行配積載并實施裝箱。最后,重箱交給車隊送往港區。由于拆裝箱是貨運站的主要業務,倉庫存放貨物是輔助性動作,為了加快周轉,在貨運站倉庫堆放貨物,有個免費倉期問題。
2.參與者與用例分析
首先,確定了系統的兩個參與者(Actor),即倉庫管理員和倉庫主管。通過為他們建立系統界面原型,觀察他們與界面交互的過程,可以分析出每個參與者使用的用例。所謂用例就是參與者與系統的一次對話中所執行的一系列相關事務序列。系統中各用例間及用例和參與者間的關系可由例圖表示,本系統的用例圖(部分)如圖1所示。
用例圖只是表達了用例間及用例和參與者間的關系,我們還必須文檔化每個用例的具體內容。集裝箱貨運站系統各用例描述如下:
(1)拆箱受理。倉庫管理員收到客戶拆箱委托時執行本用例。①倉庫管理員創建新的拆箱委托單;②倉庫管理員填寫委托信息。如發貨人和收貨人名稱、提單號、箱號、受理日期、計劃拆箱日期、貨物信息(包括貨類、貨物描述、數量、單位等)。系統自動生成委托號。③系統標記委托單狀態為“受理”。
(2)重箱進場。本用例從客戶將重箱送進場時開始。①倉庫管理員調出拆箱委托單,輸入重箱進場日期;②系統標記委托單狀態為“已進場”。
(3)預分配垛位。倉庫管理員受理拆箱委托后,可以根據情況在重箱進場前或重箱進場后但尚未拆箱時為該筆委托單預分配一個垛位。①倉庫管理員查詢垛位狀態圖;②倉庫管理員為拆箱委托單預分配一個空垛位;③系統標記該垛位為“鎖定”狀態;④系統標記委托單狀態為“預分配”。若分配的垛位不處于“空閑”狀態,則系統拒絕接受預分配垛位操作。
(4)拆箱入垛。在已為拆箱委托單預分配垛位并且重箱進場后,可以執行拆箱入垛用例。①倉庫管理員調出拆箱委托單;②倉庫管理員執行拆箱入垛操作;③系統標記該垛位為“占用”狀態;④系統標記委托單狀態為“已入垛”。
(5)貨物交出。當將垛位的貨物提出交給客戶時,執行本用例。①倉庫管理員調出拆箱委托單,執行貨物交出操作,輸入交貨日期;②系統標記該垛位為“空閑”狀態;③系統標記委托單狀態為“已交貨”。以上為進口拆箱業務用到的用例。出口裝箱業務用到的用例包括如下幾個用例(為簡明起見,不再詳細描述各用例的具體內容)。
(6)裝箱受理。倉庫管理員收到客戶裝箱委托時執行本用例。
(7)預分配垛位。倉庫管理員根據情況在適當時間為該筆裝箱委托單預分配一個垛位。若分配的垛位不處于“空閑”狀態,則系統拒絕接受預分配垛位操作。
(8)收貨入垛。倉庫管理員收到客戶的貨物并且已為裝箱委托單預分配一個垛位后執行收貨入垛用例。
(9)裝箱。貨物從垛位提出裝箱時執行裝箱用例。
(10)重箱交接。將裝好的重箱交給客戶時執行本用例。以上為出口裝箱業務用到的用例。下面是幾個查詢用例。
(11)垛位查詢。①倉庫管理員向系統查詢垛位狀態;②系統顯示垛位狀態。
(12)庫存貨狀態查詢。①倉庫主管要求查詢倉期超過一個月的委托單;②系統顯示滿足條件的委托單。
(13)客戶裝、拆箱數查詢。①倉庫主管要求查詢某客戶某段時期內的裝、拆箱數;②系統顯示查詢結果。
這里要著重說明的是,描述用例時,最好不要包含界面實現細節方面的詞匯。如“用戶在列表框中選擇收貨人”,這句話中的“列表框”就表達了界面實現細節,因而不是好的描述方法。之所以要強調描述用例時不要包含界面實現細節,是因為在初始的需求分析階段,構造的界面原型只是一個草稿,我們僅僅用它來方便用例的導出。而最終用于實現用例的界面要做進一步的優化和調整,它們可能和初始界面原型很不相同。如果在用例中過多描述跟初始界面原型相關的實現細節,就會大大限制設計人員設計最終用戶界面的創造性,從而無法設計出最優的最終用戶界面。以上問題陳述、參與者、GUI界面原型和用例一起構成了系統的需求模型。
四、建立CFS 業務信息系統的分析模型
完成需求定義,得到需求模型后,下一步進入系統分析階段。分析階段的主要任務是構造系統的分析模型,該模型主要包括靜態模型(用類圖表示) 和動態模型(用順序圖、合作圖、狀態圖等表示) 。
首先,可以根據問題描述及用例,通過詞法分析,提煉出系統的對象,進而畫出類圖,用以表示系統靜態模型。尋找對象的基本規則是名詞和名詞詞組成為候選對象,動詞是對象的服務,形容詞可能暗示存在子類。當然,由于自然語義并不十分精確,所以不能機械地套用基本規則,還須做進一步的分析與調整。本系統的類圖模型如圖2所示。
該圖中,三角形符號表示父類與子類聯系,棱形表示聚集聯系,連線代表一般聯系。連線邊的標注表明該端對象在該聯系中扮演的角色,如客戶在與委托單的聯系中扮演發貨人角色(適用于任一子類) ,在與拆箱委托單的聯系中扮演收貨人角色(僅適用于拆箱委托單) 。各對象類的主要屬性已標注在類中,但對象的服務沒有全部標出。建立對象模型后,為了表達系統的動態特征,可以建立系統的動態模型。動態模型可用順序圖、合作圖、狀態圖表示。本系統選擇順序圖和狀態圖。
理論上說,我們可以為每個用例開發一個順序圖,但實際上,通常可以省略那些過于簡單的用例的順序圖。順序圖表達了參與一個用例的幾個對象協同工作的行為。這里,給出本集裝箱貨運站系統中為拆箱委托單預分配垛位用例的順序圖(如圖3) 。
順序圖適于表達一個用例中幾個對象的交互行為,若想表達跨越多個用例的單個對象的行為,可以使用狀態圖。同樣,我們也不必為每個對象開發狀態圖,而只須為關鍵的對象和具有復雜狀態的對象開發狀態圖。這里,給出“拆箱委托單”和“垛位”的狀態圖見圖4。
完成了順序圖和狀態圖后,可據此研究對象間的消息傳遞,從而進一步修訂、精化類圖,為類添加服務。例如在“拆箱委托單預分配垛位順序圖”中,事件“預分配垛位”成為委托單類的“預分配垛位”服務;事件“驗證可用性”成為垛位類的“檢查垛位狀態”服務,事件“鎖定垛位”成為垛位類的“設置垛位狀態”服務。這樣,最終的類圖、順序圖、狀態圖和模型詞典共同構成了分析模型。此后,在系統設計階段,可以根據類圖設計數據庫,根據界面原型設計界面對象,根據數據訪問要求設計數據服務層對象。進而,擴展原來的類圖,讓它包含界面對象和數據服務層對象。最終,在系統實現階段,把各層對象組裝起來,形成完整的應用程序。
五、結語
通過集裝箱管理系統的開發過程看到,UML是一種面向對象、可視化的系統分析建模語言,它支持從需求描述開始的軟件開發全過程。采用UML語言進行系統建模分析和設計,解決了領域專家、軟件設計人員和客戶之間交流的難題,使用它的圖形元素便于開發人員更好地理解業務流程,建立更為完善的系統模型,使用戶和開發者對問題的描述理解達成一致,排除語義差異,提高分析的正確性,從而加速了開發的進程,保障了系統的開發質量。
參考文獻:
[1]劉光明陳煉馬永生:基于UML需求分析技術的應用研究[J].科技廣場, 2005,(03)
[2]馮玲玲沈軼:基于UML的需求分析與建模[J].科學技術與工程, 2005,(09)
[3]徐憲武劉永泰:UML與RUP在科技項目評審系統中的應用[J].電腦開發與應用, 2005,(07)
[4]王森:基于UML的人力資源管理系統建模研究[J].電腦知識與技術, 2005,(17)
[5]吳保艷賴永凱:UML在倉庫管理系統中的應用[J].電腦知識與技術, 2005,(17)