uml银行管理系统

uml银行管理系统（通用8篇）

uml银行管理系统 篇1

建模

课程设计报告

专业：

学号：

姓名：

任课教师：

一、系统概述

银行是与人们生活密切相关的一个机构，银行可以提供存款、取款、转账等业务。在银行设立账户的人或机构被称为银行的客户（customer）。一个客户可以在银行开设多个账户（account），客户可以存钱到账户中，也可以从自己的账户中取钱，还可以将存款从一个账户转到另一个账户。另外，客户可以随时查询自己的账户情况，以及查询以前所进行的存款、取款等交易记录。客户还有权利要求关闭自己的账户。

实际生活中的银行功能其实还要复杂得多，但为了简化系统，本次设计只考虑银行的基本功能。简化版的银行信息系统至少应具有如下功能：

1.一个银行可以有多个账户； 2.一个银行可以有多个客户； 3.一个客户可以持有多个账户； 4.一个账户可以有多个持有者； 5.银行可以为客户开设账户； 6.银行可以为客户注销账户； 7.客户可以从自己账户中取钱； 8.客户可以向自己账户中存钱；

9.客户可以在同一银行的不同账户之间转账； 10.客户可以在不同银行的不同账户之间转账； 请完成登录、存款、取款、转账和查询几个模块的设计。

二、需求分析

银行系统是与生活紧密相关的一个机构，银行提供了存款、取款、转账等业务。在银行设立账户的人或机构通常被称为银行的储户。一个储户可以在银行开多个账户，储户可以存钱到账户中，也可以从自己的账户中取现，还可以将存款从一个账户转到另一个账户。储户还可以随时查询自己账户的情况，并查询以前所进行的存款、取款等交易记录。后台管理员可以对客户的账户进行注销、删除、查询等管理，还有就是银行利息、汇率、手续费之类参数的设置，以及财务管理以及财务分析。

软件分别有开户，查询存取款，转账等功能。各个模块各有不同的功能，但都能完成查询和存取功能。各模块的数据都存放在数据库中。数据的调用和连接都有程序来完成。

此软件所要完成的主要功能有三方面：如果是存款，用户填写存款单，然后交给收银员键入系统，同时系统还要记录存款人姓名，住址，身份证号码，存款类型，存款日期，利率及密码（可选）等信息，完成后由系统反馈成功存款信息给用户。如果是取款，用户填写取款的相关信息（取款金额、取款币种）进行提交，系统要求用户输入密码以确认身份，核对密码正确无误后系统计算利息并印出利息单给用户。如果是转账，用户填写转账的相关信息进行提交，系统要求用户输入密码以确认身份，核对密码正确无误后系统计算利息并反馈信息给用户。系统及时更新数据库。

外部功能：实现化窗口，开户/销户、存款/取款、查询/转账。

内部功能：同步，过滤，定位，识别，更新，连接。

三、系统的UML基本模型

（1）、用例图

通过分析对银行管理系统的需求分析，确定参与者有银行客户、收银员。收银员具有维护系统信息、维护客户信息、查询客户情况和处理处理客户需求的作用。用例包括：

1）开户、2）存款、3）取款、4）转账、5）查询、6）销户等

（2）、用例描述：

用例名称：银行信息系统

描述：银行客户对需要办理业务的需求以及收银员对事件的处理。

（3）、银行信息系统的事件流

1.用例存款的事件流

1.1 前置条件

在存款之前，客户已经办理银行账号并且带来现金若干，并到达银行网点。1.2 后置条件

如果这个用例成功，这个存款事件是成功的，否则，系统没有变化。1.3 扩充点

无 1.4 事件流

1.4.1 基流（1）客户将银行卡交给收银员。

（2）收银员要求客户输入卡密码。

（3）客户输入卡密码，并确认密码。

（4）收银员提示，请客户选择服务类型。

（5）客户选择存款服务。

（6）收银员提示：存款数目。

（7）客户说出数目，并把钱交给收银员。

（8）收银员完成服务。

（9）收银员退还卡。1.4.2 替代流

如果输入的密码无效，用户可以重新输入密码或者终止用例。

2.用例转账的事件流

2.1 前置条件

在转账之前，客户已经办理银行账号，被转账人的账号已经存在并且已经知道了对方的账号。

2.2 后置条件

如果这个用例成功，这个转账事件是成功的，否则，系统没有变化。2.3 扩充点

无 2.4 事件流

2.4.1 基流

（1）客户填写转账单。

（2）客户把转账单和银行卡交给收银员。

（3）收银员要求客户输入卡密码。

（4）客户输入卡密码，并确认密码。

（5）收银员转账成功。

（6）收银员退还卡。2.4.2 替代流

如果输入的密码无效，用户可以重新输入密码或者终止用例。

3.用例查询的事件流

3.1 前置条件

在查询之前，客户已经办理银行账号并且携带银行卡，并到达银行网点。3.2 后置条件

如果这个用例成功，这个查询事件是成功的，否则，系统没有变化。3.3 扩充点

无 3.4 事件流

3.4.1 基流

（1）客户将银行卡交给收银员。

（2）收银员要求客户输入卡密码。

（3）客户输入卡密码，并确认密码。

（4）收银员提示，请客户选择服务类型。（5）客户选择查询服务。

（6）客户说出查询内容，收银员将内容反馈给客户。

（7）收银员完成服务。

（8）收银员退还卡。3.4.2 替代流

如果输入的密码无效，用户可以重新输入密码或者终止用例。

（4）、活动图

活动图是基于对象的状态变迁所绘制的视图。

收银员首先凭着自己的系统用户名和密码登录系统，收银员可以通过银行客户提供的有效证件号开户，提供客户账号开户、存款、取款、转账、查询、销户等功能，最后退出系统。

1．存款活动图

2．转账活动图

3．查询活动图

（5）、时序图

时序图（Sequence Diagram）主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。收银员通过用户账号和密码登录系统，在系统的操作窗口对需要存款、取款、转账、查询、销户的用户进行操作，最后退出操作窗口。

我们所开发的银行管理系统时序图如图所示：

（6）、类图

类图是对象结构建模的一部分，类图描述系统中类的静态结构。类图是代码生成（将模型转化为代码）的来源，也是逆向工程（将代码转化为模型）的目标设生成物。

类图设计如下图：

系统中主要的类（1）用户类： 它的属性有用户名（Name）、密码（Password）、银行卡号（Cardnumber）、用户身份证号码（ID）。

操作包括修改密码（Changpassword）、存款（deposit）、取款（cash）、转账（transfer）、查询（Chaxun）、、用户开户（Registered）。

（2）系统类：

它的属性有电脑号（Computernumber）、机器地址（Mac）。本身的操作没有，但有被管理员使用的操作。（3）收银员类：

它的属性有用户名（name）、密码（password）。操作包括用户开户（Registeredusers）、注销用户（Deleteusers）、查询用户信息（Chaxun）、系统维护（Weihu）。

（7）状态图

