uml教务管理系统

uml教务管理系统（通用8篇）

uml教务管理系统 篇1

随着高校校园网的建设和Internet技术的引进，基于校园网和Internet的应用系统的开发正在蓬勃发展。教务管理师高校教学管理的一向重要工作，现代化的高校教务管理需要现代化的信息管理系统支持。新世纪背景下，高校教育体制进行了大规模的改革，招生人数逐年增加，教学计划不断更新。在高校日常管理中，教务管理无疑是核心工作，重中之重。其管理模式的科学化与规范化，管理手段的信息化与自动化对于学校的总体发展产生深远的影响，由于管理内容过多，繁琐，处理的过程也非常复杂，并且随着学校人员的增加，教务管理系统的信息量大幅上升，因此往往很难及时准确地掌握教务信息的运作状态这使得高校教务管理的工作量大幅度增加，另外，随着教育改革的不断深化，教学管理模式也在发生变化，例如实施学分制、学生自主选课等。这一切都有赖于计算机网络技术和数据库技术的支持，在这样的形势下建立和完善一个集成化的教务管理系统势在必行。

目前，国内高校都开发了自己基于校园网的教务管理系统。由于其教务管理模式不尽相同，不同学校的实际教务管理情况各有自己的特点，因而各高校需要针对自己的教务管理模式和特点建立自己的教务管理系统。本设计是基于某高校的教务管理模式开发的基于校园网的教务管理系统。这样一个系统不仅可以降低工作量、提高办公效率，而且使分散的教务信息得到集中处理，对减轻教务工作负担、提高教务管理水平、实现教务管理的现代化具有重要意义。

1.建立系统用例模型

1.1确定系统模型的参与者

仔细分析教务管理系统问题描述。在UML中，角色代表位于系统之外和系统进行交互的一类对象，本系统中创建主要的角色有以下三类：

（1）教务员：教务员在教学管理系统中对全体学生进行用户登录、学籍管理、选课管理、教学管理和成绩管理，并且对教师进行登录管理、教学管理和成绩管理。教务处工作人员处理日常的系统维护，例如维护和及时更新学生，教师信息以及安排选课等。

（2）教师：教师根据教务系统的选课安排进行教学，将学生的考试成绩录入此系统。（3）学生：学生能够在教务管理系统更改学籍信息、进行选课、查询已选课程和考试成绩。

1.2识别用例

用例是系统外部参与者与系统在交互过程中需要完成的任务，识别用例最好的方法就是从分析系统的参与者开始，考虑每一类参与者需要使用系统的哪些功能，如何使用系统，根据教务管理系统的运行流程个提取的参与者信息，确定系统分为以下几个用例：(1)学生参与者用例：

 用户登录  学籍管理  选课管理(2)教师参与者用例：

 用户登录  成绩管理  教学管理

(3)教务员参与者用例：

 用户登录  学籍管理  排课管理     成绩管理 选课管理 教学管理 系统维护

1.3建立如下四个用例图模型

（1）顶层用例图如图1-1所示

图1-1顶层用例图

从用例图1-1可以看出学生、教师和教务员都使用了“用户登录”用例，表示学生必须先进行用户登录后才可以进行学籍管理和选课管理。同理，教师也必须登录后才能进行成绩管理和教学管理。教务员登录后进行系统设置、学籍管理、排课管理和教学管理等操作。

（2）学生角色用例图 如图1-2所示

图1-2学生角色用例图

从用例图1-2可以看出学生登录后才能进行所有的操作，这样可以提高系统的安全性。（3）教师角色用例图如图1-3所示

图1-3教师角色用例图 从用例图1-3可以看出教师所有的用例都是建立在“用户登录”基础上，表示教师必须先登录后才可以执行相应的功能，这样可以提高系统的安全性，以免有人故意提供虚假信息。（4）教务员角色用例图如图1-4所示

图1-4教务员角色用例图

从用例图1-4可以看出教务员的用例相对较多，但是教务员的所有的用例都必须在“用户登录”的基础上，表示教务员必须先登录才可以执行相关的功能，这样同样可以提高系统的安全性，避免有人故意更改信息。建立系统动态模型 2.1活动图

经过活动图的建模可以比较清楚地了解整个进程过程的操作过程，本系统中主要的活动图有如下几个：学生成绩查询活动图、教务员修改学生资料活动图、学生选课活动图以及教师成绩录入活动图

（1）学生成绩查询图如图2-1所示

图2-1 学生成绩查询活动图

从图2-1可以看出，活动图分为多个不同的泳道，每个泳道表示学生在查询成绩活动中不同参与者的工作流。每个泳道中的活动是参与者要执行的操作。通过不通泳道之间的活动过渡，可以了解参与者之间的通信。这些信息可以帮助我们更好地理解系统的业务过程。

在学生成绩查询活动图中可以知道，学生、教师和教务员之间存在着相互联系。学生登录以后可以查询已选科目和成绩单，如果发现自己的成绩单有错误后可以通知教务员成绩有误，教务员联系教师后，教师修改成绩，然后教务员更新数据库。成绩无误后，查询结束。

（2）教务员学生资料修改活动图如图2-2所示；（3）学生选课活动图如图2-3所示；

图2-2教务员学生资料修改活动图图2-3学生选课活动图

从图2-2可以看出，教务员登录教务系统，系统验证用户名和密码，若有错误重新输入，无误后进行选择修改项目，确定修改，图2-3学生选课活动图图2-4 教师成绩录入活动图

2.2顺序图

主要包括如下几个顺序图 ①教务学籍管理顺序图 ②学生注册顺序图 ③学生选课顺序图 ④教师成绩录入顺序图

图2-5教务学籍管理顺序图

图2-6学生注册顺序图

图2-7教师成绩录入顺序图

3系统类模型 3.1系统包图

将整个教务管理系统划分为人员信息、接口和事务3个包，分别控制不同的应用。

3.2类图

根据系统划分的三类包图，分别讨论人员信息包，接口包和事务包中的类图分别为：（1）人员信息包内的类图（2）接口包内的类图（3）事务包内的类图

图3-1 人员信息包内的类图

图3-2接口信息包内的类图

uml教务管理系统 篇2

关键词：UML建模,选课,静态建模,动态建模

1、引言

