uml学习体会

uml学习体会（精选7篇）

uml学习体会 篇1

l UML语义：描述基于UML的精确元模型定义。

l  UML表示法：定义UML符号的表示法，为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型，在语义上它是UML元模型的实例。

标准建模语言UML可以由下列5类图来定义。

用例图： 从用户角度描述系统功能，并指出各功能的操作者。

静态图：包括类图和对象图。  类图描述系统中类的静态结构，不仅定义系统中的类，表示类之间的联系，如关联、依赖、聚合等，也包括类的属性和操作，类图描述的是一种静态关系，在系统的整个生命周期都是有效的。对象图是类图的实例，几乎使用与类图完全相同的标识。一个对象图是类图的一个实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。

行为图： 描述系统的动态模型和组成对象间的交互关系，包括状态图和活动图  。状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件，状态图是对类图的补充，活动图描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并进行活动。

交互图： 描述对象间的交互关系，包括时序图和协作图  。时序图显示对象之间的动态合作关系，它强调对象之间消息发送的顺序，同时显示对象之间的交互;协作图描述对象间的协作关系，协作图跟时序图相似，显示对象间的动态合作关系。除显示信息交换外，协作图还显示对象以及它们之间的关系。如果强调时间和顺序，则使用时序图;如果强调上下级关系，则选择协作图。

实现图： 包括组件图和部署图  。组件图描述代码部件的物理结构及各部件之间的依赖关系，组件图有助于分析和理解部件之间的相互影响程度;部署图定义系统中软硬件的物理体系结构。

采用UML来设计系统时，第一步是描述需求;第二步根据需求建立系统的静态模型，以构造系统的结构;第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的，包括用例图、类图、对象图、组件图和部署图等5种图形，是标准建模语言UML的静态建模机制。其中第三步中所建立的模型或者可以执行，或者表示执行时的时序状态或交互关系。它包括状态图、活动图、时序图和协作图等4种图形，是标准建模语言UML的动态建模机制。

首先对UML中的各个图的功用做一个简单介绍：

1、用例图

描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。

2、类图

类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。

3、对象图

与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。它描述的不是类之间的关系，而是对象之间的关系。

4、活动图

描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。

5、状态图

描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类;该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。状态图是对类图的补充。

6、序列图 (顺序图)

序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。

7、协作图

和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图;如果强调上下级关系，则选择协作图;这两种图合称为交互图。

8、构件图 (组件图)

描述代码构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。

9、部署图 (配置图)

是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员。

几种图的区别：

一：这九种模型图各有侧重，

1:用例图侧重描述用户需求，

2:类图侧重描述系统具体实现;

二：描述的方面都不相同，

1:类图描述的是系统的结构，

2:序列图描述的是系统的行为;

三：抽象的层次也不同，

1：构件图描述系统的模块结构，抽象层次较高，

2：类图是描述具体模块的结构，抽象层次一般，

3：对象图描述了具体的模块实现，抽象层次较低。

在有的文献书籍中，将这九种模型图分为三大类：结构分类、动态行为和模型管理：

1：结构分类 包括用例图、类图、对象图、构件图和部署图，

2：动态行为 包括状态图、活动图、顺序图和协作图，

uml学习体会 篇2

现代主流软件工程技术主张采用模型驱动的软件开发方法。模型是现实系统的一个抽象，它提供了系统的蓝图，每个系统都可以从不同的方面用不同的模型来描述。所谓软件建模就是构建软件模型的过程，它是用户与开发者之间最主要的沟通渠道，同时也是整个软件系统开发过程中最重要的环节之一。

一、UML的建模机制

UML是由Rational公司三位著名的信息系统和面向对象方法学专家Grady Booch、James Rufnbaugh和Ivar Jacoboson联合开发的面向对象的建模语言，1997年被OMG批准作为面向对象建模语言的标准。UML作为一种通用的标准建模语言，易于表达、功能强大，不但适用于任何以面向对象技术来描述具有静态结构和动态行为类型的软件系统，而且能够应用于从需求规格描述至系统测试和维护等软件系统开发的不同阶段。因此，UML被广泛应用于可视化描述和构造软件系统，在信息管理系统的建模与开发中得到较为广泛的应用。

作为一种建模语言，UML的定义包括UML语义和UML表示法两个部分。UML语义用于描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致和通用的定义性说明，使开发者能在语义上取得一致，从而消除了因人而异的表达方法所造成的影响。而UML表示法定义了UML的表示方法，为开发者或开发工具使用这些符号和文本语法进行系统建模提供了标准。

UML用模型来描述系统的静态结构或动态行为特征，共定义了5种视图，包含了9种描述系统的图，可以从不同的视角为系统构架建模，从而形成系统的不同视图。

1. 用例视图

用例视图用于描述系统应该具有的功能集，强调从用户的角度看到的或需要的系统功能，是对系统的抽象表示。用例视图通常用用例图表示，用例图用于显示若干角色，以及这些角色与系统提供用例之间的连接关系，主要从用户的角度描述系统的功能，并指出各功能的操作者。用例图有助于系统开发者与用户进行交流，以获取系统需求。