状态图用来表示建模对象是如何改变其状态的，状态定义为对象行为在某一时刻的快照或转折点。

四、结论

系统主要的实现目标是实现客户开户、存款、取款、转账、查询、销户和后台服务器端系统的设计，提供完善的功能设计。

五、总结及心得体会

uml银行管理系统 篇2

近年来, 铁路运输以其安全、快速、经济、舒适、便捷的优势, 在我国综合运输系统中的地位日趋重要。在影响铁路运输效能充分发挥的诸多因素中, 铁路既有线路的建设施工和设备维修生产活动对运输的影响是十分巨大的。本文在研究管理信息系统的特点、设计原则、开发方法及步骤的基础上, 对铁路运输生产中实行的天窗作业的特点和目前电务天窗作业管理中存在的主要问题进行详细的分析和阐述, 提出了利用现代化通讯网络, 建立铁路电务天窗作业管理信息系统的应用设计方案[1]。

1现状分析

“天窗”是指铁路列车运行图中不铺划列车运行线或调整、抽减列车运行线为营业线施工、维修作业预留的时间, 按用途分为施工天窗和维修天窗。维修天窗纳入基本运行图。“天窗”修是指利用“天窗”进行设备施工、维修的作业方式。随着列车速度的提高, 特别是特快列车对数的增加, 设备检修和施工的直接作业时间不断减少, 铁路技术装备和运输组织发生了很大变化, “行车不施工, 施工不行车”的运输组织原则, 对营业线施工提出了新的要求。通过实行运输设备的“天窗”修, 充分保障了铁路线路、道岔、桥隧、通信信号及接触网等基础设施的正常养护与维修, 使其保持良好的技术状态, 实现运用安全和稳定, 同时做到了一点多用、平行作业, 达到了提高作业效率、作业质量, 确保人身和行车安全的目的。

现行天窗作业的组织方式较为落后, 目前普遍采用的是手工填制+电话告知+传真+邮件的方式进行天窗计划的上报、审批、任务下达、计划的执行及其执行结果的登记等工作。这种传统的业务执行模式有许多不足之处。首先, 手工操作费时费力。对于日常的设备维护工作, 各工区申请的天窗时间较为固定, 但每次都需要手工录入;对于铁路局天窗审批人员来说, 整天埋身于各段上报的天窗电子或手工表格中进行审批并下达天窗任务是十分消耗精力的。其次, 信息分散, 不能共享。这里的“信息”是指天窗计划、天窗兑现情况等业务信息。信息分散, 表现在如下方面:一是手工填制的各类信息存放于不同的文件中, 该文件也许是电子的, 也可能是纸质的, 汇总相关信息时只能手工翻找、手工汇总;二是这些信息分散在处、段、车间、工区等各个单位或部门, 而部门之间的业务资料是相对隔离的。这样就造成各处想知道当天天窗计划的兑现情况, 要等待各段的上报;想查询本月的计划兑现, 仍需要向各段取得资料。 第三, 信息传递不畅。由于没有快捷、专门的传输途径, 每天的天窗修计划上报工作只能提前一至二天上报, 不能做到当日上报、当日审批并当日执行。这种方式对于工务、电务等部门的日常维护工作是比较适宜的, 但对突发的设备故障或特别重要的安全隐患的维修却不能及时审批、及时排除故障或隐患。同时, 信息交互不畅使得业务信息的汇总、上报、下达等工作所花费的时间大大制约了运输、工务、电务、供电等部门之间协调效率的提高, 也无法及时、准确为路局经营决策部门提供生产运输方面的一手资料或信息。

建设天窗综合管理信息系统, 正是以《铁路信息化总体规划》的推广实施为契机, 以解决目前天窗修业务组织管理中的诸多缺陷与不足、在局域网络上实现天窗计划实时申报、实时审批, 实时登记天窗兑现情况, 并为路局、相关段各部门提供快速、准确地统计查询功能为目的, 是铁路信息化建设的重要组成部分。同时, 极大方便了电务部门的管理, 实现了铁路电务上天窗管理的办公无纸化和数字化。

2需求分析

随着面向对象技术的发展, 基于用例的方法在需求获取和建模方面应用得越来越普遍。这种方法是以任务为中心和以用户为中心的, 比起使用以功能为中心的方法, 它可以使用户更清楚地认识到新系统允许他们做什么。另外, 用例有助于分析者和开发者理解用户的业务和应用领域, 开发者还可以运用面向对象的设计方法将用例转化为对象模型[2]。

在用例模型中, 我们只是关心系统所应实现的功能, 而不关心内部的具体实现细节。一般来说, 用例模型的建立是由开发者和客户共同协商完成的, 通过反复讨论需求的规格说明达成共识, 明确系统的基本功能, 为后续阶段的工作打下基础。

(1) 确定角色

角色代表着与系统交互的人或事。通过确认系统功能使用者和维护者以及与系统接口的其他系统或硬件设备等, 可以有效地识别出系统角色。

(2) 确定用例

一个完整的系统包含若干个用例, 每个用例具体说明应完成的功能。识别用例首先要确定系统所能反映的外部事件, 并把这些事件与参与的执行者和特定的使用实例联系起来, 最终绘制出用例图。

(3) 描述用例

单纯地使用用例图不能提供用例所具有的全部信息, 因此, 需要使用文字描述那些不能反映在图形上的信息。用例描述实际上是关于角色与系统如何交互的规格说明, 要求清晰明确, 没有二义性。

在用例模型中, 角色和用例是两个基本概念, 分别代表着系统外部的执行者和系统应包含的功能, 因此, 建立用例模型的主要工作是确定角色、确定用例和描述用例。依据上述步骤, 建立了天窗修用例模型图, 如图1所示。

3天窗管理系统的体系结构

天窗综合管理系统是电务综合管理信息系统的重要组成部分。其体系结构采用服务器/客户端 (C/S) 和服务器/浏览器模式 (B/S) 相结合的模式。数据库选用sql server数据库系统, 运行于WINNT4.0服务器平台, 开发工具采用的是vs.net, 软件客户端可运行于WINDOWS平台, 通过友好的人机界面, 完成天窗管理。

系统数据库存放在服务器上, 来自各段的所有业务数据都被储存在服务器。服务器部署在铁路局, 由专人负责维护。铁路局同时设有应用服务器, 主要负责接收处理各电务段内的客户端的业务数据请求, 并负责与服务器进行数据交互[3]。其信息组成结构如图2所示。

系统支持远程访问、近端访问。系统支持远程工作站, 通过通信网络) 实现对系统中心服务器的访问, 系统同时也支持近端工作站, 通过局域网对系统中心服务器的访问[4,5]。

系统结构具有良好的可扩展性, 系统的扩展应是方便易行的, 在扩展过程中不会对整个系统产生影响。

4系统设计实现

根据原手工系统的作业流程图, 设计出系统模块调用关系图, 如图3所示。