高校教务工作在高校的发展和建设中占有重要的地位, 是高校管理工作的重要组成部分, 是颇为复杂又非常重要的工作。统一建模语言 (Unified Modeling Language, 简称UML) 定义良好、易于表达、功能强大且普遍实用, 不但支持面向对象的分析与设计, 还支持从需求分析开始的软件开发的全过程[1]。使用UML进行系统的分析和设计, 可以加速开发的进程, 提高代码的质量, 支持动态的业务需求。在教务管理系统设计的需求定义、系统分析、系统设计等各个阶段利用UML建模语言进行建模, 有助于提高开发效率、降低开发风险[2]。本文以教务系统中的学生选课模块为例论述了UML建模的方法。

2、UML建模机制

建模是面向对象分析和设计的核心, 也是分析和设计过程中最基本和关键的活动之一[3]。UML描述了一个系统的静态结构和动态行为, 将系统描述为一些离散的相互作用的对象并最终为外部用户提供一定功能的模型结构。静态结构定义了系统中重要对象的属性和操作以及这些对象之间的相互关系。动态行为定义了对象的时间特性和对象为完成目标而相互进行通信的机制。为了支持从不同角度来考察系统和描述软件系统从需求分析到软件测试开发的全过程, UML定义了下列图来表示:

(1) 用例图:用来描述系统边界和主要功能, 并指出各功能的操作者。

(2) 静态图:包括类图、对象图和包图, 用来描述系统的静态结构。

(3) 行为图:包括状态图和活动图, 用来描述对象的动态特征。

(4) 交互图:包括顺序图和协作图, 主要通过对象间的交互关系来描述系统的动态实现。

(5) 实现图:包括构件图和配置图, 构件图描述代码部件的物理结构及各部件之间的依赖关系;配置图定义系统中软硬件的物理体系结构。

其中, 用例图、静态图、实现图是用于静态结构建模, 行为图和交互图用于动态行为建模。

3、教务管理系统UML建模

3.1 教务管理系统需求分析

教务管理系统是整个学校管理系统的一个重点, 根据湖北大学的实际情况, 从业务角度来分析, 本校的教务管理系统照功能模块划分成以下十个功能模块:课程库和培养方案管理、年级教学计划管理、课程管理、选课模块管理、考试管理、成绩管理、学生学籍管理、教师信息管理、教学场所管理、系统模块管理。

3.2 系统建模

在本节中, 将以选课模块为例进行UML建模。首先进行静态建模, 以用例图来规范化地描述学生选课模块的功能, 帮助我们更好地了解系统需求, 以类图来描述选课模块的结构化设计;其次进行动态建模, 以活动图来描述学生选课模块中整个交互过程。

3.2.1 静态建模

需求分析的主要工作是获得系统需求, 而用例图和类图主要用于描述系统的需求。用例图是系统功能分析的重要工具。类图可以从系统实施的角度描述整个系统。下面将分析学生选课模块的用例图和类图。

(1) 选课模块用例分析

建立用例图首先要确定系统的边界和角色。角色是指在系统外部和系统进行交互的某类人, 也可以是某个系统。可以根据每个角色感受到的功能来描述系统的完整功能。

依据湖北大学的实际业务情况, 在教务管理系统的学生选课模块中, 其功能包括三部分:第一部分包括学生选课设置, 学生选课数据查询, 学生选课数据统计, 学生选课门数统计, 学生名册的打印, 初始化选课课程, 设置停开课程, 这些功能属于教务处使用;第二部分包括综合选课、分级课选课、公共选修课选课、大学体育选课、重修课选课、查询选课结果、查询个人课表、退课, 这些功能属于已经注册的学生使用;第三部分公共课表查询包括按专业、教师、教室、时间查询, 这些功能属于所有用户 (包括教务处、各个学院的教学秘书、教师、学生、匿名用户) 使用。

选课模块功能结构图如图1所示:

分析该模块可以得到的角色有:教务处、各个学院的教学秘书、教师、学生、匿名用户。经过对选课模块中这些人员的角色进行分析后得到顶层用例图, 如图2所示。

对顶层用例图进行细化, 得到二级用例图中的选课设置, 如图3所示:

通过用例图规范化的描述, 可以进一步明确了系统的功能, 使用户和开发者双方可以从高层次把握系统的的主要功能, 为后续的设计打下坚实的基础。也为系统开发编码阶段提供清晰的有关角色、权限的指导。

(2) 选课模块类图分析

在建立系统的静态模型中, 进一步工作是确立系统的类图。类反映了一种面向对象方法看待物理世界的观点, 它是面向对象的标志。建立类图的过程, 实际上是对现实世界的一个抽象过程, 它扰现实世界中与问题有关的各种对象及其相互之间的各种关系进行适当的抽象和分门别类的描述。UML的最终目标是识别出所有必须的类来, 确定类的属性和操作, 分析这些类之间的关系, 从而通过编程语言来实现这些类, 并最终实现整个系统。

按照功能的不同, 一般将类划分为:边界类、控制类和实体类。边界类一般位于系统与外界的交界处, 工作在系统和角色之间。通常边界类用作屏蔽或媒介, 隔离了如何取得应用程序提供的服务的大部分交互细节, 因此, 通常又被称为"接口类"。例如, 注册窗口、登录窗口、报表、表示通讯协议的类、直接与外部设备或外部系统交互的类都属于边界类。控制类是指控制其它类工作的类, 一般来说, 每个用例都对应于一个控制类, 它控制用例中的事件顺序。控制类用于对一个具体用例的控制或其他业务逻辑建模。实体类表示了应用领域的核心内容, 主要是指保存要放进持久存储体 (如保存到数据库和文本文件) 的信息, 并提供用于驱动应用程序中大多数交互所需要的服务。通常, 实体类都是一些直接的对象, 类名都是简单的名词, 例如学生、教师、课程等。而且每个实体类在数据库中都有相应的表, 实体类的属性对应数据库表中的字段。

对类的识别, 通常的方法是从用例中来识别。用例图实际上就是一种对系统描述的形式, 因此, 可以根据用例图来识别类。根据选课模块的用例图, 可以发现此模块主要包含学生基本信息、选课课程、选课设置这三个实体类。学生基本信息类属性有学号、姓名、年级、专业等;选课课程是指在课程安排模块进行了定课程、定时间、定地点、定教师、定教材后的一个特定课程, 其主键是教学班ID, 它是专门用于选课的实体类;选课设置类包含了可选门数、选课时间等设置信息。

类间的关系主要有关联、依赖、泛化、聚合、组合等。它们的含义如下:

关联:表示不同类的对象之间的结构关系, 它在一段时间内将多个类的实例连接在一起 (这与依赖关系不同, 依赖关系表示两个实例之间的临时关联关系) ;

依赖:对于两个相对独立的系统, 当一个系统负责构造另一个系统的实例, 或者依赖另一个系统的服务时, 这两个系统之间主要体现为依赖关系;