2. 静态视图

静态视图用于对应用领域中的概念，以及系统实现有关的内部概念建模，静态视图包含类图、对象图、包图三种图。类图描述系统的静态结构，用于模拟保证系统正常工作的所有必要资源;对象图描述系统在某个时刻的静态结构，用于模拟资源的示例或事实;包图用于描述系统的分层结构。

3. 动态视图

动态视图包含以交互的名义对行为进行建模的图，有顺序图、状态图、协作图和活动图。顺序图表示对象之间在时间和顺序上的一种动态协作关系，主要目的是表现随着时间推移发生在对象之间的交互情况;协作图描述对象之间的交互关系，以及对象之间的联系;状态图描述的是一个单独的对象，在其生命周期中，由外部激励所导致的状态变化;活动图显示系统中从一个活动到另一个活动的流程，强调对象之间的流程控制。

4. 构件视图和配置视图

构件视图体现系统实现环境的结构和行为特征，用构件图表示。构件图描述系统的元素的组织，用于模拟实现视图，是实际的软件模块。配置视图体现系统实现环境的结构和行为特征，用部署图表示。部署图描述了环境元素的配置，并把实现系统的元素映射到配置上，它模拟的是硬件环境，图上的每个节点都代表某种类型的硬件。构件图和配置图都是对面向对象系统的物理方面建模时使用的图形。

从应用的角度看，当采用面向对象技术进行系统设计时，我们第一步应用用例视图进行系统的需求分析;第二步根据需求建立系统的静态结构;第三步是描述系统的动态行为。其中第一步和第二步都是静态的，是UML的静态建模机制，而第三步中所建立的模型，或者是可执行的，或者表示执行时的时序状态和交互关系，是UML的动态建模机制。因此，标准建模语言UML的主要内容可以归纳为静态建模机制和动态建模机制。

二、学习管理系统软件建模过程

1. 学习管理系统的需求建模

学习管理系统是一个开放的、基于Web的自动化信息管理系统。系统不仅需要具备教师对课程、作业、考试等进行的管理功能，而且要通过计算机网络向分布在不同地理位置的学习者提供课程浏览、课程学习、资源搜索、在线作业、在线考试等服务功能。同时，系统还要充分利用数字化网络学习环境，方便学习者通过异步讨论和实时交流进行协作学习。

为了正确获取用户需求并方便与用户沟通，我们可使用UML用例图建立模型表示系统的详细需求。用例图描述一组用例、参与者和它们之间的关系。参与者用人形图标表示，用例用椭圆符号表示，连线描述它们之间的关系。一般情况下，我们可以先给出顶层用例图，然后根据用户的要求，进一步细化用例，在细化过程中利用泛化关系、包含关系和扩展关系等对用例进行分解和组织。

学习管理系统的角色有三类：管理员、教师和学生。管理员使用该系统进行用户管理;教师使用该系统对学生课程学习、作业、考试试题和学生成绩进行管理;学生则可以使用该系统来进行课程学习、在线作业、在线考试和成绩查询。教师和学生还可以利用该系统进行在线交流、离线讨论、查看学习记录和查看系统信息等活动。每一种活动代表一个用例，这些用例还可以进一步细化，如课程管理用例可进一步细化为课程登记、开设课程、课程查询等用例。整个学习管理系统顶层的用例图如图1所示。

2. 学习管理系统的静态建模

完成系统需求建模后，对用例的分析推导，我们可以画出系统的静态模型。静态模型用类图、对象图、包图来定义系统中类 (对象) 与类 (对象) 之间的关系。类是具有相同属性、操作、关系的对象集合的总称，通常在UML中用矩形表示。类图是描述类、接口、协作和它们之间关系的图，主要用来描述软件系统的静态结构。因此，类图在静态视图中是必须的，也是最为重要的。对象图与类图比较一致，对象之间的链接关系表明类之间的关系。包图由包和类构成，描述系统类与包的分层结构。类图、对象图、包图共同组成对系统静态视图的描述。

学习管理系统中“课程管理”用例的类图如图2所示。

在“课程管理”用例中，有“课程类 (Course) ”、“开设课程类(CourseOffering)”、“人员类 (People) ”、“教师类 (Professor) ”、“学生类 (Student) ”、“学生登记类(StudentRegistion)”、“课程登记类(CourseRegistion)”等。其中，学生类和教师类是人员类的子类，学生登记类和课程登记类是开设课程类的子类。父类和子类之间的关系用三角符号表示，一般的联系用连线表示。

除了一般类外，系统还定义了“课程信息表单 (CourseInfoForm) ”、“查询课程表单(SearchCourseForm)”、“课程登记表单 (CourseRegistionForm) ”等接口类，可以分别为教师、学生、管理员提供课程登记、课程查询、课程信息管理等功能。

3. 学习管理系统的动态建模

