基于UML的校園一卡通管理系統(tǒng)的分析與設(shè)計

文章出處：http://m.compasssalessolutions.com 作者：蘇州大學(xué) 段培同 徐州師范大學(xué) 王宜懷   人氣： 發(fā)表時間：2011年11月11日

    面向?qū)ο蟪绦蛟O(shè)計提出了一種新的系統(tǒng)設(shè)計模型，它將系統(tǒng)看成通過交互作用來完成任務(wù)的對象的集合，每個對象用自己的方法管理數(shù)據(jù)。本文將結(jié)合"一卡通"管理系統(tǒng)的分析與設(shè)計過程來闡述面向?qū)ο蠓椒▽W(xué)的思想以及統(tǒng)一建模語言UML 中的具體應(yīng)用。

    1 統(tǒng)一建模語言(UML)概述

    統(tǒng)一建模語言(Unified Modeling Language , UML) 是一個通用的面向?qū)ο蟮目梢暬ＵZ言，它主要是用于對軟件進行描述、可視化處理、構(gòu)造和建立軟件系統(tǒng)制品的文檔。它造用于對任何具有靜態(tài)結(jié)構(gòu)和動態(tài)行為的系統(tǒng)進行面向?qū)ο蟮慕！Ｆ渲徐o態(tài)結(jié)構(gòu)定義了系統(tǒng)中的重要對象的屬性和操作以及這些對象之間的相互關(guān)系，而動態(tài)行為定義了對象的時間特性和對象為完成目標(biāo)而相互進行通信的機制。標(biāo)準(zhǔn)建模語言UML 的主要內(nèi)容也可以歸納為靜態(tài)建模機制和動態(tài)建模機制兩大類[1 。2] 從應(yīng)用的角度看，當(dāng)采用面向?qū)ο蠹夹g(shù)設(shè)計系統(tǒng)時，首先是描述需求，其次根據(jù)需求建立系統(tǒng)的靜態(tài)模型，以構(gòu)造系統(tǒng)的結(jié)構(gòu)，第三步是描述系統(tǒng)的行為。其中在第一步與第二步中所建立的模型都是靜態(tài)的，包括用例圖、類圖〈包含包〉、對象圖、組件圖和配置圖等五個圖形，是標(biāo)準(zhǔn)建模語言UML 的靜態(tài)建模機制。其中第三步中所建立的模型或者可以執(zhí)行，或者表示執(zhí)行時的時序狀態(tài)或交互系，它包括狀態(tài)圖、活動圖、順序圖和合作圖等四個圖形。

    2 "校園一卡通"管理系統(tǒng)的面向?qū)ο蠓治龊蚒ML 建模

    2.1 系統(tǒng)概述

    "校園一卡通"系統(tǒng)就采用現(xiàn)代信息識別技術(shù)(如感應(yīng)式智能卡式讀寫技術(shù)〉和自動控制技術(shù)的計算機網(wǎng)絡(luò)系統(tǒng)。每個消費者都有一張儲值卡，在管理中心注冊繳費，卡內(nèi)記載著消費者的身份、賬戶金額。管理中心計算機上也有相同記錄。消費時，消費者將儲值卡插入窗口機，窗口機自動顯示卡上金額(如遇空卡、偽卡、掛失卡則自動報警)。服務(wù)員按窗口機上數(shù)字鍵，窗口機自動計算并顯示消費額及余額(如遇超支則報警)。管理中心可隨時監(jiān)視每一筆消費。管理中心的計算機可以打印出消費情況的各種相關(guān)統(tǒng)計數(shù)據(jù)，如食堂的每個窗口的就餐人次，銷售額等。

    2.2 校園一卡通系統(tǒng)靜態(tài)建模

    2.2.1 建立用例視圖。本系統(tǒng)主要由三個二元關(guān)聯(lián)類的事項組成，即消費者與系統(tǒng)服務(wù)器之間的卡的管理事項，儲值卡與收款機之間的消費事項，以及系統(tǒng)服務(wù)器與服務(wù)員的結(jié)算事項。整個系統(tǒng)參與者是消費者、管理員和服務(wù)員。用例視圖如圖1 所示。

    2.2.2 發(fā)現(xiàn)對象，找出對象類，描述類的屬性與服務(wù)，建立類圖。對這個系統(tǒng)而言，在系統(tǒng)邊界以外與系統(tǒng)進行交互的活動者是管理員、服務(wù)員和消費者，考慮系統(tǒng)問題域和系統(tǒng)責(zé)任可以發(fā)現(xiàn)下述對象z：收款機(POS) :該對象直接與系統(tǒng)聯(lián)系，模擬服務(wù)員的登錄系統(tǒng)、收款等行為。系統(tǒng)服務(wù)器(Sys) :此類對象直接與系統(tǒng)進行交互，與消費者、服務(wù)組進行業(yè)務(wù)聯(lián)系，該類對象直接操作系統(tǒng)主程序。儲值卡(Card) :代表消費者與系統(tǒng)和收款機進行交互，模擬消費者進行充值、消費等活動。消費事項(XF): 消費者在某服務(wù)窗口進行一組消費，通過服務(wù)員連續(xù)操作POS 完成收款活動，就稱為一次消費事件。經(jīng)營結(jié)算事項(JY) :對每一個服務(wù)組所有消費事件的數(shù)據(jù)按日志進行匯總，從而實現(xiàn)服務(wù)中心與服務(wù)組的結(jié)算?？ǖ墓芾硎马?Card Manager): 此類事件主要是管理卡的注冊、發(fā)放、充值、掛失、注銷工作。消費日志(Daily Log): 為提供消費清單查詢和經(jīng)營結(jié)算等行為進行實時監(jiān)控提供詳細的記錄，需要系統(tǒng)有實時日志?？紤]到未來經(jīng)營窗口的變更，比如窗口收款機的進一步擴充，并以關(guān)聯(lián)類和集合管理器為核心設(shè)計樣式。它將來有不同的"經(jīng)紀(jì)" (Agent) 是一個抽象類，包括新入網(wǎng)(net) 收款機(POS) 等。根據(jù)以上描述，可以發(fā)現(xiàn)該系統(tǒng)中有七個類，類的屬性及服務(wù)見表1。系統(tǒng)中，系統(tǒng)服務(wù)器處于主動位置，它管理相關(guān)的事項和其它類，其中卡與卡的管理構(gòu)成一個整體一部分結(jié)構(gòu)，這里沒有一般和特殊結(jié)構(gòu)，這個系統(tǒng)中沒有實例連接關(guān)系。以上完成了"校園一卡通"系統(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)對一個對象在其生命期中滿足某種條件的一個時間段建模。當(dāng)一個事件發(fā)生時，它會觸發(fā)狀態(tài)間的轉(zhuǎn)換，導(dǎo)致對象從一種狀態(tài)轉(zhuǎn)化到另一新的。本系統(tǒng)中類的狀態(tài)轉(zhuǎn)換較為容易，這里僅給出卡的管理事項中的卡掛失的狀態(tài)圖，如圖3 所示。

    2.3.3 活動視圖?；顒訄D是狀態(tài)機的一個變體，用來描述執(zhí)行算法的工作流程中涉及的活動?；顒訝顟B(tài)代表了一個活動：一個工作流步驟或一個操作的執(zhí)行。活動視圖描述了一組順序的或并發(fā)的活動。活動視圖用活動圖來體現(xiàn)。本系統(tǒng)的卡的管理活動圖，如圖4 所示。

    2.3.4 物理視圖。實現(xiàn)視圖為系統(tǒng)的構(gòu)件建模一構(gòu)件即構(gòu)造應(yīng)用的軟件單元-還包括各構(gòu)件間的依賴關(guān)系，以便通過這些依賴關(guān)系來估計對系統(tǒng)構(gòu)件的修改給系統(tǒng)可能帶來的影響。本系統(tǒng)的物理視圖可用下列構(gòu)件圖圖5 表示。

    2.3.5 部署視圖。描述位于節(jié)點實例上的運行構(gòu)件實例的安排。節(jié)點是一組運行資源，如計算機、設(shè)備或存儲器等，部署視圖用部署圖來表達。圖6 表示了系統(tǒng)中的各構(gòu)件和每個節(jié)點包含的構(gòu)件。

    3 結(jié)束語

    統(tǒng)一建模語言UML的出現(xiàn)為信息系統(tǒng)建模與設(shè)計提供了有力工具。利用基于UML的可視化的建模軟件工具，我們可以按照RUP 的要求方便的管理項目需求、使用基于組件的框架、驗證軟件質(zhì)量、控制版本更新，從而實現(xiàn)整個軟件系統(tǒng)的面向?qū)ο蟮姆治觥⒃O(shè)計與迭代開發(fā)。這一技術(shù)的深入普及與應(yīng)用必將對我國軟件產(chǎn)業(yè)的發(fā)展產(chǎn)生非常積極的推動作用，