泛化:表示一个类对另一个类的继承;

聚合:表示整体与部分的关系。通常在定义一个整体类后, 再去分析这个整体类的组成结构。从而找出一些组成类, 该整体类和组成类之间就形成了聚合关系;

组合:也是表示类之间整体和部分的关系, 但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在, 部分对象也将不存在。部分对象与体对象之间具有共生死的关系。

选课模块包含学生基本信息、选课课程、选课设置这三个实体类。一个学生可以选多门课程, 一个课程也可以被多个学生选, 因此学生基本信息与选课课程之间是多对多的关联关系, 于是产生了一个选课结果的关联类, 教学班ID与学号作联合主键;选课设置是针对学生选课的, 一个学生必定受一条选课设置条件的约束, 一个选课设置可以约束多个学生, 因此学生基本信息与选课设置是多对一的关联关系。详细的类图如图4所示:

一般的, 类图描述了系统在运行时所有数据必须满足的通用特征, 在类图中每个实体类在数据库中都有相应的表, 实体类的属性对应数据库表中的字段。因此通过类图的建立, 可以为数据库实施阶段提供清晰的指导。

3.2.2 动态建模

在建立好系统的静态模型后, 需要分析和设计系统的动态结构, 建立相应的动态模型, 从而更好地理解用例的行为。在UML中可以通过行为图 (包括状态图和活动图) 和交互图 (包括顺序图和协作图) 来实现动态建模。对于某些复杂的实时系统, 系统状态变化较多, 可以通过状态图来描述类的对象所有可能的状态以及事件发生时状态的转移条件。合作图与顺序图相似, 顺序图强调的是交互的时间顺序, 合作图强调的是交互的语境和交互对象的整体组织。顺序图按时间布图, 合作图按空间布图, 它们之间是等价的, 可以互换。活动图可以细化用例, 描述系统功能性行为, 并且描述用例之间的顺序依赖关系;也可以理解和建模业务过程和工作流, 处理多线程应用;甚至可以用于描述复杂的计算型算法。为了清楚的表达需求, 这里用活动图来对选课流程进行更详细的描述。图5是选课模块活动图。

结束语

在实际UML建模中, 静态模型和动态模型并不是完独立的两个过程, 它们是相辅相成, 不可分割的一个整体静态模型是动态模型的基础和主要依据;动态模型可以补充和完善静态模型。

UML作为一种建模语言, 应用于各种系统的设计与分析, 改变了传统的软件设计思想, 降低了系统设计的盲目性, 也更有利于系统的扩展与测试。本文在简述建模技术的基础上, 结合教务管理系统的实际需求, 以选课为例给出了详细设计应用实例, 在此设计思想上开发出来的湖北大学教务综合管理系统已经稳健运行了一年, 现仍在运行中, 在湖北大学管理工作中发挥着举足轻重的作用。随着UML的进一步发展, 软件的开发设计必将更加高质高效。

参考文献

[1]Craig Larman著.姚淑珍, 李虎译.UML和模式应用面向对象分析与设计导论[M].北京:机械工业出版社, 2002.

[2]李逦, 赵鑫.基于UML的教务管理系统的设计与实现.辽宁行政学院学报[J].2009, vol 11 (8) :156-157

基于UML的钥匙集中管理系统 篇3

[关键词] UM 指纹识别 钥匙集中管理 仿真系统

本系统的钥匙存取认证[1]除了采用指纹识别技术外，还加入了钥匙在位识别技术、软件智能控制和网络输出技术，技术可靠稳定，能有效的杜绝非法使用钥匙事件的发生；系统所管理的钥匙“锁扣”在专用钥匙孔上，存放在钥匙柜内，不通过正常的指纹认证，无法打开柜门及取出钥匙；操作使用人员存取钥匙后，由计算机进行登记记录，并可打印该记录；本系统具有报警功能，当非法打开柜门及非法拿取钥匙，或超时交还钥匙，系统发出报警。

一、系统工作原理跟功能模块

1.系统工作原理

每名鑰匙操作者经过授权，可管理一把及多把钥匙。通过输入指纹，验证指纹通过后则钥匙柜门自动开启，属于该操作者管理的相应钥匙释放，指示灯亮，操作者取走钥匙，关闭柜门。此过程计算机则自动记录(某位操作者于某日，某时取走某把钥匙)。当归还钥匙时同样先验证指纹，验证通过后，柜门开启，将钥匙还入相应钥匙位中，关闭柜门。

2.时间模块

时间模块分为权限时间判断和定时器计时两个模块。权限时间判断模块：当操作者在通过本地指纹验证之后，系统再将操作者的信息发到服务器上进行操作时间段的判断和操作权限审批结果的确认，在与服务器确认通过后，才有打开门的权限，否则以警告提示。定时器计时模块：主要是来防止操作者超时操作，主要判断钥匙柜大门与小门打开与关闭的时间，如果操作超出系统设置的时间，则系统发出警告提示并记录日志。

3.日志模块

通过操作日志模块，该系统每一次操作都会在操作日志表中有相应的记录。这样可以增强操作人员的责任感，提高系统的安全性。此外，一个真实的操作日志，也给开发过程中的调试、除错带来很大便利。

4.身份权限验证模块

身份验证功能主要是确认操作人员身份和权限的，当操作人员输入指纹信息不对时，系统将给出警告提示，并记录出错次数同时记录错误操作日志，当操作人员身份验证成功后，并开启打开大门权限(如果是管理员的话，再开启系统管理权限)，在打开大门的同时，记录钥匙权限信息。权限控制模块主要是控制钥匙柜小门开启的权限，当操作者通过验证身份后，打开大门，可以进行小门操作。打开的钥匙柜分为两个部分：小钥匙柜集（共有30个小门）、信息显示栏。信息显示栏主要显示对小钥匙柜的操作说明和操作者有权取出的钥匙，当操作者无权取钥匙的话，系统会给出警告，有权限的话进入小门，钥匙不在位的话系统给出提示。

二、操作实例进行说明

操作者在使用钥匙之前，必须先通过网络向审批系统进行钥匙使用申请。申请内容应包括将要使用的钥匙号，取钥匙的日期时间，归还钥匙的日期时间等。经审核人员审批后，申请获得通过。操作者按申请时间进行取钥匙时，在钥匙柜指纹机上进行指纹验证。指纹识别通过后，钥匙柜系统将操作者的信息传给审批系统。钥匙柜系统根据审批系统返回的申请审批信息，将对应的钥匙箱小门自动打开，并自动打开钥匙柜的大门。操作者旋动钥匙开关，取走相应的钥匙。操作者在取走相应的钥匙后，必须先关闭所有钥匙箱小门，再关闭钥匙柜的大门。