在系统静态模型的基础上，我们需要分析和设计系统的动态结构，并建立动态模型。动态模型描述系统随时间变化的行为，在UML中，动态模型主要是建立系统的交互图和行为图。交互图包括时序图和协作图，而行为图则包括状态图和活动图。时序图用来显示对象之间的关系，并强调对象之间的设计顺序，同时显示对象之间的交互;协作图主要用来描述对象之间的交互关系;状态图描述对象所有可能的状态及引起状态转换的条件;活动图是一种特殊形式的状态机，用于对计算流程和工作流程的建模。

学习管理系统中“在线作业”用例的时序图如图3所示。各构件之间的依赖关系。一个构件可能是一个源代码、二进制文件或一个可执行文件构件。构件不仅包含逻辑类或实现类的有关信息，而且构件之间存在依赖关系，这种依赖关系有助于分析和理解构件之间的相互影响程度。学习管理系统中部分构件的构件图如图4所示。

图4中，“学习管理”构件包括系统执行程序(LearningManagement.exe)、“课程管理”构件实现课程管理的动态库(Course.dll)、“成绩管理”构件实现成绩管理的动态链接库(Score.dll)、“作业管理”构件提供作业管理的动态库 (HomeWork.dll) 等。另外，学习管理系统中还存在“考试管理”构件、“分组管理”构件等构件。“学习管理”构件通过接口依赖于“课程管理”、“成绩管理”和“人员管理”等构件，而“课程管理”构件依赖于“课程”、“开设课程”等构件。

配置图主要用于对系统的构件视图建模，主要描述系统中各个物理组成部分的分布、提交和安装过程。学习管理系统基于Web网络设计，将数据库服务器、应用服务器、学习管理系统的相应构件配置在不同的节点上。各个部分通过网络相互通信，实现一个“浏览器/服务器”结构的分布式系统。

在学习管理系统的设计和开发中，UML可以用于设计和开发的各个阶段，能够从更高的抽象层次对系统进行调整和维护，从而可以快速实现系统的重构和修改，大大提高开发效率。

参考文献

[1]丁永刚.利用UML开发基于J2EE的在线课程学习系统[J].教育技术装备, 2005, (10) .

[2]胡锡伟, 陈德人.基于UML的汽配行业销售管理建模与实现[J].计算机工程与设计, 2005, (4) .

[3]吴立春, 卞良, 严军.基于UML的网上考试系统的设计[J].宁夏医学院学报, 2004, (8) .

[4]时培芳, 张永胜.基于UML的工作流管理系统模型的研究[J].计算机系统应用, 2005, (10) .

[5]吴建, 郑潮, 汪杰.UML基础与Rose建模案例[M].北京:人民邮电出版社, 2005.

[6]李虎, 王美英, 万里威.UML基础、案例与应用[M].北京:人民邮电出版社, 2004.

[7]Ivan Porres.Modeling and AnalyzingSoftware Behavior in UML[EB/OL].http://www.tucs.fi/publication/phd phdthesis/phd-porres01a.pdf.

UML实验二 篇3

一、实验目的

1.学会分析系统中的参与者和用例 2.掌握用例图的绘制方法 3.掌握需求分析阶段的用例建模

二、实验器材

1.计算机一台； 2.StarUML工具软件。

三、实验内容

1.画出ATM系统的用例图 2.完成ATM系统用例的事件流描述 3.完成网络教学系统的用例建模 4.完成学生课程注册系统的用例建模

四、ATM系统的用例建摸

1.分析

ATM自动取款机：客户可以取钱，存钱，查询余额，转帐，修改密码。通过分析可找出如下几个参与者：（1）ATM（2）客户

通过分析得到如下用例：

（1）存款（2）取款（3）查询余额（4）转帐（5）修改密码（6）打印收据 2．绘图步骤：

下面介绍在StarUML中创建用例图的过程：

（1）在“Use Case View”中双击Main图，双击图标，出现图1，为编辑用例图做准备。

图1（2）在用例视图中，从工具栏中选择Actor图标，在右边的绘图区中添加一个新元素，并取名客户表明新增一个参与者，如图2所示。

图2（3）同样的方法添加参与者“ATM”,如图3所示。

图3(4)在工具栏上选择用例的图标，依次添加存款、取款、查询余额、转帐、修改密码、打印收据，如图4所示。

图4（5）添加参与者和用例间的关联关系，如图5所示。

图5 依照个人理解，增加一些功能或修改该用例图。（增加的功能或修改的用例图放在此处）

参照如下的取款用例的事件流描述，给出ATM系统的其它用例的事件流描述。

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）储户按确认键，输入取款金额。

5）ATM把帐号和取款金额传递给银行系统，取回帐户余额。6）ATM输出现金，并显示帐户余额。7）ATM记录事务到日志文件。

（ATM系统的其它用例的事件流描述放在此处）登录用例的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，ATM系统检验密码。4）储户进入ATM系统 存款用例的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）储户选择存款事务 5）储户添加存款金额 6）ATM系统验证钞票

7）ATM系统显示储户存款金额 8）储户确定储户存款金额

9）ATM把帐号和存款金额传递给银行系统，更新账户金额 10）ATM记录事务到日志文件。查询余额用例的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）储户选择查询事务