系统由四个子系统组成, 它们分别是系统管理子系统、基础信息管理子系统、文档审批管理子系统、天窗作业管理系统。系统管理子系统的主要任务是管理系统用户账户、设置用户使用权限和数据备份;基础信息管理子系统主要功能是维护整个系统的基础信息或设置相关参数;文档审批管理子系统主要功能是对的审批文档进行、审批流程定义及其审批。天窗管理子系统主要完成不同级别天窗月、日计划的编制、天窗任务的下达, 兑现及其报表和查询等功能。

5结论

系统采用了级别较高的安全策略和工作流技术的相关思想, 将天窗计划的编制、计划的上报、计划的审批、天窗计划任务的实施及组织等功能与铁路车站、工区、车间、段、处 (局) 、员工、用户、角色等基础信息紧密结合, 实现了信息共享、高度可维护、方便使用、业务流程自动化推进的目的。通过本系统的应用, 可以大大加强铁路电务天窗作业的管理, 减轻工作人员的工作负荷, 提高工作效率, 使用户摆脱人工操作的繁琐模式, 实现电务天窗作业管理的科学性、现代化。

摘要：对铁路运输生产中实行电务天窗作业管理中存在的主要问题进行详细的分析和阐述, 提出了利用现代化的网络通信, 建立铁路电务天窗作业管理信息系统的应用设计方案, 并对天窗作业流程作了详细的描述, 确立了系统架构和目标功能。

关键词：天窗修,MIS,UM,数据库

参考文献

[1]《铁路营业线施工及安全管理办法》铁道部办公厅[2008]190号.

[2]高复先, 吴曙光.信息工程与总体数据规划[M].北京:人民交通出版社, 1989.

[3]罗超理.管理信息系统原理与应用[M].北京:清华大学出版社, 2002.

[4]庞开放, 李龙澍.基于.NET框架的Web应用与实现[J].微机发展, 2005, 15 (3) .

[5]肖金秀.ASP网络编程技术[M].北京:清华大学出版社, 2001.

uml银行管理系统 篇3

关键词：ERP；销售管理系统；UML

中图分类号：TP311文献标识码：A 文章编号：1009-3044(2007)16-30931-03

Modeling on the Sales Management System of ERP Based on UML

XIAO Wen-min, MENG Qing-guo, YAN Bing

(Department of Mechanism ,Tianjing University of Technology and Education,Tianjin 300222, China)

Abstract:ERP can plan resources transcending one enterprise to fulfill perfect management for the whole supply chains. As to moderate and small enterprise, it is urgent to control inner business. The paper are written to molding the sales management system by using UML which can accelerate the software’s development process and improve it’s quality.

Key words:ERP; sales management system; UML

1 引言

经济全球化发展趋势使得当前企业对ERP系统的需求日益增长，需求变化也越来越快。然而，中小型企业资金少，经营规模小，不能承受引进大型ERP系统所需的巨额费用，设计一种功能相对完善、成本较低、实用性较强、系统容易维护且功能容易扩展的ERP系统就为广大中小企业所期待。考虑到这样的系统仍然庞大而复杂, 内部各种数据流、资金流、业务流交错, 业务流程动态变化且管理方法不断更新, 使系统在设计阶段很难保证软件质量, 也很难预测后期的维护和升级开销。这就给软件的设计、开发和维护工作带来了很多困难。并且它的开发与单一模块的软件开发有着很大的区别，企业各个业务之间错综复杂的联系是ERP系统软件设计和开发工作必须攻克的难关[1]。

统一建模语言UML是面向对象技术领域内占主导地位的标准建模语言，可以对复杂的系统建立可视化系统模型，目前已经被工业标准组织OMG(Object Management Group)接受，得到了Microsoft, HP, IBM, Oracle等支持，在国际上应用日益广泛[2]。

本文将结合天津市某小型企业，通过对该企业ERP销售管理系统的分析与设计，阐述如何通过UML降低开发难度和提高开发效率。

2 销售管理系统的功能模块和基本特征

销售部门在企业的供需链中处于与市场与企业的供应链接口位置，主要职能是为客户与最终的用户提供产品及服务，从而实现企业的资金转换并获取利润，为企业提供生存与发展的动力源泉，并由此实现企业的社会价值。综合来说ERP的销售管理提供的销售预测、销售计划、销售订单是主生产计划的需求来源。销售管理子系统帮助企业的销售人员完成客户管理、产品价格管理、销售订单管理、销售发货、服务管理、发票管理等一系列销售事务。销售管理的主要结构可以划分5个主要功能模块： 销售计划管理、客户管理、订单管理、收发货管理以及销售服务管理。

本系统以“订单”为核心，构建出了以“客户”为中心的管理模式。

该系统具有以下一些特征：

（1）先进的系统结构，面向销售流程，能适应原有销售工作流程并进行合理的改进，从而更贴近实际的应用。

（2）系统提供的灵活的人员权限设置和全面的财务核算方式，实现真正的销售网络化办公。

（3）在实现订单的电子化、工作流程的数字化同时，帮助公司领导提高决策的科学化水平。

（4）通过对客户信息的管理，实现对不同客户情况统计和分析。

整个系统操作业务人员包括：销售员、销售经理、仓库管理员、审计员、销售主管、和系统管理员。各个角色承担不同的系统任务，通过网络和通信系统，连接到销售管理系统，使用统一的访问界面，进行日常的销售业务操作，最终实现销售部门业务的正常运转。

3 UML概述

UML是一种可视化建模语言，用于对软件系统进行描述、可视化处理，构造和建立软件系统制品的文档。它记录了对必须构造的系统的决策与理解，可用于对系统的理解、设计、浏览、配置和信息控制[3]。UML能够描述系统的静态结构和动态行为。静态结构定义了系统中的重要对象的属性和操作以及对象之间的相互关系，静态结构视图包括类图、用例图、组件图和部署图。动态行为定义了对象的时间特性和对象为完成目标而相互进行通信的机制，动态行为视图包括状态图、活动图、顺序图和协作图。

4 销售管理系统的建模分析

4.1 销售管理系统的业务建模和需求分析

业务模型和需求分析的目的是对系统进行评估，采集和分析系统的需求，理解系统要解决的问题，重点是充分考虑系统的实用性。结果可以用一个业务用例（Business Use Case）框图表达，根据销售系统的基本特征和功能可得到本系统的用例图（如图1所示）。

图1 销售订单管理子系统用例图

模型中的活动者代表外部与系统交互的单元，包括销售员、仓库管理员、维修人员、审计员、公司销售主管、和系统管理员；业务用例框图是对系统需求的描述，表达了系统的功能和所提供的服务，包括客户管理子系统、订单管理子系统、销售统计子系统、产品管理子系统、售后服务子系统。图1是销售管理系统层次的用例模型，只包含了最基本的用例模型，是系统的高层抽象。在开发过程中，随着对系统需求认识的不断加深，用例模型可以从顶向下不断细化，演化出更加详细的用例模型。