钥匙柜系统将记录下操作者每个操作动作，作为操作日志保存到本钥匙柜系统中。并在钥匙柜大门关闭时，将此次开柜所有日志传送到审批系统予以保存。当钥匙用毕归还时，操作者首先在钥匙柜系统上进行指纹验证。指纹识别通过后，钥匙柜系统根据（在取钥匙时已获得的）申请审批信息，将对应的钥匙箱小门自动打开，并自动打开钥匙柜的大门。操作者插入钥匙并旋动钥匙开关，归还相应的钥匙。操作者在归还相应的钥匙后，必须先关闭所有钥匙箱小门，再关闭钥匙柜的大门。钥匙柜系统将自动记录下操作者每个操作动作，作为操作日志保存到本钥匙柜系统中。并在钥匙柜大门关闭时，将此次开柜所有操作日志传送到审批系统予以保存。

三、市场需求分析

钥匙集中管理系统主要是针对一些重要部门和场所，有较大量的钥匙需要集中管理而设计的，它具有安全、方便、管理功能强等特点。能对所授权的钥匙进行严格的管理，并能详细的记录钥匙使用者的情况。尽最大可能地解决了因钥匙管理不当引发的各种问题和事件。该系统是在积累了丰富业务经验的基础上进行开发的，在需求上，充分考虑了具体用户的实际情况。

可以发挥以下作用:

确保钥匙的有序使用，并使之置于领导监督、控制下;有钥匙操作历史记录可查询，可以明确责任;对越权、错误操作报警，方便管理员及时处理;提高钥匙使用效率，防止越权操作，明确责任。

四、结论

通过对本系统的设计与研究，充分认识到钥匙集中管理系统的重要性，特别是在一些重要部门与场所，目前为止，钥匙集中管理系统技术还没有完全成熟，仍存在一些问题，本文通过软件仿真来实现了钥匙集中管理系统的全部功能，将本仿真系统应用到实际管理钥匙的部门并加以修改完善，就会得到一套功能更加完整的钥匙集中管理系统。

参考文献：

[1]李德良陈永利刘艳玉:基于单总线的钥匙柜管理系统[J]. 电子技术, 2003

[2]月殷兆麟:UML及其建模工具的使用[M].北京:清华人学出版社，2004

[3]王松:四川中外科技文化交流中心.Visual C++ 6.0 程序设计与开发指南[M].高等教育出版社, 1999

电影院售票管理系统UML 篇4

1.1业务需求

1.背景、业务机会和客户需要

随着社会的发展，人们生活水平的提高，欣赏电影逐渐成为人们闲暇时的主要娱乐方式之一。传统的电影售票都是人工服务，观看作为都是人共安排，无法体现人性化选择，加上现在人们的生活节奏越来越快，购票时间需要相应缩短以及方便定影院工作人员的管理，因此充分利用现代信息化、因特网的优势，设计电影院售票管系统，对提高系统建设的工作效率，提高信息的及时性、减轻各级相关工作人员的劳动强度是非常有必要的。一个完善的电影院售票管理系统，可以帮助电影院工作人员提升工作效率，辅助电影院工作人员进行相关数据的输入、输出、查找、管理等操作，让电影院售票数据变得合理化、具体化、直观化。2.业务目标（Business Objective,BO）和成功标准（Success Criteria,SC）BO-1：初始版本发布之后的6个月内，电影院的收入提高20%。

BO-2：初始版本发布之后的3个月内，每个员工每天的平均有效工作时间增加20分钟。

SC-1：初始版本发布后的6个月内，电影院收入显著提高。

3.业务风险（Risk）

RI-1：使用该系统的顾客太少，减少了对系统开发和维护过程的投资回报

1.2解决方案的前景

1.前景陈述

该系统的开发，可以提升电影院工作人员的管理效率，使得售票、检票不再那么繁琐；也大大的节约了人们排队购票的时间，同时也让人们有了更多的选择范围。2.主要特性（Feature）

FE-1：根据电影院提供的当天的播放场次选择订票 FE-2：注册订票的付费方式

FE-3：创建、浏览、修改和删除电影场次 FE-4：通过公司的内联网可以访问系统，或者授权的员工通过外部Internet访问系统 3.假设（Assumption）和依赖（Dependency）

1.3范围和局限性

1.初始版本和后续版本的范围

目前仅实现1.0版本，实现上述的所有功能。2.局限性（Limitation）和排斥性

LI-1：“电影院售票管理系统”只能支持开通网银的用户在线使用，未开通的需到影院购买。

1.4业务上下文 1.涉众概览

涉众

系统管理员 主要价值

引进新影片，更新数据库

态度

主要兴趣

使用该系统所节约的费用必须超过开发此系统的费用和使用此系统的费用

约束条件

无

员工 更高效率的利用了工作人员的整个工作时间；提高了客户的满意度

保住工作 培训工作人员，掌

握

使

用

Internet所必须的技能

顾客 可以更好的选择电影、座位、场

积极支持新系统，但使用系统

使用要简单，更节约时间

需要登录该公司的内联网

次；节约了时间，的次数可能没有更加方便

期望的高

2.项目优先级

因素

进度 具体干活者

约束条件

自由度

计划3/1/03前完成第一版，到5/1/03前完成第二版；在不包括责任人评审的情况下，最多可超过期限三星期

特性

安排1.0版本实现的特性必须完全可操作

质量

必须通过95%的用户验收测试；必须通过全部的安全性测试；所有的安全事务都必须遵守公司的标准

工作人员 项目团队包括一名半日工作的项目经理，两名开发人员，和一名测试人员

费用

在不包括责任人评审 的情况下，财政预算最多可超支15%

2.用例

各种用户类确认的“电影院售票系统”的用例和主要参与者如下表示： 主要参与者

用例

顾客

1.订票

2.变更订单

3.取消订单

4.查看订单

5.登陆网站 员工

6.处理订单

7.检票

8.更新余票 系统管理员

9.引进新片

10.更新数据库

11.添加、更改、删除员工信息

12.添加、删除、修改客户账户

用例ID号

UC-1 用例名称

订票 参与者

顾客

主要参与者

用例

描述

顾客登录网站访问”电影院售票管理系统“，随意查看某

一天的上映电影，选择自己想看的电影，选定场次、座位，提交订单并在付款界面支付

前置条件

1.顾客成功登录，并访问“电影院售票管理系统“

2.付款成功 后置条件