5）ATM系统显示账户余额 转账的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）选择转账事务 5）储户输入转账账号

6）ATM系统验证转账账号 7）储户输入转账金额

8）ATM系统验证输入金额是否符合输入要求 9）ATM系统验证储户账户余额 10）ATM系统显示储户转账账户及转账金额 11）ATM记录事务到日志文件。修改密码用例的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）选择修改密码事务

5）储户输入旧密码，ATM系统验证账户旧密码 6）储户输入2次新密码，确认输入密码 7）ATM系统更新储户的密码为新密码 8）储户修改密码成功 查询历史记录用例的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）选择查询历史事务记录用例

5）ATM系统查询并显示相关的信息 打印数据用例的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）ATM系统核实操作 5）系统提示是否打印数据 6）储户确认打印数据 7）返回主界面

五、根据下属需求，分析参与者和用例，并建立网络教学系统的用例图，给出各用例的事件流描述。

网络教学系统的功能需求主要包括以下几个方面：

① 学生可以登录网站浏览信息、查找信息和下载文件。

② 教师可以登录网站输入课程简介、上传课件文件、发布消息、修改和更新消息。③ 系统管理员可以对页面维护以及批准用户的注册申请。（建立的网络教学系统的用例图放在此处）

（各用例的事件流描述放在此处）学生浏览信息用例的事件流：

1）学生输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入网站主页界面 4）浏览到相关的信息 学生查找信息用例的事件流：

1）学生输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入网站搜索界面 4）输入关键词进行搜索 5）找到自己所需要的信息 学生下载文件用例的事件流：

1）学生输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入下载文件界面 4）查找到相关信息 5）保存在指定的硬盘 6）确定下载

教师输入课程简介用例的事件流：

1）教师输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入课程简介界面 4）增加课程简介 5）保存课程简介 6）确定输入成功

教师上传课件用例的事件流：

1）教师输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入上传课件界面 4）选择上传的课件 5）确定上传课件

教师发布、修改、更新消息用例的事件流：

1）教师输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入发布、修改、更新的消息界面 4）填写好要发布、修改、更新的消息 5）保存要发布、修改、更新的消息 6）确定消息

系统管理员页面维护用例的事件流：

1）系统管理员输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）系统管理员进入页面维护界面 4）修改相关页面

5）保存修改过的相关页面 6）确定修改相关页面

系统管理员批准用户的注册申请用例的事件流：

1）系统管理员输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入用户的注册申请界面 4）审核相关用户注册的信息 5）保存相关用户注册的信息 6）确定用户的注册申请通过

六、请根据以下需求画出学生课程注册系统的用例图。

某大学准备开发一个学生课程注册系统，学生可以使用该系统查询新学期将开设的课程和讲课教师情况，选择自己要学习的课程进行登记注册，并可以查询成绩单；教师可以使用该系统查询新学期将开设的课程和选课学生情况，并可以登记成绩单；注册管理员使用该系统进行注册管理，包括维护教师信息、学生信息和课程信息等。

在每个学期的开始，学生可以获得该学期的课程目录表，课程目录表列出每门课程的所有信息，诸如基本信息、教师、开课系和选课条件等。

新学期开始前两周为选课注册时间，在此期间学生可以选课注册，并且允许改变或取消注册申请，开学两周后注册管理员负责关闭课程注册。每个学生可以选择不超过4门课程，同时指定2门侯选课程以备主选课程未选上。每门课程最多不能超过10人，最少不能低于3人，低于3人选课的课程将被取消。一旦学生的注册过程完毕，注册系统将有关信息提交收费系统以便学生付费。如果在实际注册过程中名额已满，系统将通知学生在提交课程表之前予以更改。

uml课设心得 篇4

六月23号至六月27号，是我们班进行UML专用周课程设计的时间，虽然时间并不是很长，只有短短的一个星期而已，但是让我受益匪浅，通过这次的UML课程设计，使我所学的书本知识得到了全面的检验，也让我对这门课程有了更加深厚的体会。

这次课程设计我们没有另外选题，而是在我们之前做过的系统之上加以完善和改进。现在看看之前提交的作品，确实不近人意；但经过在网上的不断查找资料，终于还是将它完成。之前我做的系统状态图和活动图，为了锻炼自己这次选择了交互图（也就是时序图和协作图）。虽然说自己没有这方面的经验，也不是特别熟悉其工作流程，但是有了在网上 查找资料得来的一些基础和课本里的讲解，自己对它也有了一定初步的认识，虽然不是很全面，但还是跌跌撞撞的完成。其中还因为和组员没有沟通好导致用的类不同，费了好大劲才改回来。

最后，这次课设使我们发现考试真的并不是最重要，最重要的是能运用所学的知识。在整个UML课程的学习过程中，我们突破了传统学习模式，把被动接受转变为主动学习。不再是用学到的知识解题，而是在实际运用时遇到什么学什么，重在把知识应用于实际。立体的运用比死板的模仿更有效也更容易接受。下学期就大四了，也就是大学校园里的最后一年，而课设里学到的动手能力和分析问题解决问题的能力也将是我们毕业找工作的一大筹码。

