UML建模方法在高速公路監控系統中的應用
2012-04-12 00:00:00劉勇
現代電子技術 2012年13期
摘要：
為了提高監控系統軟件的設計效率和更好地使用UML進行系統建模，從理論和實踐兩個方面對UML在軟件系統建模方面的應用進行了研究。把整個過程分為全局分析、局部分析、全局設計和局部設計四個階段詳細論述，最后簡要介紹了系統的圖形用戶界面，完成了一個分布式高速公路監控系統的UML分析和設計。
關鍵詞：監控系統; UML; 高速公路; 分布式系統
中圖分類號：
TN71134; TP3
文獻標識碼：A
文章編號：1004373X(2012)13
0187
04
收稿日期：20120301
基金項目：國家“863”計劃項目(2009AA043902)；山東省科技發展計劃項目(2009GG10001011)；濟南青年科技明星計劃項目(20110301)
0引言
以工業PC總線組成的中小規模控制系統，以及由工業控制計算機和單片機構成的分布式控制系統，現在已經在監控系統中占主導地位，因此控制軟件品質就直接影響系統的安全和控制效果，從而進一步影響到控制系統的穩定性和產品的質量。UML在軟件工業中占支配地位的建模語言，并在許多領域的軟件開發中得到應用。本文以某高速公路監控系統為背景，介紹了綜合運用UML、網絡通信技術和相關的操作系統、數據庫、編程語言開發一個開放、可重用和擴展的分布式監控系統的新方法，并在從理論上對基于UML的分析設計方法進行了提煉，并提出了一些建議，為開發類似的系統提供了參考。
本文依托某高速公路監控系統項目。這條高速公路全線長22.7 km， 全線雙向六車道，共有五座互通式立交，一座特大橋，兩座隧道。全線設一個監控中心、若干外場監控點。監控中心統一對全線交通運行實施宏觀管理和調控，協調各監控點的運行，必要時下達控制命令。監控系統主要負責監控外場設備、隧道設備，實現對本路段各種交通系統信息的采集，向道路使用者提供本路段路況的各種信息，以達到監視道路和控制道路的目的，確保本路段交通通暢\\[1\\]。
監控中心實時采集管理區段內的各種數據，包括交通量、速度、占有率、車頭距、氣象、CO/VI檢測值、光強檢測值、火災報警、高位水池水位和事故等，對它們進行實時運算、分析和處理。監控系統具有事故自動檢測功能；交通控制方案自動選擇功能；統計、查詢功能；系統設備檢測功能；協調處理系統內部交通管理業務功能等。還要使用閉路監控系統通過外場攝像機、廣場攝像機、隧道攝像機對重點路段、隧道以及報警收費圖像和其他報警圖像進行實時監視，并且可以對報警信號進行聯動處理。
根據該高速公路的具體情況和當今的技術背景，項目開發小組決定使用面向對象的開發方法，準備采用UML對整個系統進行分析和設計，并使用Rational Rose作為CASE工具。目前國內使用UML進行的軟件建模，通常都是把整個過程分成建立靜態模型和動態模型兩個階段，但這種分析設計模式對自頂向下的設計方法詮釋的仍不夠完美。本文使用了一種新穎的思路，即把整個過程分為全局分析、局部分析、全局設計、局部設計四個部分。
1基于UML的監控系統分析
1.1全局分析
全局分析側重于定義擬建系統所采用的架構以及影響構架的要素。全局分析充分利用以往相似系統或問題中的經驗，避免在確定架構上浪費人力和物力，主要完成選用架構模式和整體功能分析兩項任務。
選用架構模式活動的主要依據是既往的經驗。表面上看，選用架構模式只是在模型中擺放了一個沒有內容的空架子；而實質上，它為所有后續活動設立了一個共有的基礎框架，用以承載逐步演進和累加的設計內容。
高速公路在地理上是分散的，所以必須使用分布式系統來完成對其全程監控。監控系統對實時性、穩定性和易操作性的要求很高，而不需要過于華麗的操作界面，所以采用三層C/S工作模式是最好的選擇。可以用UML的Business Use Case框圖對系統的總體功能進行描述。圖1為系統的Business Use Case框圖。
該系統有五個業務用例，因此可以把其對應劃分為五個包。同時還發現一個業務工人通信系統，業務工人屬于系統，所以也可以把它歸結到一個包中。這樣就把整個系統按功能劃分為六個包，分別命名為RoadMonitor，TunnelMonitor，GraphPacket，VideoMonitor，DataManagePacket，CommPacket。既然已經決定采用分布式系統，那么這六個包初步決定分別作為六個客戶端，分布在六個工作站上。對系統架構確定之后，可以對整個系統的功能進一步整理。因為我們已經按功能劃分了包，這樣就可以分別對每個包的功能進行分析［2］。
整體功能分析可以采用用例模型描述。UML是一種基于用例驅動的建模語言，所以用例模型特別重要。把系統的用例模型所需要的角色和用例都提取出來，即可以繪制出系統的用例圖，視頻監控包的用例圖如圖2所示。但是一個系統并不是用一個用例圖就能分析清楚的，還需要對其他一些備選事件進行用例建模［3］。
1.2局部分析
局部分析以選定的用例作為研究對象，以相對粗大的顆粒，用面向對象的概念和方法對問題進行轉述，為后續以相對細小的顆粒做進一步的設計活動提供必要的鋪墊。局部分析中有不同側重的兩項活動：提取分析類和轉述需求場景［4］。
提取分析類就是對選定的用例進行進一步研究，該活動的基本依據是對全局分析時獲取的用例的理解。分析類用于描述擬建系統中那些較高層次的對象，不必關注某些與應用邏輯不直接相關的細節，特別是那些純粹的軟件技術問題。轉述需求場景活動的主要依據是已經獲取的需求中各個用例描述的需求場景；該活動的結果基于面向對象概念，用UML交互圖，主要是順序圖，來轉述需求場景。順序圖能夠使BCE(BoundaryControlEntity)模型清晰的展現出來［5］。圖3所示的是“監聽并處理路隧報警”用例的順序圖。從圖中可以看出，處理報警的各個步驟都是通過控制類(Listener)發送的各條消息來實現的，從圖中還可以注意到編號為3和4的兩條消息是異步消息。
2基于UML的監控系統設計
2.1全局設計
全局設計的任務是在擬建系統的全局的范圍內，以系統分析活動的結果為出發點，將現有的分析類映射成模型中的設計元素，明確適用于擬建系統的設計機制，調整內容逐步充實擬建系統的架構。全局設計任務的總體思想是從上向下充實層次架構中的內容，然后做貫穿層次的調整。
(1) 確定核心元素
確定核心設計元素，具體講就是確定設計類和子系統接口。確定核心元素活動的主要依據是在多個局部分析活動中得到的分析類集合，也就是說要把分析類映射為核心設計元素。
從概念上講，設計元素是能夠直接用于指導編碼實施的模型元素，但是在本文中推遲了“明確設計類的操作”這一活動，設計元素僅是指由分析類映射而來的設計類和子系統接口。原因是，對于設計類而言，在全局設計任務中，尚且不需要將原有分析類的責任精確地轉換成相應的操作。因為在后續設計活動中，一般的設計類還要經歷很多調整與精化。
(2) 明確組織結構
當設計元素確定了之后，下一步的工作就是把他們分配到系統的各個層次上去。在UML建模中，各個不同的層次表現為各個不同的包。
在全局分析階段我們把系統按功能劃分為六個包，并初步設定這六個包是六個客戶端。經過局部分析階段和進入全局設計階段后，認為這樣的設定基本合理，所以在此明確這六個包為六個客戶端，同處于客戶端層中。全局分析中還確定使用三層C/S工作模式實現該系統，所以還有另外兩個層次應用服務層和數據庫服務層，這兩個層分別定義為兩個包Application Sever和Database Sever。把設計元素分配到系統的各個層次工作并不復雜。一般而言，由邊界類映射而來的設計元素放置在客戶層對應的包中，由控制類映射而來的設計元素放置在應用服務層所對應的包中，由實體類映射而來的設計元素放置在數據庫服務對應的包中。
2.2局部設計
局部設計的任務是基于全局分析和局部分析的框架，利用全局設計提供的素材，精化設計類的屬性和操作，然后在不同的局部，將分析的結果用精化后的設計元素加以替換和落實。
(1) 精化設計類
完成全局設計之后，可以開始對設計類進行精化了。精化設計類就包括兩方面的工作，一是填充類的信息，主要是確定類的屬性和操作；二是找出類之間的關系，繪制出類圖［6］。
尋找類之間的關系有一個很好的直觀依據，就是交互圖。簡單的順序圖能很容易的看出類之間的關系，復雜的順序圖只要慢慢對照，也能了解到各個類之間的關系［7］。例如用圖1所示的“監聽并處理路隧報警”用例的順序圖，可以找出與之相關的類之間的關系，從而繪制出如圖4所示的類圖。被映射成數據庫表格形式的實體類的屬性和類之間的關系也可以通過這種類圖表現出來，從中可以了解到Vidicon，RecordLog，AlarmLog，SiteToVidicon這幾個類的屬性、操作以及它們之間的依賴關系，即一個類元以某種方式依賴于其他類元，但關系不是真正的關聯。
(2) 實現需求場景
實現需求場景活動的基本依據是局部分析任務中得到的用例實現，即用分析類的交互關系轉述的需求場景。該活動的結果是設計意義上的用例實現，主要從兩個方面進行：一方面，用核心設計元素取代分析類；另一方面，充分分析需求場景，加入備選事件的交互關系。
分析類和設計元素的本質區別是有不同的使用目的。分析類針對的是問題描述中的要點，可以在用例事件流描述中找到直接的對應內容；設計元素針對的是解決方案，將作為后續實施活動切實可行的根據。在分析活動中，很多與應用邏輯不直接相關的技術細節可以用概要的方式描述和封裝；在設計活動中，對大多數技術問題應當有一個明確的交代［8］。
在此以“監聽并處理路隧報警”用例為例來說明。首先要繪制出事件流圖，可以用圖5所示的活動圖來表示。下面即可以用順序圖來實現用例描述的需求場景，另一種交互圖協作圖也可以完成同樣的任務。順序圖強調的是交互的時間順序。協作圖強調的是交互的語境和參與交互的對象的整體組織。圖6所示的是“監聽并處理路隧報警”用例在設計階段的協作圖。這個圖可以清楚的表示出各個對象之間的協作關系，TRollAlarmThread類的實例是整個圖的中心，所有其他實例都圍繞著它。如果通過協作圖看到其他實例不是以控制類的實例為中心，就應該對協作進行調節。
3監控系統的實現
在完成分析和設計工作之后，該高速公路監控系統就可以開始部署并實施編碼。組件圖是描述各個組件之間關系的一種圖形。UML中的組件包括源代碼組件、二進制代碼組件和可執行組件或者相應的文檔組件。在該高速公路監控系統中包含了exe文件、dll文件、ini配置文件和電子文檔。組件圖就是要描述這些組件在服務器和客戶端上的分布以及組件之間的關系［9］。圖7為整個系統的組件圖。
圖8是公路監控工作站的主畫面，界面中上部為整條高速公路的地圖(不包括隧道)。
可以通過菜單項中選擇對應的菜單項驅動以便選擇控制查看及統計，通過對地圖上的對應設備進行左鍵單擊選擇對應設備，彈出對應的控制或狀態頁面。對于設備故障報警、路段異常報警和交通其他報警，系統單獨開辟獨立線程自動進行系統查詢。并當相應路段出現異常時可以在界面上得到顯示并設為特定對應顏色居中顯示并提供報警預案。當相應的設備出現故障時，系統自動閃爍該設備從而提醒用戶該設備已故障。對于設備故障報警、路段異常報警和交通其他報警，系統還提供了人工手動報警輸入，為系統提供相當大的自主性［10］。
4結語
本文某高速公路監控系統為背景，使用Rational Rose為建模工具，分析、設計和實現了一個分布式的高速公路監控系統，目前該系統已經交付使用。其中，打破常規的UML動態建模和靜態建模的設計思想，使用一種新穎的思路對系統進行分析和設計是該系統開發的重要前提和關鍵。當然，系統中仍然存在不完善的地方，比如對象的分布設計問題等。不過由于面向對象具有可復用、可擴展的特性，可以在以后的研究中方便的完善其中的不足。
參考文獻
［1］夏創文.基于多媒體技術的高速公路聯網監控調度系統研究與應用［J］.公路交通科技，2011(1):185188.
［2］李立芳.基于多媒體技術的指揮調度系統關鍵技術研究［J］.艦船電子工程，2007(3):6465.
［3］穆振海，張昌年.新型指揮信息管理系統的設計與實現［J］.微計算機信息，2008(6):295296.
［4］余林.多媒體通信的關鍵技術及其發展趨勢［J］.山西科技，2006(6):2931.
［5］GUO Qian， HUANG Lin. Software design and modules development of the expressway tunnel monitoring system \\[C\\]// 4th IEEE Conference on Industrial Electronics and
Applications. Xi’an， China: IEEE， 2009: 965968.
［6］BAUER Bernhard， ODELL James. UML 2.0 and agents: How to build agentbased systems with the new UML standard \\[J\\]. Journal of Engineering Applications of Artificial Intelligence， 2005， 18: 141157.
［7］BERARDI Daniela， CALVANESE Diego， DE GIACOMO Giuseppe. Reasoning on UML class diagrams \\[J\\]. Artificial Intelligence， 2005， 168(1/2): 71118.
［8］BOGER Marko， JECKLE Mario， MUELLER Stefan， et al. Diagram interchange for UML \\[R\\]. \\[S.l.\\]: SpringerVerlag， 2002.
［9］SONG Eunjee， YIN Shuxin， RAY I. Using UML to model relational database operations \\[J\\]. Computer Standards and Interfaces， 2007， 29(3): 343354.
［10］DENG Wenjun， LIANG Yiwen. Reason on UML diagrams with answer set programming \\[C\\]// Proceedings of International Conference on Computer Science and Software Engineering. Washington， DC， USA: IEEE Computer Society， 2008: 205209.
作者簡介：
劉勇 男，1971年出生，山東濟南人，碩士研究生，副教授。主要研究方向為電子信息。