1.订单在“电影院售票管理系统“中的存储状态是

“已接受“

2.根据这一订单来更新余票

主干过程

1.0 订一张票

分支过程

异常

1.顾客要求查看某一天的上映表 2.系统显示当日上映电影、场次及余票 3.顾客选择自己喜欢的电影场次 4.顾客表明订票完成 5.系统显示所订票价格

6.顾客确认订单或请求修改订单（回到第3步）7.顾客付款 8.系统确认接受订单

9.系统向顾客发送电子邮件，确认订单细节，价格10.系统将订单存储在数据库中，并更新余票

1.1订多张票（第4步之后分支出来）

1.顾客要求预定另一场次的电影 2.返回到第2步

1.2同样的票订多张（第3步之后分支出来）1.顾客请求预定指定数量的电影票

2.返回到第4步

1.0.E.1

订单截止时间在当前时间之前（第1步）

1.系统通知顾客今天订票已经太晚了 2a.顾客取消订单 2b.系统终止用例

3a.顾客请求选择另一个日期 3b.系统重新启动用例

1.0.E.2

票全部售完（第1步）

1.系统通知顾客今日已没有余票 2a.顾客取消订单

2b.系统终止用例

包含

优先级

使用频率

业务规则

特别需求

假设

注意和问题

用例ID号

用例名称

参与者

描述

前置条件

1.0.E.3 不能完成同样的票订多张（第1步）1.系统通知顾客它所能提供的该票最大值 2.顾客变更订单数量，或者取消订单

无

高 无 无

1.顾客在确认订单之前的任何时刻都可以取消订单

无 1.如果客户在今天的截止时间之前使用系统，那么默认的日期是当前日期，否则，默认日期为下一个营业日 2.这一用例的峰值使用负载是当地时间早十点到晚十点

UC-6

处理订单 员工

员工根据用户提交的订单，查询是否有余票及对应场次、座位，判断是否接受订单

1.用户

3．软件需求规格说明

3.1介绍

1.目标

软件需求规格说明描述了“电影院售票管理系统”1.0版本的软件功能性需求和非功能性需求。这一文档计划实现和验证系统正确功能的项目团队成员来使用。除非在其他地方另有说明，这里指定的所有需求都具有高优先级，而且都要在版本1.0中加以实现。

2.项目范围和产品特性 “电影院售票管理系统”允许顾客在线订购电影票，并且可以修改取消订单。详细的项目描述请中参见电影院售票管理系统前景和范围文档。文档中的这一部分标题为“初始版本和后续版本的范围”，列出了按照进度计划在这一版本中实现的全部或部分特性。

3.参考文献

（1）Karl Wiegers所著的Cafeteria Ordering SystemVision and Scope Document,其网址是代码遵照HTML4.0标准 CO-4：所有脚本都用Perl语言来编写 5.用户文档（User Documentation，UD）

UD-1：系统将提供一个分层的和跨连接的HTML联机帮助系统，它描述并演示了所有系统功能

UD-2：如果是一个新用户第一次使用该系统，系统可以根据用户的要求，提供一个联机教程，咋这样用户可以使用静态教程来具体实践一下如何订票。系统不会将采用这一模板的订单存储到数据库中，也不会将这种订单提交给系统。

6.假设（Assumption）和依赖（Dependency）

3.3系统特性

1.订票

（1）描述和优先级

顾客在其身份得到验证后，就可以订票，只要所订票还没有超过播放时间，顾客就可以取消或改变订单。优先级为高。（2）刺激/响应序列

刺激：顾客请求订票，可以是一张或多张 响应：系统向顾客询问订票细节、付费方式 刺激：顾客请求改变订单

响应：如果订单状态是“已接受”，则系统允许用户编辑以前的订单 刺激：顾客请求取消订单

响应：如果订单状态是“已接受”，则系统取消订单（3）功能性需求

 登录到“电影院售票管理系统”的顾客可以通过该系统订票，订一张或多张都可以

 顾客可以浏览当天的上映电影  顾客可以选择电影场次及座位

 如果顾客所订票数超过了现在余票的最大值，系统将通知顾客他能订购的最大值

 顾客可以修改订单，删除订单

 当顾客订购完成后，系统将提示顾客付款  顾客可以浏览已订票信息

 订购成功后，系统将发送电子邮件提示用户订购价格及细节

（4）非功能性需求 安全性：系统应保证客户信息不被泄露

可维护性

及时性：用户点击最多不超过3秒，系统应给予相应的响应

3.4外部接口需求

1．用户界面（User Interface，UI）

UI-1：“电影院售票管理系统”的屏幕画面将遵照Process Impact Internet Application User Interface Standard版本2.0 UI-2：系统对所显示的每个HTML网页都提供帮助链接，解释如何使用这些网页

UI-3：Web页面的全部导航和票目选择，除了综合使用鼠标和键盘共同完成外，还可以只通过键盘来单独完成

2.硬件接口

硬件接口还没确定

3.软件接口（Software Interface，SI）还没确定

4.通信接口（Communication Interface，CI）

CI-1：“电影院售票管理系统”将向顾客发送电子邮件消息，以确认收到订单、价格。

CI-2：“电影院售票管理系统”奖项顾客发送电子邮件信息，以报告接受订单后存在的问题。

系统管理员对账户操作的活动图

登录系统进行账户维护员工账户顾客账户添加账户修改账户删除账户添加删除修改退出系统

顾客登录系统的时序图 顾客登陆界面服务器数据库输入帐号密码发送帐号密码到服务器查询验证帐号密码查询验证成功将信息发送到界面提示用户登录成功

顾客订票的活动图

查找登录NO浏览预订判断是否登录判断是否有余票YESNO选择场次、座位退出系统付款

员工处理退票的活动图

登录查询客户订单判断是否有退订YESNO查询电影场次时间超时拒绝退出系统接收退票申请退钱通知顾客进度更新余票

员工处理订单的活动图

网上教学系统的UML设计 篇5

课程报告

题目：网上教学系统的UML设计

分数：

学期：

班级： 学号： 姓名： __ ___ 授课教师： __

一、需求分析

网上教学系统基本分为三个模块：

1、教师模块：教师在教学网站上通过登录教学系统，进行输入课程介绍、上传课件、发布消息、修改和更新消息。

2、学生模块：学生在教学网站上通过登录教学系统，进行浏览信息、查找信息、下载文件。

3、管理员模块：管理员通过登录教学系统，对页面维护、批准用户的注册申请。

二、用例模型

设计系统首先需要进行用例图的建立，所以在此进行参与者确定。