UML实验指导书 篇5

前言

UML技术是一门实践性很强的课程，必须十分重视加强实验教学。UML技术实验课的目的是进一步巩固和加强理论知识，培养基本应用和建模工具操作技能，提高解决实际问题的能力。

为了达到上述目的，根据我系UML技术的教学大纲及实际情况编写了该实验指导书。全书共分7个实验，每个实验包括有：实验目的、实验器材、实验内容和步骤、实验报告要求

等项目。

１

UML实验指导书

目录

实验一 用例图...............................................................................................................................３ 实验二 交互图...............................................................................................................................４ 实验三 类图...................................................................................................................................５ 实验四 数据建模...........................................................................................................................６ 实验五 活动图...............................................................................................................................７ 实验六 状态图...............................................................................................................................８ 实验七 组件图和部署图...............................................................................................................９

２

UML实验指导书

实验一 用例图

一、实验目的

1． 熟悉用例图的基本功能和使用方法。2． 掌握如何使用建模工具绘制用例图方法。

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

根据以下需求设计一个图书馆管理系统的用例图。基本功能要求：

图书管理：新书登记，图书查询，图书注销； 借阅管理：借书，还书，查询今日到期读者；

读者管理：增加读者、删除读者、查询读者、读者类别管理（可以设置不同类的读者，并使不同类读者对应不同类的图书流通参数，如可借册数，可借天数，可续借次数，可续借天数等）；

报表管理：包括图书借阅统计报表，被注销图书统计报表等；报表可以有多种格式可供选择；可以把报表输出到文件中，可以预览报表、打印报表等。

系统管理：系统管理员使用，包括用户权限管理（增加用户，删除用户，密码修改等），数据管理（提供数据修改、备份、恢复等多种数据维护工具），系统运行日志，系统设置等功能。

四、实验步骤

详细分析系统需求，使用Rose工具完成系统用例图。（1）分析系统活动者（2）分析系统活动者的用例

（3）分析活动者之间、用例之间的关系（5）绘制用例图

五、实验报告要求

1． 整理实验结果。2． 小结实验心得体会。

３

UML实验指导书

实验二 交互图

一、实验目的

1．理解顺序图的基本概念； 2.理解协作图的基本概念；

3.掌握在Rational Rose中绘制交互图的操作方法。

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

根据图书馆管理系统的需求分析和用例图，完成系统的交互图，对用例进行动态建模。

四、实验步骤

1.分析：根据图书馆管理系统的需求分析和用例图，对系统中的用例进行动态建模。2.请根据教材中示例部分在Rational Rose中绘制上述的交互图。

五、实验报告要求

1． 整理实验结果。2． 小结实验心得体会。

４

UML实验指导书

实验三 类图

一、实验目的

1．理解类的基本概念；

2.掌握如何从需求分析中抽象出类的方法； 3.掌握在Rational Rose中绘制类的操作方法。

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

根据图书馆管理系统需求分析、用例图、交互图，对系统进行静态建模，寻找和发现类，分析类之间的关系。

四、实验步骤

1．打开前面初步构建的UML模型文件;2．打开Rose中的逻辑视图（Logical View），选择分析模型（analysis model）目录。并在其下创建一个子目录并命名为：“图书馆业务功能”。

3．用鼠标右击“图书馆业务功能”在弹出来的菜单中选择“New→Class diagram”项，创建类图。

4．双击新建的类图，并点右边控件集中选中的类并用鼠标在图中分别拖出上述类图。5．设定上述抽象出来各类的属性和操作。6．分析、设定以上各类之间的关系。

7．请根据教材中示例部分在Rational Rose中绘制类间的关系。

五、实验报告要求

1． 整理实验结果。2． 小结实验心得体会。

５

UML实验指导书

实验四 数据建模

一、实验目的

1．数据建模的基本概念

2．掌握在Rational Rose中进行数据建模。

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

根据图书馆管理系统需求分析、类图系统进行数据建模。

四、实验步骤

1.创建 Database，Database建模元素在component view中创建。2.创建 Schema，在logical view中创建schema，并选定目标数据库。

3.创建 Domain Package和Domain，在logical view中创建，先创建Domain Package，再创建Domain。

4.创建 Data Model Diagram，在schema下创建。5.创建 Table，在Data Model Diagram中建表。6.创建 Column，在表上建立列。

7.创建 Relationship，在表与表之间建立关系,，有两种关系，即non-identifying(非确定性)关系和 identifying(确定性)关系

8.Normalizing the Data Model，创建了数据模型后，还要将模型规范化，如转换为3NF。

9.Optimizing the Data Model，如创建索引，视图，存储过程，denormalization，使用domain等。

10.Implementing the Data Model，利用Rose产生DDL或直接在数据库中建立表。

五、实验报告要求

1． 整理实验结果。2． 小结实验心得体会。

６

UML实验指导书

实验五 活动图

一、实验目的

1． 熟悉活动图的基本功能和使用方法。2． 掌握如何使用建模工具绘制活动图方法。

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