根据系统的用例图，可以对系统的持久对象进行设计，图2是本系统持久对象类及类之间关系图。

图2 核心业务对象类及类之间的关系

4.2 销售管理系统分析与设计

系统分析与设计是研究欲采用的实现环境和系统结构，结果是产生一个对象模型，也就是设计模型。设计模型包含了用例的实现，可以表现对象如何相互通信和运作来实现用例。对于系统的静态结构，可以通过类图、对象图、组件图和配置图来描述；对于系统的动态行为，可以通过顺序图、协同图、状态图、活动图描述。这些图在加上说明文档就构成完整的设计模型。

4.2.1系统架构设计

销售管理系统拥有大量销售信息资源，这些资源包括各种客户、订单、和产品等信息。其数据量大、信息变化快，非结构化信息与结构化信息共存。使用UML对销售管理系统进行基于面向对象的分析和实现，可以从开发的第一步开始，从系统的底层就把握住销售信息资源的特征，为下一步具体实现打好基础。在销售管理系统建立模型时要涉及到处理大量的模型元素，如类、接口、组件、节点、用例等，可以将语意上相近的模型元素组织在一起，这就构成了UML的包，包把这些建模元素按照逻辑功能分组，以便理解、反映它们之间的组成关系。

本系统在此将使用Java Web开发，系统主要有以下四个包：

（1）用户接口包（User Interface package）

用户接口包在其它包的顶层次，为系统用户提供访问信息和服务，即边界类。对于每一个参与者，都应该设置至少一个边界类，以表示参与者与系统进行的交互。

（2）业务逻辑包(Business Rule Package)

该包是销售管理系统业务的核心实现部分，包括客户管理、订单管理、产品管理等，其它包可以通过访问该包提供的接口，实现业务逻辑，如客户管理业务等。

（3）数据持久访问包(Data Persistence Package)

该包实现数据的持久化，也就是与数据库交互，实现数据的存取、修改等操作。

（4）通用工具包（Util Package）

该包主要包括应用程序安全检查的类，可以为上面三个包提供安全检查，如客户端检查和服务器端业务规则检查等，同时包括一些系统异常检查与抛出处理以及系统日志服务等。

4.2.2系统详细设计

详细设计主要是描述在系统分析阶段产生的类，与分析阶段类的区别就是偏重于技术层面和类的细节实现。销售管理系统提供的各种服务都是建立在分布、开放的信息结构之上，依托高速、可靠的网络环境来完成的。每项服务都可以看作一个事件流，由若干相关的对象交互合作来完成。对于这种系统内部的协作关系和过程行为，可以通过绘制序列（Sequence）框图和协作（Collaboration）框图来帮助观察和理解。此外，描述工作流和并发行为还可以通过活动框图，表达从一个活动到另一个活动的控制流。同时，可以在理解这些图的基础上，抽象出系统的类图，为系统编码阶段继续细化提供基础。下面是客户管理子系统详细设计。

（1）客户管理子系统的基本结构建模：图3是客户管理子系统主要类极其关系的详细设计。

图3 客户管理子系统类的详细设计及类之间关系

（2）序列图：序列图是一种对象交互图，着重强调了时间序列，而不是静态对象的关系，通过序列图可以清楚地看到不同对象之间的实时行为。

图4是一个客户管理的序列框图例子。描述了先加载某个客户；显示某些状态；再更改某些属性值，最后更新数据库状态的一次执行过程。通过序列框图可以清晰看出系统用户、客户管理子系统的用户接口、数据库连接模块之间以时间为顺序的消息交换，这对于把握系统的控制流、顺序行为和交互行为是非常有益的。

图4客户管理的序列图

（3）状态图适合描述一个对象穿越多个用例的行为。类的状态图表示类的对象可以呈现的状态和这个对象从一种状态到另一种状态的转换。图5描述了Customer对象的生命期中可能的状态及状态变化（从创建、更新到消亡的转变过程），其中ready用于加载客户信息，persist用于保存客户信息，save用于成功的保存成绩，error用于由于数据等的异常而未能成功的保存客户信息。

（4）协作图：协作图和序列图相似，两种图所表达的是同一种信息，可以互相转换。但两者是有区别的，序列图强调的是交互的时间序列，协作图强调的是交互的语境和参与交互的对象的整体组织。图6描述的是查询一个客户信息消息传递的过程。

（5）活动图：用于描述业务过程和类的操作，类似与流程图，显示出一个问题的活动（工作步骤）、判断点和分支。图7是反映了更新客户用例的活动图。

图5Customer对象状态图

图6 查询客户信息的协作图

图7 业务处理活动图

通过框图，可以确定需要开发的类、类之间的关系和每个类操作和责任。序列框图按照时间排序，用于通过情境检查逻辑流程。协作框图用于了解改变后的影响，可以很容易看出对象之间的通信，状态图描述了对象在系统中可能的状态，如果要改变对象，就可以方便地看到受影响的对象。

（6）软件系统一般由一组部件组成，换句话说，部件是相对独立的部分软件实施，有自己特有的功能，并可在系统中安装使用，系统中各部件相互协作，给系统提供完整的功能。图7是本系统运行时的主要部件。

图8 运行的部件图

4.2.3 销售管理系统的实现、测试和系统配置

系统采用五层逻辑结构：客户端只需中文浏览器；表示层用12个JSP(Java Server Page)文档实现动态页面以创建、操作业务对象；核心对象层用6个Java类以JavaBean形式构成业务处理的核心对象；连接层采用JDBC2提供两种连接方式：一种是基于DriverManager，主要支持Java应用和测试；另一种基于DataSource；资源层即数据库服务器。

经过系统分析和设计后，就可以根据设计模型在具体的环境中实现系统，生成系统的源代码、可执行程序和相应的软件文档，建立一个可执行系统；进而需要对系统进行测试和排错，保证系统符合预定的要求，获得一个无错的系统实现。测试结果将确认所完成的系统可以真正使用；最后完成系统配置，其任务是在真实的运行环境中配置、调试系统，解决系统正式使用前可能存在的任何问题。

5 结束语

ERP系统的发展方兴未艾，我国中小企业目前正处于传统手工、半手工管理向数字化过渡的阶段，将 UML应用于销售管理系统的建设，可以加速开发进程，提高代码质量，支持动态的业务需求。从实际效果来看，UML可以保证软件开发的稳定性、鲁棒性，在实际应用中取得良好的效果。

参考文献：

[1]罗鸿. ERP原理·设计·实施[F].北京：电子工业出版社，2005.

[2]宋波，刘杰，杜庆东.UML面向对象技术与实践[TP].北京：科学出版社，2005.

[3]RUMBAUGH J，JACOBSON l，BOOCH G．姚淑珍，唐发根，等译．UML参考手册[M]．北京：机械工业出版社，2001．

uml 描述高校教材管理系统 篇4