1、在网上教学系统中，教师为参与者之一。教师作为教学直接实施者，需要在网上教学系统中进行进行输入课程介绍、上传课件、发布消息、修改和更新消息，如下图教师用例图所示。

图1：教师用例图

2、学生是网上教学系统的重要参与者。学生作为教学受益者，需要在网上教学系统中进行浏览信息、查找信息、下载文件。其用例图如下图所示。

图2：学生用例图

3、管理员也是网上教学系统的参与者之一，作为系统的维护人员，管理员需要在系统中进行页面维护、批准用户的注册申请。下图为管理员用例图。

图3：管理员用例图

三、静态模型

进行网上教学系统程序设计需要先绘制出类图，以便程序的编写。用户类操作为登录；

学生类操作处了登录、注册外还有浏览、下载、查询。教师类操作有登录、注册、上传、修改、发布。管理员类操作为基本管理和系统维护。下图为网上教学系统的类图。

图4：用户类图

四、动态模型

4.1、顺序图

4.1.1、学生模块下载课件顺序图

图5：学生下载课件顺序图 4.1.2、学生模块浏览页面顺序图

图6：学生浏览页面顺序图

4.1.3、教师模块上传课件顺序图

图7：教师上传课件顺序图 4.1.4、教师模块修改信息操作顺序图

教师在教学系统上的操作以及教学系统自身运作。

图8：教师修改操作顺序图

4.1.5、管理员模块顺序图

管理员与教学系统及教学系统与信息数据库之间的交互。

图9：管理员顺序图

4.2、协作图

4.2.1、学生协作图

图10

图11 4.2.2、教师协作图

图12

图13 4.2.3、管理员协作图

图14

4.3、状态图

网上教学系统的基本流程为：用户在首页输入网上教学系统的地址，在登录界面输入用户名以及密码，系统验证，若成功则进入下一个状态，若不成功则返回上一界面。验证成功时分为三种情况，为管理员用户则跳转管理员模块；为教师用户则跳转教师模块；为学生用户则跳转学生模块。其状态图如下：

图15：系统状态图

4.4、活动图

网上教学系统的总活动图：

图16：系统活动图

五、总结

在进行网上教学系统的UML设计时，需要对Rose软件有一定的了解，并会使用其进行各种图的建立，明白不同图的绘图规则以及所需主要项。

网上教学系统的UML设计主要为对用例图、类图、顺序图、协作图、活动图、状态图的建立。分析出系统的对象以及功能，这需要对面向对象设计有一定的了解，明白系统中各个部分的内容和功能。

基于UML的网络购物系统的分析 篇6

摘要：论文简单的描述了UML的基本概念和发展历史，并且分析了目前运用UML存在的一些问题，通过在实际的设计开发中运用UML对网络购物系统的开发例子来阐述UML的一些实现原理。

关键词：对象管理组织统一建模语言 [Abstract]: [key words]：

1.UML简介和背景：

2.目前运用UML存在的一些问题：

自从OMG（）提出UML以来,随着它的不断完善发展, UML逐渐被很多企业接受认可, 在很短的时间内，UML已经成为软件工业中占支配地位的建模语言。但目前在国内外UML的运用情况却不是很好。2002年6月底,BZ公司对226个个体进行了调查,结果是有34%的开发人员运用UML进行系统开发的建模,62%的开发人员不用UML进行开发,4%的开发人员不太确定[1].究其原因是UML1.4还存在以下几个方面的不足: 第一，目前UML很多地方运用难以解释的字符来描述系统的功能、系统的行为和计算,不易于理解。并且没有对数据操作进行定义,很多对象之间的行为过程没有加以说明，如：对象之间关系的操作（relationship manipulation），这些都迫切需要一个标准化的行为描述语言(Action Specification Language)来对系统的行为进行精确的描述。

第二，UML虽然是一种面向对象的软件系统设计的标准描述语言，但是在其状态图中用状态和迁移表示对象行为关联时用到了大量的不易于理解的注释字符，因此，系统的UML模型既不是可以执行的也是不和用编程语言开发的可执行程序相协调。

第三，在不同的技术实现平台上（如：实现语言，软件环境）对同样需求的系统建模时细节差别很大，系统构建模型的重用性就很低。这样在计算机技术正在向各个方向快速发展的今天，老的遗留系统必须和新技术的实施平台，开发技术相协调，使得新旧系统之间的集成或系统的演化面临不同的实现技术，老的遗留系统在运用新技术进行重构时，必然要浪费很多财力，人力进行系统模型的更新甚至完全重建系统。3.网络购物系统的分析：

3.1网络购物系统的需求分析：

1：普通用户可以登陆系统，成为登陆后用户。

2：普通用户只具有搜索产品、查看产品分类、查看产品项目、查看产品等几个基本权限。

3：除提供一般权限外，本系统还可为登陆后用户提供编辑帐号、购物车、定单、结算的功能和服务。

4：登陆后用户可修改购物数量。3.2 用例图的分析：确定执行者 1谁使用系统的主要功能？

2谁需要从系统获得对日常工作的支持和服务？

3需要谁维护管理系统的日常运行？

4公司的哪个部门使用系统？

5系统需要与其它哪些系统交互？

6谁需要使用系统产生的结果？ 针对网上购物系统的前台系统，通过回答以上问题，可以得到执行者有两类，普通用户和登录后的用户。确定用例:

2系统需要哪些输入/输出？这些输入/输出从何而来？到哪里去？

4执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？ 绘制用例图如下，见图(1):

3.3类图的分析：画类图和理解类图时都应采用三个层次的观点。这些观点也适用于其它模型。三个层次的观点不是UML的组成部分，但对建造模型或评价模型都非常有用，且都可应用于UML.（1）概念层描述应用域中的概念，是对现实世界的直接描述，与实现它们的类有关但与实现方案和实现语言无关。（2）说明层描述软件的接口，而不是软件的实现。一个类型描述一个接口，但可能有多种实现。（3）实现层从实现的角度定义类及其实现，揭示了软件实现体的构成情况。

针对当前系统1产品类（Product）的主要操作：设置和获取每个属性值的方法。2产品类别类（Category）的主要操作：设置和获取每个属性值的方法。3产品项目类（Item）的主要操作：设置和获取每个属性值的方法

4订单类（Order）的主要操作：设置和获取每个属性值的方法、初始化订单（initOrder）、增加产品项目（addLineItem）等。

5购物车类（Cart）的主要操作：设置和获取每个属性值的方法、增加产品项目（addItem）、删除产品项目（removeItemById）等。