根据图书馆管理需求分析、用例图、类图等，应针对每个用例进行业务分析，说明其具体的业务流程，完成系统活动图活动图。

四、实验步骤

以“删除读者信息”用例为例，说明绘制活动图的步骤。1．管理员在录入界面，输入待删除的读者名；

2．“业务逻辑”组件在数据库中，查找待删除的读者名；

3．如果不存在，则显示出错信息，返回步骤（1），如果存在则继续； 4．“业务逻辑”组件判断“待删除的读者”是否可以删除；

5．如果不可以，则显示出错信息，返回步骤（8），如果可以则继续； 6．在数据库中，删除相关信息； 7．显示删除成功信息； 8．结束。

五、实验报告要求

1． 整理实验结果。2． 小结实验心得体会。

７

UML实验指导书

实验六 状态图

一、实验目的

1．理解什么状态和状态图； 2.学会使用UML绘制状态图；

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

根据图书馆管理系统的需求分析、用例图和相应的活动图，从对象的动态行为的角度去描述系统的业务活动，完成系统的状态图。

四、实验步骤

1.业务分析：由前面章节对图书馆管理系统中的还书业务的描述和分析可知，还书业务的动态行为是由：空闲（idle）、图书查找（finding）、还书（reversion）、失败（Failure）、归还成功（Success）5种状态及激活相互转换的事件。

2.绘制状态图：请您根据分析运用UML绘制还书用例的状态图。

五、实验报告要求

1．整理实验结果。

2．小结实验心得体会。

８

UML实验指导书

实验七 组件图和部署图

一、实验目的

1.理解组件图的基本概念 2.理解组件图的应用：逻辑部署 3.理解部署图的基本概念 4.理解部署图的应用：物理部署 5.掌握组件图和部署图绘制的方法

二、实验器材

1.计算机一台；

2.Rational Rose 工具软件；

三、实验内容

1． 根据图书馆管理系统的分析和设计，已完成类图和交互图的分析与设计，完成系统的组件图和部署图。

四、实验步骤

1.绘制组件图 分析：

在图书馆管理系统中，通过分析可以发现类图中的类应分为4个部分：

1．用户接口模块（UI），主要负责系统和用户的交互，包括Frame类，Dialog类等。2．业务对象模块（BO），主要负责处理系统中的业务计算，如借书，还书等功能的具体操作。

3．数据存储模块（DB），主要负责处理对数据的存储。4．通用工具模块（UTIL），包括系统中通用函数。

通过一个主程序StartClass来启动。由于系统中的类较多，这里以业务对象模块（BO）为例来讲解如何创建组件图，BO模块中包括

Item类：书目类，表示一本实际存在的书籍或杂志

Loan类：借书业务类，将借阅者和图书馆关联起来，一个Loan对象表示借出的一本书 BorrowerInfomation类：借阅者信息类，表示一个借阅者。

Title类：表示一种书或一种杂志。如《C++编程思想》就是一种书，用1个title表示，如果有2本这样的书，则需要用2个Item表示。

Reservation类：预定信息类，表示一个预定信息。

Item类和Loan类之间互相依赖，Loan类和BorrowerInfomation类之间互相依赖，９

UML实验指导书

BorrowerInfomation类和Reservation类之间互相依赖，Reservation类和Title之间互相依赖，Title和Item类之间互相依赖。绘图步骤：

（1）在组件视图中双击Main图，出现图7.1，为编辑组件图做好准备，这时绘图工具栏中的图标如图中椭圆所示，其中具体含义可参看本节“补充图标”一段的介绍。

图7.1（2）在组件视图中，从工具栏中选择MainProgram图标，在右边的绘图区中添加一个新组件，并取名StartClass.java表明新增一个主程序。

图7.2（3）选择新创建的组件，点击鼠标右键，在弹出的菜单中选择“Open Sepcification”,弹出图7.3对话框。

１０

UML实验指导书

（4）在对话框中，可以修改组件的名称，设置组件的类型，指定实现的语言。这里新组件的名称定为“StartClass.java”，组件构型为Main Program（Rose中提供了多种构型，大部分在补充图标一段中均有简单的介绍），实现语言为JAVA（Rose中默认的是分析语言Analysis），修改结果如图7.4所示。

图7.3

图7.4（5）组件图描述的是系统的实现视图，因此要指定实现组件功能的文件。点击File

１１

UML实验指导书

选项卡，在列表框中点击鼠标右键，在弹出的菜单中选择“Insert File”，弹出文件对话框。在对话框中，键入StartClass.java，点击“打开”按键，这时对话框如图7.5所示。

图7.5（6）双击StartClass.java，弹出是否创建对话框，询问是否创建文件，选择“YES”,弹出记事本，这时可输入相应的源程序（注意：如果这里选择的文件已经存在，则不会弹出创建文件对话框，而是直接显示相应文件内容）。

（7）创建相应的包。选择包图标，在右图中创建。这里同样需要对每个组件打开“Open Specification”对话框，设置具体的属性，对“包”组件来说需要在Files选项卡中指明与其对应的目录。创建完毕的组件图如图7.6所示。

