基于UML的校園一卡通管理系統的分析與設計

文章出處：http://www.xujuanpiju.com 作者：蘇州大學 段培同 徐州師范大學 王宜懷   人氣： 發表時間：2011年11月11日

    面向對象程序設計提出了一種新的系統設計模型，它將系統看成通過交互作用來完成任務的對象的集合，每個對象用自己的方法管理數據。本文將結合"一卡通"管理系統的分析與設計過程來闡述面向對象方法學的思想以及統一建模語言UML 中的具體應用。

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

    統一建模語言(Unified Modeling Language , UML) 是一個通用的面向對象的可視化建模語言，它主要是用于對軟件進行描述、可視化處理、構造和建立軟件系統制品的文檔。它造用于對任何具有靜態結構和動態行為的系統進行面向對象的建模。其中靜態結構定義了系統中的重要對象的屬性和操作以及這些對象之間的相互關系，而動態行為定義了對象的時間特性和對象為完成目標而相互進行通信的機制。標準建模語言UML 的主要內容也可以歸納為靜態建模機制和動態建模機制兩大類[1 。2] 從應用的角度看，當采用面向對象技術設計系統時，首先是描述需求，其次根據需求建立系統的靜態模型，以構造系統的結構，第三步是描述系統的行為。其中在第一步與第二步中所建立的模型都是靜態的，包括用例圖、類圖〈包含包〉、對象圖、組件圖和配置圖等五個圖形，是標準建模語言UML 的靜態建模機制。其中第三步中所建立的模型或者可以執行，或者表示執行時的時序狀態或交互系，它包括狀態圖、活動圖、順序圖和合作圖等四個圖形。

    2 "校園一卡通"管理系統的面向對象分析和UML 建模

    2.1 系統概述

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

    2.2 校園一卡通系統靜態建模

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

    2.2.2 發現對象，找出對象類，描述類的屬性與服務，建立類圖。對這個系統而言，在系統邊界以外與系統進行交互的活動者是管理員、服務員和消費者，考慮系統問題域和系統責任可以發現下述對象z：收款機(POS) :該對象直接與系統聯系，模擬服務員的登錄系統、收款等行為。系統服務器(Sys) :此類對象直接與系統進行交互，與消費者、服務組進行業務聯系，該類對象直接操作系統主程序。儲值卡(Card) :代表消費者與系統和收款機進行交互，模擬消費者進行充值、消費等活動。消費事項(XF): 消費者在某服務窗口進行一組消費，通過服務員連續操作POS 完成收款活動，就稱為一次消費事件。經營結算事項(JY) :對每一個服務組所有消費事件的數據按日志進行匯總，從而實現服務中心與服務組的結算。卡的管理事項(Card Manager): 此類事件主要是管理卡的注冊、發放、充值、掛失、注銷工作。消費日志(Daily Log): 為提供消費清單查詢和經營結算等行為進行實時監控提供詳細的記錄，需要系統有實時日志。考慮到未來經營窗口的變更，比如窗口收款機的進一步擴充，并以關聯類和集合管理器為核心設計樣式。它將來有不同的"經紀" (Agent) 是一個抽象類，包括新入網(net) 收款機(POS) 等。根據以上描述，可以發現該系統中有七個類，類的屬性及服務見表1。系統中，系統服務器處于主動位置，它管理相關的事項和其它類，其中卡與卡的管理構成一個整體一部分結構，這里沒有一般和特殊結構，這個系統中沒有實例連接關系。以上完成了"校園一卡通"系統的靜態模型分析，下面對它進行動態分析。

    2.3 動態分析

    2.3.1 順序圖。以事項為分析對象，考慮每個事項的個案詳細情況。用序列圖對消費事項個案進行更為詳細的描述，詳見順序圖2。

    2.3.2 狀態機視圖。狀態機視圖是一個類對象所可能經歷的所有歷程的模型。每個狀態對一個對象在其生命期中滿足某種條件的一個時間段建模。當一個事件發生時，它會觸發狀態間的轉換，導致對象從一種狀態轉化到另一新的。本系統中類的狀態轉換較為容易，這里僅給出卡的管理事項中的卡掛失的狀態圖，如圖3 所示。

    2.3.3 活動視圖。活動圖是狀態機的一個變體，用來描述執行算法的工作流程中涉及的活動。活動狀態代表了一個活動：一個工作流步驟或一個操作的執行。活動視圖描述了一組順序的或并發的活動。活動視圖用活動圖來體現。本系統的卡的管理活動圖，如圖4 所示。

    2.3.4 物理視圖。實現視圖為系統的構件建模一構件即構造應用的軟件單元-還包括各構件間的依賴關系，以便通過這些依賴關系來估計對系統構件的修改給系統可能帶來的影響。本系統的物理視圖可用下列構件圖圖5 表示。

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

    3 結束語

    統一建模語言UML的出現為信息系統建模與設計提供了有力工具。利用基于UML的可視化的建模軟件工具，我們可以按照RUP 的要求方便的管理項目需求、使用基于組件的框架、驗證軟件質量、控制版本更新，從而實現整個軟件系統的面向對象的分析、設計與迭代開發。這一技術的深入普及與應用必將對我國軟件產業的發展產生非常積極的推動作用，