6购物车项目类(CartItem)的主要操作：设置和获取每个属性值的方法、统计金额（calculateTotal）等。

下面是系统的类图，见图(2):

4.系统的顺序图分析：顺序图可描述几个对象间的动态协作关系，它非常直观的展示了对象之间传递消息的时间顺序。反映了系统执行过程中某个特定时刻所发生的事情。在系统分析时，可对主要对象类绘制顺序图，以便分析系统的行为，验证和修改系统的静态结构，满足用户的需求，达到系统的目标。根据以上图(1)、图(2)的分析，可得网上购物系统如下，见图(3):

5.结束语：UML在软件工程中的运用是与ＯＭＧ组织提出的ＭＤＡ是相一致的，随着它的不断发展和完善，并且随着OMG使UML实现的标准化﹑统一化，最终基于UML的MDA软件开发过程将变为一个更加重用，更加快速，更加有效的软件开发方法，使软件开发方法向更高抽象层，更加可重用发展。6.参考文献：

基于UML的信息管理系统设计 篇7

学校图书馆信息管理系统是学校信息管理系统中的一个重要组成部分, 要求系统具有健壮性、可扩展性及便于维护性。本文就是根据图书管理的需求, 利用UML为学校图书馆信息管理系统建模, 给出其用例图、类图、活动图及序列图, 并详细分析了创建这些图的要点及过程。

二、UML建模机制

UML (UnifiedModelingLanguage, 统一建模语言) 不仅支持面向对象的分析与设计, 而且支持从需求分析与设计以及实现软件开发的全过程。UML支持三种建模方式:功能性、静态及动态建模。功能性建模是描述系统提供的功能;静态建模是现实生活中各种对象以及它们之间的关系抽象;动态建模描述系统中的对象在执行期间不同的时间点的动态交互。

三、图书馆信息管理系统的UML模型

1、功能性建模———用例视图

用例用于描述用户需求的基本功能。学校图书馆信息管理系统的服务对象主要是全校师生员工, 系统的使用对象为图书馆的工作人员。主要完成以下功能:

1) 图书编目:对新进图书进行著录, 能够建立和维护各类MARC记录, 各类MARC记录按照原格式存放、编辑;

2) 典藏管理:图书的入库;对剔旧和丢失的图书进行注销;打印有关统计表。

3) 读者管理:单个或成批的添加、挂失、停借、注销。

4) 图书流通:读者可以通过图书管理员在系统里借还图书、以及预约图书。

5) 信息查询:读者通过查询子系统可以查找所需图书的信息以及个人借阅信息。

6) 系统管理:建立管理员的帐号和权限;进行有关参数的设置;提供相应的统计报表。

·根据上述功能需求分析定义用例及系统角色, 如图1所示:

·关于业务流程 (数据流)

用文本说明来说明数据的流向, 在此简单阐述一本新书是如何到读者的手里。图书管理员先给读者办理借阅证;新书到馆后, 图书管理员对新书进行著录、入库 (包括两方面的工作:一是通过系统转到数据库中, 一是将新书上到书架) 并打印统计报表;读者通过查询子系统找到所需图书后径直到书架上取书, 在这里又分两种情况:一是若书在架上, 取下后交给图书管理员, 然后登录到借书子系统, 输入读者号和索书号即可, 系统将进行记录和更新;一是若书不在架上, 则读者可通过图书管理员登录到预定子系统进行预约, 等书还回后, 图书管理员将告诉已预定过的读者来借阅。

2、静态建模-逻辑视图

逻辑视图用来显示系统内部的功能是怎样设计的, 它利用系统的静态结构和动态行为来刻画系统功能。本文为图书管理系统建类图。类图设计是面向对象方法的核心技术, 通过类图将用例的实现具体到每个类中, 从而完成设计走向细化的过程。

·图书馆信息管理系统类的描述

(一) 系统对象

(1) 类Reader

描述了读者的信息, 包括姓名、性别、读者类型、读者号等。其所有对象都是持久的 (Persistent) , 继承了类Persistent并实现了读写操作。

(2) 类Title

描述了图书的著录信息, 包括书名、作者、出版者、出版日期、索书号等。它继承了类Persistent并实现了读写操作, 其所有对象都是持久的 (Persistent) 。

(3) 类Book

代表可以借阅的物理书刊, 该对象有两个状态"已借出"和"未借出"。之所以区分类Book和类Title, 因为图书馆对同一种书刊通常保存几本复本。它继承了类Persistent并实现了读写操作, 其所有对象都是持久的 (Persistent) 。

(4) 类Loan

描述了读者从图书馆借阅物理书刊的借阅记录。它继承了类Persistent并实现了读写操作, 其所有对象都是持久的 (Persis-tent) 。

(5) 类Reservation

描述预定记录, 读者可以预定已借出的书刊, 即优先借阅该书刊的物理拷贝。它继承了类Persistent并实现了读写操作, 其所有对象都是持久的 (Persistent) 。

(6) 类Persistent

支持对象的持久存储, 具有将对象写入数据库文件的方法read () 和从数据库读出对象的方法write () , 还提供了通过OID检索对象, 获得持久对象的OID, 以及存储、删除、更新对象的方法。

(7) 类OID

实现了对象ID, 可以用来引用系统中的持久对象, 使得从数据库文件中引用和检索对象变得容易。对象ID由所引用的类的类名和一个独一无二的号组成。通过将OID传递给类Persistent的方法getobject () , 可以从数据库文件中读出对象, 并将对象返回给调用者。

(二) 用户界面类

(1) 类MainWindow

系统的主界面, 选择不同的菜单项时可以执行不同的操作。

(2) 类ReaderDialog

进行读者管理的操作, 比如添加、删除、挂失、停借、补办等。

(3) 类BorrowDialog

进行借书的界面, 图书管理员通过输入读者号可以完成借阅手续。

(4) 类ReturnDialog

进行还书的界面, 图书管理员通过输入图书号如条形码可以完成还书操作。

(5) 类titleDialog

进行图书著录的界面, 图书管理员可以对图书进行编目、入库、注销等操作。

(6) 类FindDialog

提供信息查询, 图书管理员和读者都可以进行图书和借阅信息的查询。

(7) 类RsvDialog

进行预定的界面, 图书管理员可以通过输入图书号为读者预定所需的图书。

(8) 类LoginDialog

提供登录界面, 图书管理员可以通过输入帐号登录到系统。

·识别出系统中的类后, 接着识别出类间的关系并建立域类结构图。

可将系统中的类分为3个包:GUI包、Library包和DB包。包GUI由界面类组成, 包Library由实体类组成, 包DB又与数据库有关的类组成。包GUI依赖于包Library和包DB, 包Library依赖于包DB。

