基于UML的校园一卡通管理系统的分析与设计

    面向对象程序设计提出了一种新的系统设计模型，它将系统看成通过交互作用来完成任务的对象的集合，每个对象用自己的方法管理数据。本文将结合"一卡通"管理系统的分析与设计过程来阐述面向对象方法学的思想以及统一建模语言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 的要求方便的管理项目需求、使用基于组件的框架、验证软件质量、控制版本更新，从而实现整个软件系统的面向对象的分析、设计与迭代开发。这一技术的深入普及与应用必将对我国软件产业的发展产生非常积极的推动作用，