徐源清 肖躍軍 中國礦業(yè)大學力學與建筑工程學院,江蘇 徐州 221116
基于UML的索賠信息系統(tǒng)功能分析
徐源清 肖躍軍 中國礦業(yè)大學力學與建筑工程學院,江蘇 徐州 221116
從建筑承包商的角度來看,索賠過程中的信息溝通和搜集、索賠決策的準確性對其索賠工作十分重要。文章基于UML這樣一種通用的統(tǒng)一建模語言對索賠信息系統(tǒng)進行了首要的功能分析。具體實現(xiàn)了功能分析中用例圖分析和類圖分析的全過程。
UML;索賠;信息系統(tǒng);用例
對建筑工程承包商來講,索賠是指由于外界干擾造成了非承包商負責的工期延長和成本增加,從而向?qū)Ψ教岢龅馁r償要求。索賠是建筑工程項目管理中綜合性很強的工作,它涉及施工組織、施工技術、預算(估價)、合同等各個方面。這些方面體現(xiàn)出的索賠問題,如成本的增加、工期的延誤、合同糾紛等使得項目組織的信息溝通和工程師的輔助決策變得至關重要[1]。如能設計一個工程索賠信息系統(tǒng),幫助承包商把握各種索賠相關信息,分析與處理這些信息,做好決策,就能節(jié)約承包商人力與時間,降低管理費用,減少不必要的損失,從而提高效率。
UML(Unified Modeling Language,統(tǒng)一建模語言)是一種圖形化的軟件建模語言[1]。UML的目標之一就是為軟件開發(fā)團隊提供標準、通用的設計語言來開發(fā)和構建計算機應用。軟件項目開發(fā)團隊的相關人員可以能夠共享閱讀和交流系統(tǒng)架構和設計規(guī)劃,就像建筑工人多年來所使用的建筑設計圖一樣。
UML與程序設計語言無關,可以用任何程序設計語言來實現(xiàn)[2],并且它是圖形化的語言,非常容易理解。
索賠信息系統(tǒng)的功能分析主要從兩個方面來講述:首先列出系統(tǒng)需要實現(xiàn)的主要功能點,以用例圖的方式加以描述,針對每個用例圖給出具體的用例描述;然后分析出系統(tǒng)功能所需的主要類,對類與類之間的關系進行區(qū)分,針對分析出的相關聯(lián)的類給出類圖描述。
2.1 主要功能:
2.1.1 系統(tǒng)管理 對使用本系統(tǒng)的人員進行分類、分權限的管理控制;對本系統(tǒng)所用到的數(shù)據(jù)進行備份維護。比如人才機數(shù)據(jù)的維護,證據(jù)、案例數(shù)據(jù)的維護等;
2.1.2 工程信息管理 對工程的概況、工程參與各方等與索賠可能有關的工程信息進行輸入和維護;
2.1.3 索賠日常管理 對索賠從事件描述、干擾事件分析、合同條款分析、工期索賠計算到費用索賠計算進行連續(xù)的可缺省的管理;
2.1.4 索賠文檔管理 對索賠的證據(jù)和案例進行搜集和查詢,并對索賠日常管理提供依據(jù);
2.1.5 索賠報表管理 對索賠日常管理和決策管理的成果進行報表設計,得出索賠意向書,索賠報告等;
2.1.6 幫助 對本軟件的使用,特別是索賠操作流程提供使用說明。
2.2 用例圖
2.2.1 用例圖分析
用例圖由參與者(Actor)、用例(Use Case)、系統(tǒng)邊界和關系組成。
參與者:是指系統(tǒng)以外的,在使用系統(tǒng)或與系統(tǒng)交互的過程中所扮演的角色。索賠信息系統(tǒng)中,參與者可以有承包商、發(fā)包商、監(jiān)理方等。由于本文從建筑工程承包商的角度考慮,所以參與者為承包商。
用例:對包括變量在內(nèi)的一組動作序列的描述,系統(tǒng)執(zhí)行這些動作,并產(chǎn)生傳遞特定參與者價值的可觀察結果。用例就是參與者想要系統(tǒng)做的事情。
系統(tǒng)邊界:用來表示正在建模的系統(tǒng)的邊界。邊界內(nèi)表示系統(tǒng)的組成部分,邊界外表示系統(tǒng)外部。參與者在邊界的外面,用例在邊界的里面。
關系:用例圖中的關系包括用例之間的關系、角色之間的關系以及用例和角色之間的關系。這些關系大致可分為3種:
⑴通信關系,如圖1中的參與者承包商與用例“索賠日常管理”之間的連接就是通信關系,通信關系只能存在于參與者與用例之間;
⑵使用(uses)關系或包含(includes)關系,它表示一個用例包含了另外的用例,如圖1中“索賠日常管理”的功能需要使用“索賠事件描述”這個子用例;
⑶擴展(extends)關系,它表示一個用例在另一個用例的基礎上增加某些功能可以完成一個新的功能,如圖1中的“網(wǎng)絡工期分析”用例就是在已有用例“索賠工期計算”的基礎上新增某些功能來完成的。
圖1 索賠信息系統(tǒng)用例圖
圖1所示的用例圖雖然描述了系統(tǒng)所需要完成的功能,但其描述非常簡單,為了對其進行進一步的說明,下面使用用例規(guī)范對幾個用例進行詳細的描述。為了便于文檔的跟蹤,對圖1的用例進行了編號,如表1所示。
表1 用例清單
2.2.3 用例描述
用例表清單中詳細列出了索賠信息系統(tǒng)所需要的全部用例表,筆者選取了工期索賠計算的用例進行了詳細描述,如表2 所示。
2.3 類圖
2.3.1 類圖分析
類圖通常包含類、接口、協(xié)作和關系,而其中最基本的元素是類或接口。
⑴類:一般包含3個組成部分,分別為類名、屬性和該類提供的方法。
“呼!總算擺脫了那可惡的家伙!”男孩躲在一條長椅后面,一手抓著扶手,一手拍著胸脯,露出半個腦袋觀察周圍的情況,目光不知不覺落在了巷子口那個老爺爺身上。
⑵接口:接口是一系列操作的集合,它指定了一個類所提供的服務。
⑶關系:常見的關系有一般關系、關聯(lián)關系、聚合關系、合成關系和依賴關系。
一般關系:表現(xiàn)為類與類之間、接口與接口之間的繼承關系、類與接口之間的實現(xiàn)關系。在索賠信息系統(tǒng)中,一般關系非常普遍。圖2中UserInfo和Adminer分別代表了索賠信息系統(tǒng)的使用者的基本信息和使用者中的領導層的基本信息,這兩個類就是一般關系,即領導層基本信息繼承了所有使用者的基本信息。
表2 工期索賠計算用例
圖2 一般關系類圖
關聯(lián)關系:類與類之間的連接,它使一個類知道另一個類的屬性和方法。例如:索賠信息系統(tǒng)中在進行由工期拖延所造成的人工費索賠計算時,需要知道工期索賠計算的屬性,如圖3~4兩個類圖的關系就屬于關聯(lián)關系。
圖3 關聯(lián)關系類圖
聚合關系:關聯(lián)關系的一種,是較強的關聯(lián)關系,強調(diào)的是整體和個體的關系。關聯(lián)關系的兩個類處于同一層次上,聚合關系的兩個類處于不同的層次上,一個是整體,一個是部分。
依賴關系:類與類之間的連接,表示一個類依賴于另一個類的定義。例如,如果A依賴于B,則B體現(xiàn)為局部變量、方法的參數(shù)或靜態(tài)方法的調(diào)用。
2.3.2 類圖設計
索賠信息管理系統(tǒng)主要采用3層架構設計。類主要分為3種:
⑴界面設計類,以Frm前綴開頭,用來設計軟件的界面;
⑵數(shù)據(jù)實體類,以M前綴開頭,后面跟數(shù)據(jù)庫表的名稱,將數(shù)據(jù)庫設計為一個模型實體;
⑶業(yè)務邏輯類,以B開頭,后面也是以表的名稱來命名,業(yè)務邏輯類用來完成數(shù)據(jù)的存取操作。
類的設計基本采用這樣的流程:首先根據(jù)界面上用戶的輸入的信息生成實體類,然后在界面類中生成業(yè)務邏輯對象,再調(diào)用業(yè)務邏輯對象提供的辦法,以實體類為參數(shù),完成數(shù)據(jù)的管理功能。
2.3.3 類圖描述
由于索賠方式多樣性、索賠參與方的對立性、工程實際的復雜性,導致對索賠信息系統(tǒng)的功能分析也是比較復雜和難以定性的。本文只對索賠信息系統(tǒng)中的人工費索賠計算模塊的類圖進行詳細的描述,如圖4,以期闡明類圖在分析索賠信息系統(tǒng)功能時的特點和優(yōu)勢。人工費索賠計算由用戶在FrmLabourCost窗體上實現(xiàn)可視化簡明操作,通過BLabourCost對用戶輸入的數(shù)據(jù)進行計算、存儲、修改、刪除操作,并在M L a b o u r C o s t和MLabourMethodCost進行信息的實體化。在日常索賠工作中人工費的索賠計算可能由多種方法或項目,所以每一個MLabourMethodCost是MLabourCost中的一個組成部分。
圖4 人工費索賠計算模塊類圖
UML技術的優(yōu)勢還體現(xiàn)在有強大的工具支持,例如Microsoft公司開發(fā)的Visio辦公產(chǎn)品正是對UML建模圖形化的最大保障,內(nèi)置了與程序接口的各類UML功能圖的繪制功能。這也將大大極高UML技術在初步功能分析時的可推廣性和適應性。本文所有UML類圖都是通過Visio工具繪制。
筆者以上過程基本完成了索賠信息系統(tǒng)的功能分析,這是基于UML建模的第一步,也是提綱性的一步。用例圖和類圖的分析及設計對索賠信息系統(tǒng)的框架的形成起到了重要作用,也對索賠信息系統(tǒng)的功能進行了徹底的剖析。之后的序列圖、狀態(tài)圖的分析,以及數(shù)據(jù)庫設計和代碼設計等項目的具體實現(xiàn)是一步步展開,一步步詳細設計的過程,從而完成UML建模到發(fā)布軟件的全過程。
[1]成虎,許沛.工程索賠決策支持系統(tǒng)的研究[J].系統(tǒng)工程理論與實踐,1997,(10):4~9
[2]王哲.建設工程索賠管理信息系統(tǒng)研究[D].武漢理工大學大學碩士學位論文,2004
10.3969/j.issn.1001-8972.2012.03.034