在用户界面类中, 各个子系统都是通过主界面进行启动的, 所以它们之间是一种聚合关系;在系统对象中, 各个子类都会继承父类Persisten的一些属性和方法, 其实也是一种聚合关系;而各个子系统分别与一些子类发生关系的, 因此是一种关联关系。

3、动态建模———并发视图

并发视图用来显示系统的并发工作状况。本文给出图书馆信息管理系统借书活动的序列图, 序列图用来显示对象之间的动态合作关系, 强调对象之间消息的发生顺序, 同时显示对象及它们之间的交互。

借书的过程是:图书管理员在主界面启动借书子系统界面, 然后输入帐号和密码登录到服务器;接着输入读者证号和图书的索书号, 接受服务器数据库的验证;通过后管理员将图书交给读者, 过程结束, 如图3所示。

4、物理模型

本系统是一个基于局域网和数据库的应用系统。配置图如图4所示, 有四个节点:"Library Server" (图书馆信息管理系统服务器) 、"DB Server" (数据库服务器) 、"PC" (图书馆信息管理客户端PC) 、"Printer" (打印机) , 另外"Library Server"通过校园网和"School Server" (校园网服务器) 连接。

四、小结

本文是利用UML对图书馆信息管理系统进行了建模的开发工作, UML能够对整个开发过程提供灵活、一致和易读的表达, 便于软件系统的理解、扩充和维护, 特别适合于大型软件的开发。

摘要：本文首先介绍简单UML建模机制, 接着根据图书管理的需求, 利用UML为学校图书馆信息管理系统建模, 给出其用例图、类图、活动图及序列图, 并分析了创建这些图的要点及过程。

关键词：UML,系统设计

参考文献

[1]、Stephen R.Schach著.《Software Engineering with Java》.机械工业出版社

[2]、冀振燕编著.《UML系统分析设计与应用案例》.人民邮电出版社

[3]、B.Bruegge A.H.Dutoit著.《Object-Oriented Software Engineering》.清华大学出版社

uml教务管理系统 篇8

关键词：UM；系统建模；实验室管理

中图分类号：TP311.52 文献标识码：A文章编号：1007-9599 (2010) 13-0000-02

The Design of Management System for Laboratories on UML

Ma Wei

Changchun engineering college，130012

Abstract:UML is an object-oriented modeling language, the standard in system development is widely used. Based on laboratory management system software development needs,describes the system function requirement analysis modeling process.

Keywords:UML;system modeling;laboratory management

随着近年来高校教育改革和发展，为了进一步提高各高校管理的水平，不得不考虑如何提高工作的效率。实验室管理系统是网络教学的重要组成部分，主要实现实验室信息管理，发送报告、管理学习内容、预约实验室课程等功能。本文基于UML作为分析设计描述语言，分析设计了一个实验室管理系统。

一、UML建模机制

UML（Unified Modeling Language的缩写）统一建模语言，它是用来对软件密集系统进行可视化建模的一种语言。UML作为一种对软件系统进行规约、构造、可视化和文档化的语言，它融合Booch方法、OMT方法的核心概念而形成的一个公共的、同意的、有广泛实用性的建模语言。它也是为面向对象开发系统的产品进行说明、可视化、和编制文档的一种标准语言。

二、需求分析

开发者要充分了解客户的需要才能够设计出比较完善的系统，如果不能很好的理解客户需求，在设计上就会返工，下面就是经过双方调研后的到的需求說明。

（一）系统管理模块：该模块下又包括了用户管理、数据库备份、数据库还原等个子模块。由于该模块是对整个系统中权限的管理，所以该模块只有超级管理员可以操作，在这里超级用户可以添加其他用户并授予不用级别的管理权限。

（二）教师管理模块：该模块下又包括了实验授课计划表和审批、调串课三个子模块，该模块是教师登录后可管理的模块，所以该模块是对教师组登录后才可见的。教师在实验授课计划表中填写好所做实验的地点、时间、项目、班级、学生数等具体情况，用来为系统的自动排课提供信息，然而只有通过审批的计划表才可以参加排课。

（三）实验室管理功能：包括实验室信息、实验室统计、课程管理、实验室统计、设备管理、公告、日志管理、实验室预约管理七个子模块，辅助实验员与教师根据实验教学计划安排实验任务以及对实施情况进行监督管理。

（四）学生管理模块：学生在登录系统后可以进行实验室开放课程预选，并且可以查看课表。

三、用例视图的建立

用例视图描述的是系统的参与者与系统进行交互的功能，是参与者所能观察和使用到的系统功能的模型图。用例视图通常用例图表示，一个用例图就是系统中的一个功能模块，它表示参与者与系统之间进行的一次交互作用，也把参与者与系统中的用例的联系给标识出来，并确定什么样的参与者执行的哪个用例。系统的参与者可以使人，也可以使外部系统或子系统等。以本系统的“实验员”功能为例的用例图，如图1所示。

四、系统的静态模型的建立

UML建模分析与设计中静态模型是依据系统结构从静态观点描述系统的视图，它定义系统中的对象和类及类之间的关系和类的内部结构，即类的属性和操作。系统的静态模型主要包括静态视图（类图、对象图、包图）、用例视图（用例图）、实现视图（构件图、配置图）。

实验室管理系统中的“课程管理”用例的类图如图2 所示。

在“课程管理”用力中，有“课程类别（Course）”、“开放课程类（CouserOffering）”、“班级类（Class）”、“学生类（Student）”、“教师类（Teacher）”、“课程表（CourseOfferingform）”等。

五、系统的动态模型的建立

系统的静态模型建立以后，开始进行系统的动态建模。动态模型包括行为视图（状态图、活动图）、交互视图（顺序图、协作图）。顺序图将交互关系表示为一个二维图。纵向是时间轴，横向代表协作中独立对象的类元角色。类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线是一个双道线。消息从一个对象的生命线到另外一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列

六、结束语

基于ASP的实验室设备管理系统，是结合高校的实际情况所设计的一个基于数字化校园信息平台的实验室设备管理系统，它实现了高校实验室设备的网络化管理。在进行系统需求分析这个重要阶段时选择UML进行系统建模，可以让用户更好的参与进来，加强信息的交流，既加快了开发人员对问题的理解，又让设计流程变得清晰化。这说明UML这种系统建模提高了系统开发的成功性，促进了系统的实用性、规范性。

参考文献：

[1]时陪芳,张永胜.基于UML的上考试系统的设计[J].计算机系统应用，2005,（10）