随着高等学校扩大招生情况的出现，每一个高校需要处理的各种教材的数量逐年倍增。如何改变低效率的原始教材管理方式，成为摆在高校管理人员面前的一个重要课题。而建立高效的教材管理系统就是一个解决此根本问题的思路。所以，这里为读者介绍一个高校教材管理系统的建模实例。

2.1需求分析

高校教材管理系统的功能性需求综述如下：

（1）高校的每个学生使用自己的姓名和学号登陆系统之后，可以查询自己每个学期的教材使用情况，也能够查询自己的教材费用。

（2）高校的每个老师使用自己的姓名和密码登陆系统后，能够查询自己教材的使用情况，也可查询自己的教材费用（供报销用）。

（3）系统管理员通过用户名和密码登陆系统后,能够输入教材订购计划,生成订购单,统计各个班级教材费用和教材使用情况,同时，还可以更新删除学生﹑教师﹑教材等各类信息。

2.2系统建模

在系统建模以前，我们首先需要在Rational Rose 2003中创建一个模型。并命名为“高校教材管理系统”，该名称将会在Rational Rose 2003的顶端出现，如下图2-1所示。

图2-1创建项目系统模型

2.2.1创建系统用例模型

创建系统用例的第一步是确定系统的参与者。高校教材管理系统的参与者包含以下三种：

（1）学生（2）教师（3）系统管理员

此三个参与者如图2-2所示。

图2-2 系统参与者图 2-3 学生用例图

然后，我们根据参与者的不同分别画出各个参与者的用例图。

（1）学生用例图：学生在本系统中可以进行登录、教材费用查询和教材使用情况查询的相关操作，通过这些活动创建的学生用例图如图2-3所示。

（2）教师用例图：教师在本系统中可以进行登录、查询教材费用和教材使用情况查询的操作，通过这些活动创建的教师用例图如图2-4所示。

图 2-4 教师用例图图 2-5 系统管理员用例图

（3）系统管理员用例图：系统管理员在本系统中可以进行登录、教材订购资料输入、生成订购单、统计教材费用、统计教材使用情况和管理各类信息的操作，通过这些活动创建的系统管理员用例图如图2-5所示。

2.2.2创建系统静态模型

从前面的需求分析中，我们可以依据主要六个类对象：学生、教师、班级、教材、库存和订单创建完整的类图如图2-6所示。

图2-6 系统类图

2.2.3创建系统动态模型

系统的动态模型可以使用交互作用图、状态图和活动图来描述。

2.2.3.1 创建序列图和协作图

1.学生在本系统中活动步骤分为：（1）进行注册个人信息（2）登录通过身份验证（3）选择查询的教材（4）查询使用情况（5）返回查询结果（6）退出系统。根据以上步骤创建的序列图和协助图，如下图2-7和图2-8所示。

图 2-7 学生序列图

图 2-8 学生协作图

2.表示教师的序列图和协作图与学生序列图和协作图相似，只是把学生换成了教师。

3.系统管理员在本系统活动的步骤分为：（1）进行注册个人信息（2）登录通过身份验证（3）管理学生信息、管理教师信息或管理教材信息。（4）退出系统。根据以上步骤创建的的序列图和协作图，如图2-9和图2-10所示。

图 2-9 系统管理员序列图

图 2-10 系统管理员协作图

2.2.3.2 创建活动图

我们还可以利用系统的活动图来描述系统的参与者是如何协同工作的。高校教材管理系统中，根据教材管理人员、学生和教师的活动步骤，我们可以创建活动图如下图2-11所示。

图 2-11 系统活动图

2.2.3.3 创建状态图

在高校教材管理系统中，有明确状态转换的类是系统参与者，在整个验证过程前后有各种不同的状态。本系统的状态图如下图2-12所示。

图 2-12 参与者状态图

2.2.4创建系统部署模型

对系统的实现结构进行建模的方式包括两种，即构件图和部署图。高校教材管理系统的构件图我们通过构件映射到系统的实现类中，说明该构件物理实现的逻辑类，在本系统中，我们可以对学生类、系统管理员类、教师类、教材库存、订单类、教材类和班级类分别创建对应的构件进行映射，创建的高校教材管理系统的构件图如图2-13所示。

.图2-13 系统构件图

高校教材管理系统的部署图描绘的是系统节点上运行资源的安排。包括四个节点，分别是：客户端浏览器、Http服务器、数据库服务器和打印机，创建后的部署图如图2-14所示。

uml银行管理系统 篇5

提要：UML 是一种可视化的建模语言, 是面向对象分析与设计的重要工具。本文采用统一建模语言UML对税务稽查管理系统进行了分析

关键词：UML系统分析税务

统一建模语言UML是Rational公司的知名专家 Gary Booch、Ivar Jacobson和Jim Rumbaugh三人联合开发的第三代面向对象的建模语言。于1997年被OMG接受，在软件开发的每个步骤中，从对需求的分析到技术规范，再到结构设计及配置要求，它采用了一整套成熟的建模技术, 广泛适用于各种应用领域。它得到了工业界的广泛支持, UML是一种定义良好、易于表达、功

能强大、适用面广的第三代面向对象的建模语言。它不仅支持面向对象的分析与设计, 而且支持从需求分析到系统设计以及系统实现的软件开发的全过程。UML代表了面向对象方法的软件开发技术的发展方向, 具有巨大的市场前景。UML已被对象管理组织（OMG）接受为标准的面向对象建模语言。

为促进税务管理现代化的进程, 实现以计算机网络为依托, 主动申报, 集中征收, 重在稽查的新的征管模式, 本文利用统一建模语言对税务稽查管理系统进行了系统分析。

1、统一建模语言概述

UML是OO开发中一种有严格语法定义、易于表达的建模语言, 支持面向对象建的全过程。它通过一整套的图形符号和相应的方法学来系统地反映现实世界的客体, 是一种可视化的图形建模语言。UML主要包括以下几种基本模型：

1.1、用例模型：通常认为, 用例模型是由系统的内部功能（用例）、系统的外部环境（角色）以及两者之间的关系（用例图）组成, 这是以系统的外部的操作者的角度描述系统的功能；从而为需求分析提供标准化手段。

1.2、静态图：包括类图、对象图和包图.其中类图用于展示系统中类的静态结构, 不仅定义系统中的类, 还表示类之间的联系, 如关联、依赖、聚合等, 也包括类的内部结构(类的属性和操作),它表达了系统在一个稳态必须满足的对象间的关系, 它描述的是一种静态关系, 在系统的整个生命周期都是有效的；对象图是类图的一种实例化图, 它使用与类图完全相同的标识, 不同之处在于它显示的是类的多个对象实例, 由于对象存在生命周期, 因此对象图只能在系统的某一个时间段存在；包图是对类图的一种分组机制, 用于描述系统的分层结构, 可以帮助理解与维护。

1.3、行为图：包括状态图和活动图, 其中状态图用于描述一类对象具有的所有可能的状态极其转移关系；活动图用于展示系统中各种活动的执行流程。