图7.6（8）选择业务对象包（BO），双击，打开业务对象包的详细组件图，这里根据分析的结

１２

UML实验指导书

果分别创建Title.java,Item.java，Loan.java，BorrowerInfomation.java，Reservation.java组件，并设置好每个组件的构型和对应的文件。创建好的BO包组件图如图7.7。

图7.7（9）创建依赖关系。在本节“关系”一段中，已经描述过依赖关系使用虚线表示，因此根据分析中的结果，在图中将相互依赖的组件连接即可。完成后的组件图如图7.8。

图7.8 2.绘制部署图 分析：

HNS的图书管理系统目前开发的是一个单机版系统，其中所有的运算均在一台机器上完

１３

UML实验指导书

成，但是由于打印报表的需要，系统还应配备一台打印机。因此得出系统中存在2个节点：

① 一台主机，其类型是Processor。② 一台打印机，其类型是Device。绘图步骤：

（1）浏览窗口中选择“Deployment View”,弹出如图7.9所示窗口：

图7.9（2）在图中添加分别添加一个Processer和Device，并分别命名为“computer with java support”和“Printer”，添加完毕后，其结果如图7.10所示：

１４

UML实验指导书

图7.10（3）为节点添加连接关系。全图如图7.11。

图7.11

五、实验报告要求

1． 整理实验结果。2． 小结实验心得体会。

基于UML的回归测试研究 篇6

回归测试是面向对象系统的一个有效测试过程的必要部分。当代码修改或配置改变后，都必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否对软件的其他功能没有产生副作用。同时，还需要补充新的测试用例来测试新的或被修改了的功能。所以回归测试应该包括两部分：对修改部分的测试以及与修改相关代码的测试。对被修改部分的重新测试，如果修改部分的功能以及接口没有发生变化，可以直接运行原来的测试用例。但是如果修改导致功能或接口发生变化，则要根据修改后的功能点或接口的变化增加、删除或改进测试用例。由于程序的修改会对软件产生涟漪效应，因此对与修改部分有交互关系的代码也要进行重新测试，以此来保证修改没有对软件产生不良作用。

在渐进和快速迭代开发中，回归测试会更加频繁，测试用例集不断扩大，回归测试成本也随之剧烈增加。由于测试用例集不断重复，因此对测试用例集的微小瘦身都会对成本带来巨大的收益。

本文将详细介绍面向对象系统回归测试中遇到的问题，从全面测试和高效测试的角度，给出一个基于依赖集和优化技术的回归策略。

1、面向对象的回归测试

1.1 面向对象的测试

面向对象程序设计语言的基本特征是提供了数据抽象、继承和动态绑定等设施。一方面通过软件重用提高了软件生产率和可靠性，但另一方面也影响了软件测试的方法和内容。

在面向对象系统中，系统的基本构造模块是封装了的数据和方法的类和对象，而不再是一个个能完成特定功能的功能模块。每个对象有自己的生存周期，有自己的状态。消息是对象之间相互请求或协作的途径，是外界使用对象方法及获取对象状态的唯一方式。对象的功能是在消息的触发下，由对象所属类中定义的方法与相关对象的合作共同完成，且在不同状态下对消息的响应可能完全不同。系统执行中对象的状态可能被改变，产生新的状态。由于对象中的数据和方法是一个有机的整体，在测试过程中要充分考虑面向对象的特点，不能仅仅检查输入数据产生的输出结果是否与预期的吻合，还要考虑对象的状态。

1.2 回归测试

在软件开发过程采用层次增量模型，需要在整个开发过程采用回归测试。当一个类改变后，对类本身、子类关于继承、多态、动态绑定和封装以及使用该类的应用程序必须进行回归测试。而类的改变主要表现在对象属性或方法的修改；对类属性的修改，需要对所有与该属性有依赖关系的类都必须重新测试。对类方法的修改，要根据修改某方法对类的影响程度，可将其修改分为如下三类形式：

(1) 对某类中方法的内容修改，不影响类中各方法之间的调用关系。

(2) 对方法的修改，影响到类中方法间的调用关系。

(3) 类或类中方法的改变影响了其它类。

对 (1) 情况，重新修改所改变的方法测试用例，而对该类其余部分的测试用例不变；对 (2) 情况，只需对所修改的类进行重新测试，而该类与其它类集成的测试用例不变；对 (3) 情况回归测试应包括两部分：一、必须构造足够的测试用例，按其测试准则（覆盖准则或其它），对该方法进行充分测试；二、找出所有与该方法有依赖关系的类，必须构造新的测试用例并对它们的交互进行充分测试。从上面的分析来看对类方法修改的 (1) 和 (2) 情况回归测试相对简单就不再介绍。本文重点是对类属性的修改和对类方法的修改 (3) ，需要重新测试所有与修改有依赖关系的类。

为修改类构造一个依赖图，根据类依赖图决定选择哪些测试用例。如果依赖性分析是正确的，根据它所产生的回归测试包就是安全的缩减。所以依赖性对回归测试具有重要的意义。

