基于UML的校園一卡通管理系統(tǒng)的分析與設計
文章出處：http://m.botanicstilllife.com 作者：蘇州大學 段培同 徐州師范大學 王宜懷 人氣： 發(fā)表時間：2011年11月11日
面向?qū)ο蟪绦蛟O計提出了一種新的系統(tǒng)設計模型，它將系統(tǒng)看成通過交互作用來完成任務的對象的集合，每個對象用自己的方法管理數(shù)據(jù)。本文將結合"一卡通"管理系統(tǒng)的分析與設計過程來闡述面向?qū)ο蠓椒▽W的思想以及統(tǒng)一建模語言UML 中的具體應用。
1 統(tǒng)一建模語言(UML)概述
統(tǒng)一建模語言(Unified Modeling Language , UML) 是一個通用的面向?qū)ο蟮目梢暬ＵZ言，它主要是用于對軟件進行描述、可視化處理、構造和建立軟件系統(tǒng)制品的文檔。它造用于對任何具有靜態(tài)結構和動態(tài)行為的系統(tǒng)進行面向?qū)ο蟮慕！Ｆ渲徐o態(tài)結構定義了系統(tǒng)中的重要對象的屬性和操作以及這些對象之間的相互關系，而動態(tài)行為定義了對象的時間特性和對象為完成目標而相互進行通信的機制。標準建模語言UML 的主要內(nèi)容也可以歸納為靜態(tài)建模機制和動態(tài)建模機制兩大類[1 。2] 從應用的角度看，當采用面向?qū)ο蠹夹g設計系統(tǒng)時，首先是描述需求，其次根據(jù)需求建立系統(tǒng)的靜態(tài)模型，以構造系統(tǒng)的結構，第三步是描述系統(tǒng)的行為。其中在第一步與第二步中所建立的模型都是靜態(tài)的，包括用例圖、類圖〈包含包〉、對象圖、組件圖和配置圖等五個圖形，是標準建模語言UML 的靜態(tài)建模機制。其中第三步中所建立的模型或者可以執(zhí)行，或者表示執(zhí)行時的時序狀態(tài)或交互系，它包括狀態(tài)圖、活動圖、順序圖和合作圖等四個圖形。
2 "校園一卡通"管理系統(tǒng)的面向?qū)ο蠓治龊蚒ML 建模
2.1 系統(tǒng)概述
"校園一卡通"系統(tǒng)就采用現(xiàn)代信息識別技術(如感應式智能卡式讀寫技術〉和自動控制技術的計算機網(wǎng)絡系統(tǒng)。每個消費者都有一張儲值卡，在管理中心注冊繳費，卡內(nèi)記載著消費者的身份、賬戶金額。管理中心計算機上也有相同記錄。消費時，消費者將儲值卡插入窗口機，窗口機自動顯示卡上金額(如遇空卡、偽卡、掛失卡則自動報警)。服務員按窗口機上數(shù)字鍵，窗口機自動計算并顯示消費額及余額(如遇超支則報警)。管理中心可隨時監(jiān)視每一筆消費。管理中心的計算機可以打印出消費情況的各種相關統(tǒng)計數(shù)據(jù)，如食堂的每個窗口的就餐人次，銷售額等。
2.2 校園一卡通系統(tǒng)靜態(tài)建模
2.2.1 建立用例視圖。本系統(tǒng)主要由三個二元關聯(lián)類的事項組成，即消費者與系統(tǒng)服務器之間的卡的管理事項，儲值卡與收款機之間的消費事項，以及系統(tǒng)服務器與服務員的結算事項。整個系統(tǒng)參與者是消費者、管理員和服務員。用例視圖如圖1 所示。
2.2.2 發(fā)現(xiàn)對象，找出對象類，描述類的屬性與服務，建立類圖。對這個系統(tǒng)而言，在系統(tǒng)邊界以外與系統(tǒng)進行交互的活動者是管理員、服務員和消費者，考慮系統(tǒng)問題域和系統(tǒng)責任可以發(fā)現(xiàn)下述對象z：收款機(POS) :該對象直接與系統(tǒng)聯(lián)系，模擬服務員的登錄系統(tǒng)、收款等行為。系統(tǒng)服務器(Sys) :此類對象直接與系統(tǒng)進行交互，與消費者、服務組進行業(yè)務聯(lián)系，該類對象直接操作系統(tǒng)主程序。儲值卡(Card) :代表消費者與系統(tǒng)和收款機進行交互，模擬消費者進行充值、消費等活動。消費事項(XF): 消費者在某服務窗口進行一組消費，通過服務員連續(xù)操作POS 完成收款活動，就稱為一次消費事件。經(jīng)營結算事項(JY) :對每一個服務組所有消費事件的數(shù)據(jù)按日志進行匯總，從而實現(xiàn)服務中心與服務組的結算?？ǖ墓芾硎马?Card Manager): 此類事件主要是管理卡的注冊、發(fā)放、充值、掛失、注銷工作。消費日志(Daily Log): 為提供消費清單查詢和經(jīng)營結算等行為進行實時監(jiān)控提供詳細的記錄，需要系統(tǒng)有實時日志。考慮到未來經(jīng)營窗口的變更，比如窗口收款機的進一步擴充，并以關聯(lián)類和集合管理器為核心設計樣式。它將來有不同的"經(jīng)紀" (Agent) 是一個抽象類，包括新入網(wǎng)(net) 收款機(POS) 等。根據(jù)以上描述，可以發(fā)現(xiàn)該系統(tǒng)中有七個類，類的屬性及服務見表1。系統(tǒng)中，系統(tǒng)服務器處于主動位置，它管理相關的事項和其它類，其中卡與卡的管理構成一個整體一部分結構，這里沒有一般和特殊結構，這個系統(tǒng)中沒有實例連接關系。以上完成了"校園一卡通"系統(tǒng)的靜態(tài)模型分析，下面對它進行動態(tài)分析。
2.3 動態(tài)分析
2.3.1 順序圖。以事項為分析對象，考慮每個事項的個案詳細情況。用序列圖對消費事項個案進行更為詳細的描述，詳見順序圖2。
2.3.2 狀態(tài)機視圖。狀態(tài)機視圖是一個類對象所可能經(jīng)歷的所有歷程的模型。每個狀態(tài)對一個對象在其生命期中滿足某種條件的一個時間段建模。當一個事件發(fā)生時，它會觸發(fā)狀態(tài)間的轉(zhuǎn)換，導致對象從一種狀態(tài)轉(zhuǎn)化到另一新的。本系統(tǒng)中類的狀態(tài)轉(zhuǎn)換較為容易，這里僅給出卡的管理事項中的卡掛失的狀態(tài)圖，如圖3 所示。
2.3.3 活動視圖?；顒訄D是狀態(tài)機的一個變體，用來描述執(zhí)行算法的工作流程中涉及的活動。活動狀態(tài)代表了一個活動：一個工作流步驟或一個操作的執(zhí)行。活動視圖描述了一組順序的或并發(fā)的活動。活動視圖用活動圖來體現(xiàn)。本系統(tǒng)的卡的管理活動圖，如圖4 所示。
2.3.4 物理視圖。實現(xiàn)視圖為系統(tǒng)的構件建模一構件即構造應用的軟件單元-還包括各構件間的依賴關系，以便通過這些依賴關系來估計對系統(tǒng)構件的修改給系統(tǒng)可能帶來的影響。本系統(tǒng)的物理視圖可用下列構件圖圖5 表示。
2.3.5 部署視圖。描述位于節(jié)點實例上的運行構件實例的安排。節(jié)點是一組運行資源，如計算機、設備或存儲器等，部署視圖用部署圖來表達。圖6 表示了系統(tǒng)中的各構件和每個節(jié)點包含的構件。
3 結束語
統(tǒng)一建模語言UML的出現(xiàn)為信息系統(tǒng)建模與設計提供了有力工具。利用基于UML的可視化的建模軟件工具，我們可以按照RUP 的要求方便的管理項目需求、使用基于組件的框架、驗證軟件質(zhì)量、控制版本更新，從而實現(xiàn)整個軟件系統(tǒng)的面向?qū)ο蟮姆治?、設計與迭代開發(fā)。這一技術的深入普及與應用必將對我國軟件產(chǎn)業(yè)的發(fā)展產(chǎn)生非常積極的推動作用，