1.4、交互图：包括顺序图和合作图, 其中顺序图用于展示对象之间的一种动态协作关系（强调时间上的顺序关系）；合作图用于从另一个角度展示对象之间的动态协作关系（强调相互间的通信关系）。

1.5、实现图：包括构件图和配置图, 其中构件图用于展示程序代码的物理结构；配置图用于展示软件在硬件环境中的配置关系（尤其在分布式及网络环境中）。

UML包括5个大类10种模型图, 为人们提供了从不同角度去观察和展示系统的各种特征的一种标准方法, 不同类型的系统、不同领域的系统会分别用到不同的模型或几个模型的组合, 作为系统分析, 通常以用例图、类图和行为图的视角来描述系统。

2、系统模型的建立

目前存在很多种面向对象的开发方法, 各自具有自己的优点和缺点, 基于这些方法中的成熟技术,UML采用其中最好的思想、观点以及相关的技术特色, 并把它们融合成一个完整的开发过程。因此, UML是一种扬长避短的方法。UML的分析步骤可简述如下：

1、建立需要模型。根据初始的需求文档, 在用户参与的情况下, 定义角色与用例, 建立其需求模型, 包括静态模型和动态模型, 即用例图和活动图, 而静态模型就是功能模型；

2、建立初始的对象模型。系统的对象模型同样包括静态模型和动态模型, 通过包图、类图和对象图定义系统对象及对象间的静态关系, 通过顺序图、合作图和状态图描述对象间的交互关系和交互顺序、对象的生命周期以及生命周期中对象可能存在的状态以及状态间的 转换约束；

3、建立定义类的责任由此确定对象模型中类的服务和属性, 重定义和精化类和类之间的关系, 产生了一个精化的对象模型；

4、参照对象模型可以从用例和服务建立事件踪迹图和对象状态图来描述系统的动态特性。

通过重复分析过程同时精化对象模型和动态模型, 可以保证分析模型的正确性、完整性和一致性。

2.1、建立系统的需求模型

需求分析就是说明系统需要做什么, 对于系统项目, 需求说明不仅是开发的基础, 也是衡量最终系统是否满足用户需要的依据。

税务稽查是指税务机关以税收法律、行政法规和税收征收管理制度为依据,对纳税人是否履行纳税义务及其偷、逃、骗、抗、避税行为的审核和查处行为的总称。做好税务稽查工作的前提是案件选择的正确性，本系统根据实际需求, 分为如下几个功能：

制度违章。对计算机存储的确定稽查对象提供依据的有关信息资料, 依据选案标准, 确定日常稽查待查对象, 经过人工归集分类得到稽查对象；

综合查询。对稽查管理有关的各种数据进行排列, 组合的查询, 以便随时提供各种准确数据；

计划管理。是税务局内部进行计划制定, 计划调整, 计划完成情况监控分析而使用的功能。它是稽查从选案到实施、审理、执行的一个全面管理过程；

稽查分析主要是利用税务稽查问题汇总单数据对违法成因, 违法特征、违法频度及稽查

成果进行统计、分析, 为选案部门及领导决策提供依据；

文书处理。主要是处理稽查过程中的各种需要输人、输出的结果。根据功能划分, 画出用例图（见图1）。

2.2、建立系统的分析模型

面向对象的分析就是用对象的概念分析系统应该做什么。而采用UML 进行分析的主要工作就是建立系统的分析模型。UML中支持分析建模的图形有多种, 在实际进行系统分析时,系统分析员与工程设计人员应根据实际需要选择适用的图形进行描述。通常主要采用3 种图形：类图、序列图和活动图。类图是UML中最核心的图形, 描述了系统中的类与类之间的关系。本文主要以类图为例进行说明。

按照前面的分析我们不难得出这些类。制度违章类及纳税情况分析类。制度违章类又派生出税务登记违章类、纳税申报违章类及发票违章类、而纳税情况分析类又派生出零申报情况分析类、流转税情况分析类、企业所得情况税分析类及财务指标分析类。详细见图所示。

3、结论

UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。本系统采用UML建模语言进行分析, 具有灵活、高效的特点, 为进行可视化大型系统的开发提供了极大的方便。

uml银行管理系统 篇6

基于UML的新型农村合作医疗管理信息系统建模

统一建模语言(UML)已成为一种面向对象建模语言的标准,它吸收了软件工程领域的新方法和新技术.阐述了结合使用J2EE和UML的原因以及如何运用UML实现对J2EE的建模表示,探讨了运用UML对复杂系统建模的过程和方法.这些模型有助于开发人员对中间层(即商业逻辑层)设计的优化,并可有效的实现软件的.重组和复用.根据纯面向对象思想,在UML建模研究的基础上,实现Java三层结构的新型农村合作医疗信息系统.

作 者：王世华 艾剑良 WANG Shi-hua AI Jian-liang  作者单位：复旦大学,力学与工程科学系,上海,200433 刊 名：科技与管理 英文刊名：SCIENCE-TECHNOLOGY AND MANAGEMENT 年，卷(期)：2009 11(1) 分类号：C931 关键词：管理信息系统   统一建模语言   面向对象   快速还原法  

uml银行管理系统 篇7

UML(Unified Modeling Language)是由面向对象方法领域的三位著名专家Grady Booch,James Rumbaugh和Ivar Jacobson提出的,并于1997年11月被OMG(国际对象管理组织采纳,成为面向对象建模的标准语言[1]。它融入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程[2]。UML主要用图来表达模型的内容,从不同的视角为系统建模。其重要内容可由:1)用例图;2)静态图;3)行为图;4)交互图;5)实现图这五类图包括9种图形:用例图、类图、对象图、状态图、活动图、顺序图、协作图、配置图和组件图来定义。为此,我们尝试就UML在高校科研管理系统中的应用,研究实现在基于B/S结构的系统中利用UML进行系统建模。

B/S(Browser/Server,浏览器/服务器模式)结构是WEB兴起后的一种网络结构模式。其最大的优点是将用户界面、应用逻辑与数据管理分开,可以在任何地方进行操作而不用安装任何专门的软件。本文所描述的系统中,采用了基于B/S结构模式的三层应用结构,即用户层、应用层、数据层,各部分之间通过中间件通信。

2 系统需求分析

该高校科研管理的过程是:教师录入个人科技成果并提交给院系科技成果管理人员。由院系科技成果管理人员进行初审,确定无误后上报校科研处。由校科研处科技成果管理员审核。审核通过后,进行相应工作量计算,作为评定职称及其他各种奖项的重要依据。若审核未通过,则将其申请退回所属院系,并通知退回原因。由院系科技成果管理人员通知其本人。并且要求在科技成果日常管理的工作中,能够以个人或院系为单位统计、打印报表;能够对科技信息数据进行初始化,对科技管理人员信息进行管理、权限管理。

3 高校科研管理系统建模

标准建模语言UML的主要内容也可以归纳为建立静态模型和建立动态模型两大类。其中静态模型可以用用例图、类图、对象图、组件图和配置图等描述;动态模型可以用状态图、活动图、顺序图和协作图来描述,表示了执行时的序列、状态或交互关系。