2、构建回归测试的依赖集

2.1 面向对象的类图分析

在基于UML的面向对象系统中，类图表达了面向对象系统分析中的最基本元素--类和类之间联系，UML提供多种描述类与类之间的关系：依赖（Dependency）、关联（Association）、泛化（Generalization）、实现（Realization）等。两个类之间的依赖关系具体体现为一个类的属性和操作与另一个类的属性和操作之间的依赖关系。由于关联、聚集、泛化属于较弱的依赖关系，本文将它们归为依赖关系。这样就可以将类图转化成类之间的有向依赖图，在回归测试的过程中，类图有利于静态地分析和研究面向对象系统间广义的依赖关系。

关联依赖：UML类图G中类间的关联关系描述了给定类的单独对象之间语义的链接，提供了不同类间对象可以相互作用的连接。关联可以是二元的。

聚合依赖：聚合关系是关联关系的一种特殊形式，表示类与类之间的"整体-部分"关系。如果部分类完全隶属于整体类，且部分类与整体类有共同生存期，则这样的聚合关系是强聚合关系；否则为弱聚合关系。

继承依赖：继承是一种机制, 继承类（子类）共享了行为上相关的被继承类（父类）的结构和行为，继承机制既可以避免重复定义属性和方法，同时也使得类间的层次关系变得更加清晰和直观。

以教学管理系统为例，下图显示教学管理中各类之间的关系。

2.2 构建类依赖有向图

对于给定的UML类图G, UML类依赖图是用二元组表示的有向图K=<S, E>，其中：S是类的集合；E是边集。

本文采用邻接表来构建类图，将类图中的每一个类看作一个节点，每个节点都包含类名、属性名、操作名等信息，类中的关联、泛化、聚合等依赖关系看作节点间的边，将类图作为初始条件输入，寻找每个类与其它类的依赖关系来构造依赖有向图。

具体算法实现如下所示：

输入:类图G的邻接表

输出:类依赖图K=<S, E>

初始化:S=覫;E=覫;

(1) For每个c1∈G do

(2) For每个c2∈G并且 (c1≠c2)

(3) If c1和c2之间存在关联时

(4) 就将c1的指针指向c2，构造一条有向边

(5) If c1和c2之间存在c2指向c1的聚合、泛化、依赖关系

(6) 就将c1的指针指向c2，构造一条有向边

(7) End For

(8) End For

2.3 构建类测试依赖集

在类依赖图中，寻找所有与修改类有依赖的类集合。具体是从修改类出发寻找一个没有入点的类，将遍历过的所有类加入集合，就得到该修改类的依赖集。

具体算法如下：

输入:依赖图K和节点 (即修改类) c3

输出:数组T (T中的节点)

(1) 以c3为根节点

(2) 从c3的未被访问的邻接点中选取一个顶点w，从出发进行深度优先遍历。

(3) 重复上述两步，直到图中所有和c3有路径相通的节点都被访问到，并将这些节点存入T。

3、测试用例集的缩减

根据上面构建的依赖集，找出测试该集中类的所有测试用例。运行这些测试用例观察测试结果。但是这些测试集中存在冗余和无效，导致回归测试效率的降低，对提高测试效率的测试工作是不合适的。为了达到减少测试成本，提高测试效率的目的，本文对采用优先技术对这些测试用例进行排序。

首先为基于依赖集的每个测试用例赋予一个优先级，在测试过程中按照测试用例优先级顺序来选择执行测试用例。当被测程序中包含某类错误比较多时，优先运行可以检测这类错误的测试用例就有助于提高测试的效率。在测试过程采用启发式方法来预测那些测试用例应该优先执行。对当前测试无用或冗余的测试用例删除，保证测试用例集的有效性和完整性。

4、结束语

软件回归测试在软件测试中扮演着重要的角色。软件回归测试是花销很大的测试，如何进行有效的回归测试，如何有效减小回归测试用例集是软件回归测试研究的重点和难点。本文给出的回归策略是结合我的工作提出的，它能够提高效率和减少成本。但它不是"万能的"。在回归测试中要充分考虑到各个方面的因素制定好的回归策略。

参考文献

[1].华庆一, 王斌君等译.面向对象系统的测试[M].北京:人民邮电出版社, 2001

[2].方朴, 孙家肃等.面向对象软件回归测试技术研究[J].软件学报, 2001:12 (03)

[3].胡顺仁, 王铮, 邓毅.基于UML构造回归测试依赖集[J].计算机工程与应用, 2003.5

[4].李必信, 王云峰, 张勇翔等.基于简化系统依赖图的静态粗粒度切片方法[J].软件学报, 2001, 12 (2) :204-208

UML建模--银行管理系统 篇7

建模

课程设计报告

专业：

学号：

姓名：

任课教师：

一、系统概述

银行是与人们生活密切相关的一个机构，银行可以提供存款、取款、转账等业务。在银行设立账户的人或机构被称为银行的客户（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）状态图

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

四、结论

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

五、总结及心得体会