3.1 需求模型

在此系统中,用MUL的用例图描述系统的功能需求建立需求模型。用例图用来描述人们如何使用系统,它主要由用例和角色组成。用例就是对系统提供的功能的描述,在图中用椭圆来表示。角色是用例功能的使用者,在图中用简笔人物表示。根据上文对科技成果管理过程的分析,我们可以看出此系统的角色可以分为:系统维护员、校级科技成果管理人员、院系科技成果管理人员、教师。系统所提供的用例如图1所示。

其中,空心三角形箭头符号表示科技成果管理人员是教师的泛化,实线箭头表示角色与用例之间的关联。

3.2 结构模型

建立用例图后,即可从用例中分析出类。类图表示了类的属性、接口、操作以及他们之间的关系。建立类模型的过程,实际上是对现实世界的一个抽象过程,它把现实世界中与问题有关的各种对象及其相互之间的各种关系进行适当的抽象和分类描述[3]。

以系统的“科技成果管理”模块为例的类图,如图2所示。图2中,Teacher(教师)类、Technology Manager(科技成果管理员)类和Administrator(系统管理员)类都继承了用户类,它们之间是子类与父类的继承关系,用户类包含了一般教师类、科技成果管理员类和系统管理员类这三类所共有的一些基本信息以及一些基本的操作。而这三类各自又新增了不同的属性、操作,如:Department_id(所属院系号)、rework Article(修改著作)、audit Article(审核著作)、stat.Article(统计著作)等。用户类与Article(著作信息)类之间是一对多的关系,一个用户可有多篇著作。

3.3 行为模型

建立静态模型后,为了体现系统的动态特征,需建立系统的动态模型。状态图表现从一个状态到另一个状态的控制流。通过状态图可以了解一个对象所能到达的所有状态,以及事件作用于对象对其状态产生的影响等。以系统的“科技成果管理”为例,给出UML状态图在系统中的应用。如图3,显示了科技成果管理人员进行著作管理时所经历的几种状态,以及各状态之间转换的条件:科技成果管理人员登录系统主页面进入输入用户名和密码状态,若密码输入正确则进入选择操作类型状态,若密码输入有误,则停留在原状态。进入选择操作类型后可根据不同需要进行相应的选择,由此状态可以进入查询著作、添加新著作和统计著作状态。进行查询、添加、统计后,科技成果管理员可以返回上一个状态,也可以退出。其中查询著作可根据不同查询条件,会有多个查询结果,可由此进入查看某个著作的相关信息、审核著作、删除某著作的状态。

3.4 实现模型

对系统物理方面进行建模可以使用组件图和配置图。配置图描述了系统执行处理过程中系统资源配置情况,可以显示配置和配置之间的依赖关系。本系统采用了浏览器/服务器(B/S)三层体系结构,其配置图如图4所示。其中的立方体表示节点,可以是服务器和客户端,节点间的连线表示各节点之间的通信路径。

4 结语

本文以高校科研管理系统的开发为背景,基于B/S结构用UML面向对象建模机制对系统进行了分析设计。在建模过程中,使用UML丰富的视图从多个视角对系统的不同侧面进行了描述,将系统的分析、设计和实现有机集成起来,便于对系统在更高抽象层次上进行维护,提高系统的可扩展性。

参考文献

[1]张海藩.软件工程[M].北京:人民邮电出版社,2003.

[2]吴际,金茂忠.UML面向对象分析[M].北京航空航天大学出版社,2002.

uml银行管理系统 篇8

摘 要：随着“互联网+”在教育领域的应用，理实一体化课程在职业教育应用广泛，构建相应的学习、教学空间成为当下流行趋势，作者根据学习空间课堂教学管理实现的功能，应用UML分析设计B/S结构的系统模型，建立开放课堂教学管理系统，实现对象类的定义、对象类的动态建模及物理建模，有利于提高教学管理系统的开放性、稳定性、可重用性。

关键词：开放课堂教学管理；UML；学习空间；动态建模

中图分类号：G434 文献标志码：A 文章编号：1673-8454（2016）11-0062-03

一、引言

2016年地平线报告提出学习空间重构的重要性，这就要求各院校建立新的教与学空间。高等职业教育变革的主要体现之一是采用理实一体化的教学课程模式，利用现代教育技术，将理论与实践，教与学，教室、工作室、实训室，知识、技能等一体化。系统从学习空间教学角度出发，采用.NET框架和MVC模式开发开放课堂教学管理系统，既能够实现学习空间动态、开放的教学，同时对职业院校学习空间的综合管理具有重要作用。从学习空间教学的角度出发，使用UML对开放课堂教学管理系统建设内容进行分析建模。系统合理规划，功能完善，方便师生共同使用，减少相关工作人员的工作量；实现学习空间上的资源共享，激发学习者的学习动机，学生完成社会性交互，促进学生主动参与，提升学习效果；学习空间管理方面，减轻管理员工作，采用信息系统的管理模式，学习空间主要实现项目课程的安排，师生通过访问服务器可以方便地查询、提交有关教学资源。

二、系统结构

系统根据教学需求把用户分为四类，有教师用户、学生用户、系统管理员用户、学习空间管理员用户。针对具体的用户，系统根据用户数据库提供的信息设置相应的权限和功能。学生使用这个系统可以运用个人密码登录，然后在线查看课程安排时间、地点，浏览工作项目信息，提交项目报告，修改个人信息，评定其他学生的工作项目，查看自己项目课程成绩；教学一线的教师登录这个系统主要是查询本人授课的班级，所在的地点、时间，评定学生学习空间平时的课程成绩，跟踪学生的互动信息，记录学生在开放课堂的表现，修改个人资料，申请使用学习空间并查看结果，申请设备，发布及管理项目报告资源；学习空间的管理人员登录系统进行学习空间项目信息管理，管理耗材信息，管理设备信息，检索并分配学习空间，审核学习空间申请，查看学习空间申请及学习空间安排；系统管理员登录本系统设置学习空间、学生、教师基本信息，设置工作项目设备信息，维护公告信息、学习空间排课系统等。

系统使用ASP.NET MVC模式来实现模型应用程序核心，实现在数据库中存取数据的功能，视图一方面将模型的数据接收并传递给用户，另一方面将用户的数据和请求传递给模型和控制器，控制器负责处理用户之间的交互，MVC将模型、显示和控制进行了分离，使一个模型可以具有多个显示视图，使应用更加方便。系统面向全体用户具有信息发布功能，能够完成项目提交、评定等功能，系统可以实现教师申请学习空间的请求，教师根据自己的教学计划合理安排教学并作具体分配，避免学习空间安排冲突，开放课堂教学管理系统结构如图1所示。

三、用例图

系统采用UML 在需求分析阶段的建模步骤，根据系统需求，从用户的角度描述出系统的功能，作为用例图执行时系统与操作者的一个交互过程，在捕获用户需求后，使用用例图对系统静态结构进行建模，定义系统的参与者，划分用例，建立用例图。

1.系统管理员用例图

系统管理员的主要需求是保障系统的正确运行，同时进行系统运行过程中基础数据的维护以及管理配置，具体包括基本信息配置，学习空间课程信息维护，系统用户数据管理，学习空间排课系统维护、实现、信息的发布，系统登录等。通过调查分析，学习空间课程信息维护包括项目课程信息导入，项目课程信息查询，项目课程信息添加、修改、删除等，参与查询项目课程信息的用户包括学生、教师、学习空间管理员等。将每个业务用例都绘制出相应的活动图，活动图用于研究实现一个工作过程、多个对象之间的合作，再将其中的各种“活动”整合，图2为系统管理员用例图：

2.学习空间课程教师用例图

学习空间课程教师登录系统，可以查询学习空间的设备情况、学习空间课程的申请情况，预约申请学习空间、设备、耗材，上传项目任务单，管理学生项目报告等，系统存储师生在学习空间的教学资源，为学生在线主动学习提供了有力保障，图3为学习空间课程教师用例图：

3.学生用例图

学生登录系统，一方面提交项目报告，查看项目课程成绩，进行自评互评，修改个人资料信息，查看课程安排，与系统管理员、课程教师、学生之间进行信息交流；另一方面系统及时记录学生学习过程并及时反馈给教师，教师可以随时随地了解学生的学习情况，图4为系统学生用例图：

四、系统的类

系统在建模过程中，以用例模型为输入，以MVC模式识别系统类、类的属性和操作，对类进行划分建立初步模型，之后确定类的属性和操作以及类之间的联系。Model部分包括后台的逻辑操作，访问数据库中的类，在.NET中写成独立的类文件，最后建立开放课堂教学管理系统的类图，系统的类分别是用户类、系统管理员类、学生类、教师类、项目类、班级类、学习空间类、院系类、专业类、排课类，图5为开放课堂教学管理系统的类图，每类的功能介绍如下：

用户类：用户类是所有类的父类，包括的属性有登录名、密码、用户邮箱等，方法有getAccount（）（获取登录账号）以及changePass（）（修改密码）。

系统管理员类：主要负责系统运行过程中基础数据的维护以及用户的管理配置，除了继承父类的属性和方法，管理员有自己的属性、电话号码。还有自己的方法：cerftfyUpload（）（文件的上传认证）、updaPageInfor （）（更新页面信息）、addUser（）（添加用户）和deleteUser（）（删除用户）等。

学生类：主要负责参与学习空间项目课程学生的基本信息的事务管理，除了继承父类的属性和方法，还包括学号、姓名、性别、年级、专业、班级编号、系部编号、电话、学生类别、邮箱等。对学生信息事务管理的主要操作有updateStuInfo（）（更新个人信息）等。

教师类：包括学习空间管理员与项目课程的教师，主要负责教师基本信息的事务管理，除了继承父类的属性和方法，还包括教师编号、教师姓名、性别、教授的课程、职称、系部编号、类别、电话等，对教师信息事务管理的主要操作有updateCourInfo（）（更新课程介绍）、updateTchIntro（）（更新教师介绍信息）等。

项目类：主要负责教师学生项目基本信息的事务管理，工作项目基本信息事务管理的主要操作有issue（）（项目发布）、delete（）（项目删除）和modify（）（项目修改）等。对项目课程事务管理的主要操作有修改项目课程信息的方法modify（），主要属性包括项目编号、课程编号、项目名称、项目总课时数、项目要求、课程名称、任务单号、专业编号、课程标准、考核类型、学习空间编号、用户类别、学习者特征、分组人数、首开时间、教学目的等。

班级类：主要负责班级的事务管理，主要属性包括班级编号、班级名称、专业编号等，对班级事务管理的主要操作有修改班级信息的方法modify（）等。

学习空间类：主要负责理实一体化学习空间基本信息的事务管理，主要属性包括学习空间编号、学习空间名称、负责教师编号、房间号、容纳人数、电脑数、是否分配等，对学习空间事务管理的主要操作有修改学习空间信息的方法modify（）。

院系类：主要负责系部信息管理，主要属性包括院/系编号、院/系名称等，对院/系事务管理的主要操作有修改院系信息的方法modify（）等。

专业类：主要负责专业信息管理，主要属性包括专业编号、专业名称等，对专业事务管理的主要操作有修改专业信息的方法modify（）等。

排课类：主要负责排课结束后的课表相关元素信息管理，主要属性包括学习空间编号、项目编号、教师编号、教学周次、教学日次、教学节次、项目批次、容纳上课人数等，对排课事务管理的主要操作有自动排课autoCourse（）、手动排课manualCourse（）、冲突检测conflictDetection（）、统计分析statisAnalysis（）、报表输出reportOut（）等。

五、开放课堂教学管理系统中对象的动态建模

系统的动态建模的主要作用是描述个对象间消息的实时变换和相互作用等，开放课程教学管理系统，系统中内部对象间的通信采用UML建模方式进行描述，系统从用户的主要用例间的交互出发，在用例图的基础上建立时序图。具体的动态建模的流程是：系统管理员进行验证后登录系统，对学生、教师、课程的信息进行管理；学习空间管理员进行验证后登录系统，可查看课程、课程项目信息，审批预约申请，查询学习空间设备；学生进行验证后登录系统，可以对项目课程信息和考核成绩进行查询，就学生个人信息进行个性化设置等；教师进行验证后登录系统，可以查看项目课程、学生信息，同时也可对教师的个人信息进行个性化设置和实时观察学生的学习过程等。

六、结束语

开放课堂教学管理系统以高职院校理实一体化课程的学习空间为基础，结合学习空间教学管理的工作流程，开发Web应用系统，采用统一建模语言UML在系统中的应用，提出系统的静态和动态结构，系统经过反复调试使用，目前运行稳定，各基本条件设置较为满足，达到合理分配学习空间资源的效果，满足院校学习空间教学管理系统的优化与实现。

参考文献：

[1]李雄杰.职业教育理实一体化课程研究[M].北京：北京师范大学出版社，2011.8.

[2]柏依彤.基于校园网的高校毕业设计选题系统的建模与设计[D].成都：电子科技大学，2011.

[3]刘冰，刘锐.软件体系结构原理、方法与实践[M].北京：清华大学出版社，2014.1：128-153.

[4]李志河.基于Web的高校教师绩效考评系统的研究[J].电化教育研究，2011（11）.

[5]陈艳艳，施珺.构建网络化教学质量监控系统的探索与实践[J].中国教育信息化，2010（13）：54-55.

[6]王振，陈军.基于UML对高校教务管理系统的分析与建模研究[J].延边教育学院学报，2015（1）：55-58.

[7]毛睿.基于UML的教学质量监控系统设计[J].电脑知识与技术，2014（31）：7377-7381.