uml系统建模技术

uml系统建模技术（精选8篇）

uml系统建模技术 第1篇

实验3 动态建模

一、实验目的与要求 掌握分析ATM系统用例中用例的流程，分析对象之间的交互关系 掌握用UML设计参与对象之间的交互，用状态图、时序图、协作图和活动图来描述系统的行为。

二、实验设备、环境

PC(一台)，Windows 2000或以上版本，安装Microsoft Visio 2003

三、实验内容及步骤 交互图：实现ATM系统的序列关系图和通信（协作）关系图； 2 分析设计软件系统的状态图。（（1）和（2）选做一个状态图）；

（1）ATM系统

（2）具体题目如下：某销售POS机，它的工作流程是：当客户到收银台后，收银员逐一输入用户购买的商品，输入完之后，计算出总金额，然后等待用户付款，确定支付成功之后，完成收银，等待下一个客户。请为其绘制出相应的状态机图。

3分析设计ATM系统的活动图（选做1个活动图）。

建立动态模型：

建立序列关系图、状态图、活动图

步骤：



编写脚本



确定各个对象之间的事件



构造事件追踪图（交互图）

构造状态图



添加活动和动作

一、时序关系图

1）ATM系统的正常情况脚本

 ATM请储户插卡；储户插入一张现金兑换卡。 ATM接受该卡并读它上面的卡号。

 ATM要求储户输入密码；储户输入自己的密码“1234”等数字。

 ATM请求系统验证卡号和密码；核对储户密码，然后通知显示器显示说这张卡有效。

 ATM要求储户选择事务类型（取款、转账、查询等）；储户选择“取款”。 ATM要求储户输入取款额；储户输入“880”。

 ATM确认取款额在预先规定的限额内，然后要求处理这个事务；成功处理完这项事务并返回该账户的新余额。

 ATM吐出现金并请储户拿走这些现金；储户拿走现金。 ATM问储户是否继续这项事务；储户回答“不”。

 ATM打印账单，退出现金兑换卡，请储户拿走它们；储户取走账单和卡。 ATM请储户插卡。

2）ATM系统的异常情况脚本

 ATM请储户插卡；储户插入一张现金兑换卡。 ATM接受该卡并顺序读它上面的数字。

 ATM要求密码；储户误输入“8888”等数字。

 ATM请求总行验证卡号和密码；经验证发现密码错误，拒绝这张卡。 ATM显示“密码错”，并请储户输入密码；储户输入“1234”等数字；ATM请求总行验证后知道输入密码正确。

 ATM要求储户选择事务类型；储户选择“取款”。

 ATM询问取款额；储户改变主意不想取款了，按“取消”。 ATM退出现金兑换卡，请储户拿走它们；储户取走卡。 ATM请储户插卡。

ATM 脚本的事件时序图如下图所示：（正常情况）

用户读卡器显示器ATM卡用户账户事务提款机插卡读卡初始化提示输入密码输入密码验证密码获取密码获取账户初始化提示选择业务选择业务执行事务初始化提示输入金额输入金额获取余额验证取款金额计算余额计算利息更新账户配给现金打印收据退卡

二、状态图

主屏]do：显示主屏幕插卡[可读]Do：要求密码输入密码Do:验证账户继续密码错拿走卡退卡do：退卡请拿走卡插卡[不可读]不可读的卡do：显示信息取消取消do:显示取消信息无效账户账户有效Do:要求类型取消输入类型Do:要求金额取消结束do：打印账单Do:显示无效账户信息输入金额等待5秒Do:处理事务中止取消Do:请求继续拿走现金do：吐出现金请拿走现金事务成功取消事务失败Do:失败信息网络响应等待网络响应中断do：显示取消信息ATM类的状态图

处理事务验证账户请求处理事务请求验卡事务成功事务失败无效账户账户有效密码错

事务处理状态图

账户验证状态图

三、活动图

插卡<没有接收动作>输入密码<没有接收动作>输入账户类型输入金额取卡取钱<没有发送动作>

四、实验体会

顺序图的重点是完成某个行为的对象类之间所传递的消息的时间顺序。一个顺序图事务对象角色，生命线，激活期和消息构成。协作图用于描述系统的行为是如何有系统的成分合作实现的。协作时一种静态结构，是一个系统对实现某些服务所涉及的对象及其交互的投影。一个协同定义了一组对某些服务有意义的参加者和它们的联系，这些参加者定义了交互中的对象所扮演的角色。

uml系统建模技术 第2篇

题

目：

《图书馆管理系统》 专业班级：

学

号:

姓

名：

一、系统功能需求

1、基本功能

① 借阅者能够借阅书籍和还书。

② 图书管理员能够处理借阅者的借阅和还书请求。

③ 系统管理员可以对系统的数据进行维护，如增加、删除和更新书目，增加、删除和更新借阅者帐户，增加和删除书籍。

2、系统主要包括以下几个模块：

2.1、基本数据维护模块

① 添加借阅者帐户

② 修改更新借阅者帐户信息 ③ 添加书目

④ 修改和更新书目信息 ⑤ 添加书籍 ⑥ 删除书籍

2.2、基本业务模块

① 借书 ② 还书 ③ 书籍预留

④ 取消书籍预定

2.3、数据库模块

① 借阅信息管理 ② 书籍信息管理 ③ 帐户信息管理 ④ 书籍预留信息管理

2.4、信息查询模块

① 查询书籍信息 ② 查询借阅者信息

3、系统中的类

① 读者类Reader ② 图书馆人员类 LibraryStaff 图书馆管理员类LibraryManager 系统管理员类SystemManager 图书馆馆长类LibraryBoos ③ 图书馆数据库类LibraryDatabase 图书馆资源数据库ResourcesDatabase 图书馆读者数据库ReaderDatabase 图书馆工作人员数据库LibraryStaffbase ④ 图书馆资源类LibraryResources 实物书籍类BooksResources 电子书籍类ElectronicResources 书类Book

Magazine杂志类

4、系统的用例图

 借阅者请求服务的用例图

1借书还书resourcesDatabase下载（阅读）电子书长籍11读者身份验证1reader查询书籍资料阅读杂志readerDatabase11libraryDatabaselibraryStaffese

 图书馆工作人员用例图

图书馆管理员验证处理读者借书处理读书还书1systemManager添加书目resourcesDatabase1系统管理员验证删除书目1添加书籍1libraryDatabaselibraryStaff删除书籍readerDatabase删除读者用户libraryManager添加读者用户

二、软件系统体系结构建模 2.1、系统的时序图

 系统管理员添加书籍的时序图

 系统管理员添加借阅者帐户的时序图

 系统管理员删除书目的时序图

 图书管理员处理书籍借阅的时序图

 图书管理员处理书籍归还的时序图

 借阅者查询书籍信息的时序图

 借阅者预留书籍的时序图

ReaderReaderDatabase1:验证身份()ResourcesDatabase2:返回验证信息3:使用终端机器预留书籍()4:预留书籍信息5:返回书籍信息和馆藏地点

2.2、系统的协作图

 系统管理员添加书籍的协作图

SystemManager2:返回验证消息LibraryResources3:向数据添加新书()4:向书库添加新书()7:返回添加新书成功1:验证身份()5:返回添加成功信息LibraryStaffbaseResourcesDatabase  系统管理员删除书籍的协作图

SystemManager3:删除数据库书目()7:删除成功2:返回信息1:验证身份()LibraryResources5:返回删除消息4:删除馆藏的书()LibraryStaffbaseResourcesDatabase6:更新数据库

 图书管理员处理借书的协作图

对象13：发出借书请求4:输入ReaderID()5:返回读者信息11：将书给读者对象42:返回信息7:输入书籍ID()10:借阅成功1:验证身份()对象38:该书信息对象5对象29:标记该书借出

 图书管理员处理还书的协作图

 借阅者预留书籍的协作图2.3、系统的活动图

 借阅者的活动图

进入图书馆

Reader进入刷卡终端键盘输入ReaderId刷卡输入ReaderID验证成功享受Reader各项服务借书还书将书给图书馆管理人员将书还给图书馆管理员查询书籍资料登录查询终端机下载电子资料登录账户图书管理人员处理借书请图书馆管理人员处理还书请求输入查询资料信息进入电子资料数据库借书成功还书成功得到相关资料信息下载或阅览电子资愿该项服务结束结束离开图书馆  图书管理员的活动图

验证图书馆管理人员账户登录到管理员账户等待读者的还书请求等待读者的借书请书处理读者的还书请处理读者借书请求重新等待读者服务请求处理还书结束处理借书 借书将书给读者重新等待读者服务请求系统管理员的活动图

 系统管理员维护借阅者帐户的活动图

系统管理员 维护借阅者账户的活动图登录到系统管理员账户登录到维护读者账户模块添加读者账户删除读者账户修改更新读者账户输入新账户信息检查该账户信息修改更新读者数据库信息有欠款欠书开设新读者账户没有欠款欠书将账户给读者删除该账户信息督促该用户归还欠款书  系统管理员进行书目信息维护的活动图

系统管理员进行书目信息维护的活动图登录到系统管理员账户登录到书目信息维护模块添加书目删除书目修改更新书目向数据库中添加书目删除数据库中的书目修改更新数据库书目向书库添加新书目删除书库中书目 系统管理员维护书籍信息的活动图

系统管理员维护书籍活动图登录到系统管理员账登录到维护书籍模添加书籍删除书籍向书库添加书籍删除书库中书籍更新数据库书籍信

三、硬件系统体系结构建模

3.1、业务对象组件图 <><>Item.javaLoan.javaTitle.javaReservation.java3.2、用户界面的组件图

UpdateBorrowerFBorrowerFrame.jrame.javaavaCancelResevationFBorrowerWirame.javandow.javaFindBorroweReturnItemrDialog.javaFrame.javaLendItemFFindTitleDrame.javaialog.javaUpdateTitleTitleFramFrame.javae.java

3.3、系统的部署图

DatabaseApplication ServiceWeb Bussiness ApplicationOperation<>BorrowerInformation.java

MainWindow.javaReservationFrame.javaTitleInfoWindow.javaBorrowerInfoWindow.java

UML系统建模的分析和应用 第3篇

1 UML系统建模

建模,顾名思义,就是建立模型。在本文中,就是建立教务管理系统的业务模型。之所以要建立教务管理系统的业务模型,是因为业务系统模型是开发教务管理信息系统的基础。教务管理信息系统本质上是一个互联网技术(Internet Technology,IT)系统,因此掌握和理解业务环境必不可少,对业务的分析和建模是IT系统开发的重要组成部分。

2 系统模型分类

业务建模通常包含如下两部分:

一是模型的动态方面,业务过程的分析。所谓的业务过程,即为了实现某个目标而必须经历的多个工序或者一系列事件。业务过程通常包含一些步骤,这些步骤称为活动集。例如,在教务管理中,为了实现转专业这个目标,必须包含的活动如图1所示。

活动可以顺序执行,也可以并行执行,当学生进行转专业申请时,其仍然可以进行网上选课。通常,业务过程中的活动是相互依赖的。这个依赖关系是由各个活动之间的交互创建的,这些活动属于为实现某个共同目标的业务过程。

二是模型的静态方面,业务系统中的组织结构,业务对象和信息对象分析。高职院校中常见的教务管理组织机构如图2所示。

教务处和各个二级学院、部共同组成业务运行主体,教务的主要业务过程都在这3个核心部门运行。但是一个业务过程运行可能要跨越多个部门,需要多个业务部门共同完成,例如学生购买教材,需要教务处和财务处协助完成。

相对于组织结构,业务对象的分析要简单很多。业务对象,就是指在教务管理业务运行过程中产生的实物,例如转专业申请单,成绩单等。

3 系统外部和内部视图

外部视图就是从外环境来观察教务管理业务系统,外部环境包含学生、普通任课教师和除教务处之外的其他职能部门等,外部视图只关心和外部环境相关的业务过程,以及教务管理系统本身能提供什么服务,而教务管理业务系统本身则是被看作一个黑匣子。

从外部视图来观察教务管理业务系统,只考虑那些和外部用户相关的活动,并不关心教务管理业务系统是如何运转的,里面的业务过程有多少个环节,只关心教务系统能输出什么或者能给提供什么服务。

教务管理系统的输出可以分两种:实物输出和服务输出。实物输出是有形的,例如一张学生的成绩单,而服务输出是无形的,如查询学生成绩。

内部视图则是描述教务管理业务系统是如何给外部环境提供服务,内部视图包含很多业务对象和业务信息,例如教务处管理人员、二级学院教学秘书以及成绩单、申请表等,他们处理必要的业务过程,同时也是业务系统组织结构的一部分。内部视图对外部环境而言是不可见的。

内部视图描述的是教务管理业务系统内部的活动、过程、关系和结构。内部视图通过功能向外界提供服务,功能是存在业务系统内部的,它对于外部用户而言,既不可见,也不可以访问,它用来表示一个内部活动,或者一个业务过程。和业务用例一样,业务过程既可以手工执行,也可以基于IT系统执行。

4 系统的外部用例、活动图

本文将通过用例图和活动图来构建外部视图。用例,根据OMG的定义,是由系统执行的一系列操作,该操作为其他参与者或者相关涉众提供一个重要的结果。在教务管理系统中,用例可以是手工的,也可以是基于IT系统的。业务用例始终是由参与者发起的,或者说外部用户可以使用业务系统提供的服务了。参与者就是使用业务系统输出的外部用户,在教务管理业务系统中,外部用户就是学生、教师。参与者能够与业务系统中的人或IT系统进行交互,例如学生输入自己的学号,才能查询到自己的成绩。在教务管理业务系统内部的操作人员或IT启动的活动并不是外部视图中的业务用例。

在外部视图中,使用UML用例图来表示业务用例和参与者之间的交互关系。之所以采用用例图,是因为它有很好的沟通性,不涉及具体的技术细节。无论是对于设计者、开发人员还是客户,都能根据用例图进行深入的沟通,虽然用例图不能描述工序的细节,但能很好描述系统的功能。设计用例图,首先确定教务管理业务系统的外部参与者,参与者在其中发挥重要作用。

教务管理业务系统的外部参与者罗列如下:

教师:学校的一个员工,教学活动直接参与者,向学生传授知识技能。

学生:经过高考进入学校的一个人,在学校的目的主要是学习知识和技能。

辅导员:老师的一种,主要是从事学生的思想政治教育工作。

二级学院院长:老师的一种,主要负责二级学院的管理工作。

教务处处长:老师的一种,主要负责学校的日常教学管理工作。

其次,要标识从外部参与者来看,将会涉及的用例,如下所示:

U1:学生登陆系统可以查询成绩信息。

U2:学生可以进行网上公共选修课选课。

U3:学生可以进行网上体育课选课。

U4:选课完毕后,学生去听课。

U5:教师可以查询打印选课学生名单信息。

U6:教师可以查看课表。

U7:教师去上课。

U8:教师网上录入学生成绩。

最后,本文使用用例图可完整地展示上面提到的用例示意,如图3所示。

本文从图3中可以解读出如下信息:对于学生角色,他与4个业务用例进行关联,可以执行4个业务用例。而对于教师角色,他也和4个业务用例进行关联,可以执行4个业务用例。上课用例和录入成绩用例是包含关系,这意味着在和上课用例进行交互的过程中,将会在某个时候执行录入成绩用例。对于二级学院院长、教务处处长、辅导员的角色作了泛化,因为本质上他们都是教师的角色。

用例图虽然可以清楚地看到外部参与者和用例之间的关联,但是无法描述业务用例的细节,就是教务管理业务系统的业务过程。这些缺陷可以通过活动图来进行弥补,活动图可以描述外部参与者和业务系统之间的交互,这种交互包含并行、分支和顺序等。

活动图与程序流程设计相关,它用于表示活动集。在外部视图中,本文用活动图来描述这些业务过程,也就是描述业务系统的功能,从功能的角度思考问题,对业务过程建模很有帮助。

绘制活动图可以选择不同的详细程度。可以把他们逐步精细化,在外部视图中,活动图和用例图类似,只是从外部视角来观察业务过程和活动。本文不能描述业务过程的执行细节,这是内部视图考虑的事情。

从学生的角度观察,活动图如图4所示,活动图首先从学生登陆教务管理系统这个事件开始,然后沿着控制流到达一个决策点,如果没有登陆成功,活动结束。如果登陆成功,将会遇到一条粗线,学生可以进行选公选课或者选体育课,注意这2个用例是可以同时进行的。当这2个用例都进行完毕后,控制流进行了汇总,进行听课的用例执行,在听课结束后,学生可以查询自己的个人成绩。如图4所示,相比较用例图,本文可以看出用例之间是并行执行的还是顺序执行的。

5 系统组织单元

要执行内部视图建模,首先是调查内部组织结构。组织单元结构对于教务管理业务系统内部视图而言是很重要的。在UML中,组织单元结构使用包图来描述,它可以包含教务处管理人员、业务对象以及其他组织单元。组织单元是能够负责执行业务过程活动的实体,组织单元是对组织中各种个体工作的抽象。

在UML中,一个组织单元是由工作者、业务对象、其他组织单元以及它们之间的关系构成的。组织单元必须位于业务系统之中,这是一个基本原则。在业务系统之外的组织单元是参与者。

6 系统的类图

包图可以反映每个管理单元所包含的内部工作人员和业务对象,但是包图并不能反映内部工作人员和业务对象之间的关系,类图可以弥补包图的缺陷。

类图5可以对教务管理业务系统的结构部分,即各个管理人员、业务对象以及外部参与者的关系进行描述。业务模型级的类图尽量保持了简化,只使用了很少部分的元素,这样做是为了便于阅读和沟通。因为UML所设想的目标就是简化相关参与者之间的沟通,如果过于复杂,这一优势就会丧失殆尽。

在图5中本文能读出如下信息,学籍管理人员会生成班级名单和学生名单,教学计划任务管理人员会使用班级名单,然后生成上课地点清单和公共、专业课任务清单。公选课管理人员会根据上课地点清单生成公选课任务清单。体育选项管理人员使用上课地点清单生成体育选项任务清单。成绩管理人员使用学生名单生成学生成绩单。排课管理人员使用体育选项任务清单、公选课任务清单、公共课专业课任务清单、学生名单来生成学生课表和教师课表。生成的教师课表发给人事系统使用。学生名单则供学工系统、一卡通、财务、图书馆系统使用。教师和学生作为系统外部参与者可以查看教师课表和学生课表。

7 结语

综上所述,UML统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点,从而有效地消除了各种建模语言之间不必要的差异。UML建模能力比其他面向对象建模方法更强。它不仅适合于一般系统的开发,而且对并行、分布式系统的建模尤为适宜。

摘要：文章以高职院校教务管理业务作为原型基础,通过该实例详细地介绍了UML建模技术。包含如何进行系统模型的分类,怎样区分外部视图和内部视图,如何绘制外部用例和活动图以及如何建立系统组织单元等,最后给出了完整的类图模型。

关键词：UML模型,教务管理,类图

参考文献

[1]PATRICK G,HENRIETTE B.UML 2.0 in Action[M].Birmingham:Packt Publishing,2007.

[2]MIKE D.Object-Oriented Analysis&Design[M].United States:O’Reilly Medi,2005.

[3]GRADY B,JAMES R,IVAR J.Unified Modeling Language User Guide(Second Edition)[M].United States:Pearson education inc,2013.

uml系统建模技术 第4篇

关键词：UML；贫困生管理；系统设计；需求分析

中图分类号： G4 文献标识码： A 文章编号： 1673-1069（2016）28-135-2

0 引言

需求分析在系统开发过程中起到关键作用，只有用户需求获取精准后，才能开发出实用性的软件系统。在UML中，使用用例图进行需求建模，本文以江门职业技术学院贫困生管理系统为例，应用用例图进行建模，并清晰地描绘出系统的功能。

通过本系统的实施，减轻了学院系部和校学生工作处的工作量，为贫困生提供了更好的申请与助学服务，还可以提供相关的数据报表，为贫困生认定及勤工助学管理提供有效的管理手段。

1 高职院校贫困生管理系统需求分析

高职院校贫困生管理中涉及五个角色，分别是：使用系统的学生、院系管理员、校学生工作处管理员、心理咨询处管理员以及财务处管理员。系统需采用基于角色的权限管理，每个权限分属于不同的角色，而每个用户都有其对应的本系统中角色。系统要根据用户的所属的角色的权限分配给用户访问不同的页面的权力。上述的五类参与者能够参与的本系统功能描述如下：

学生的用户是本系统中相对高级权限的用户，能够在系统中完善个人信息、贫困生资格申请，贫困生助学岗位申请、查询岗位工资等操作。

院系管理员是系统的二级管理员，能够完成查询审核系部贫困生申请、查询学院政策通知、提供助学岗位、查询审核助学申请等操作。

学生工作处管理员是系统的一级管理员，能够完成贫困学生名单二次审核、发布相关政策通知、计算发放工资等操作。

心理咨询处和财务处用户是系统的较为低级权限的用户，只能能够完成心理咨询信息以及讲座信息等操作，财务处只能完成发放贫困生工资的操作。

根据上述需求分析得出系统的功能模块有：贫困生管理、勤工助学管理、贫困生精神援助模块、系统管理等功能模块。

2 基于UML用例建模的系统用户功能需求分析

本系统的主要执行者有学生、学院/系部、校学生工作处、财务处、系统管理员和校心理咨询处等，常见的执行用例个人信息录入、贫困生资格申请、助学岗位查询、个人申请提交等。

2.1 学生自助服务用例建模

贫困学生在此模块还可以登录“勤工助学”版块，可以看到“申请勤工岗位表”、“申请补助表”，填完可以提交，学生要通过填写申请信息，等待申请的反馈，查看上岗信息。然后根据情况上岗，最后可以再完成勤工助学之后可以查询工资情况。

2.2 贫困生资格审核管理用例建模

贫困生管理模块主要目的是为实现学生提供贫困生信息数据录入、贫困生资格申请的功能；为学院系部提供查看学院贫困生工作相关政策通知和查询系部贫困生申请，提交本系部贫困生信息到校学生工作处；此外，该模块还提供校学生工作处发布相关政策通知和二次审核贫困学生名单，进而建立贫困生档案。贫困生资格审核管理的功能图如图2所示。

2.3 贫困生助学岗位审核管理用例建模

勤工助学管理模块在功能机制上更体现了人性化：学生在申请勤工助学岗位时可以根据自己的实际确定岗位志愿，以最大限度地满足学生的实际需求。在为学生安排岗位时可自动对学生按岗位要求的性别、年级、学院、校区等信息进行筛选、提高了工作效率。贫困生助学岗位审核管理的功能图如图3所示。

2.4 贫困生精神援助用例建模

贫困生精神援助模块主要是为贫困我解决心理上面的问题，在这个模块中，贫困生可以完成网上阅读、收听讲座、做心理测试等操作。同时在心理咨询处的老师可以通过系统记录学生信息；对于心理测试不正常的学生信息也被记录。贫困生精神援助模块的功能图如图4所示。

2.5 助学岗位工资管理用例建模

财务处所完成的操作：结算工资；发放工资。助学岗位工资管理的功能图如图5所示。

2.6 公共信息管理用例建模

公共信息管理主要功能包括公告管理、用户管理、系统日志管理。该模块主要为系统管理员提供管理用户信息、管理系统日志和公告等功能。

3 系统模块设计

综上所述需求分析和用例模型分析，采用面向对象设计的方法设计出贫困生管理系统功能模块，主要包括：学生自助服务、贫困生资格审核管理、贫困生助学岗位审核管理、贫困生精神援助、助学岗位工资管理、公共信息管理共6个子系统。

4 结语

UML 统一建模语言具有标准统一、面向对象、可视化表达、与过程独立、容易掌握等特点，为此，在软件工程建设项目中被广泛应用。本文主要以高校贫困生管理系统为例，对UML技术在信息管理系统中的用例建模方面进行分析和研究，以期为更好地在软件工程项目中掌握和使用UML 技术提供借鉴。

参 考 文 献

[1] 翟洁.基于合约的泛型Web服务组合与选择研究[D].华东理工大学，2015.

[2] 胡芳槐.基于多种数据源的中文知识图谱构建方法研究[D].华东理工大学，2015.

uml系统建模技术 第5篇

一、图书馆管理系统可行性分析

随着政府机关与广大企事业单位内部网络的广泛建立，在通用信息平台上构筑高效实用的协同工作和自动化办公应用系统，满足信息高度共享和即时发布的需求，有效实现内部知识管理，已成为众多用户的共同需求。

该图书管理系统，为图书馆管理提供了一个较好的解决方案。在开发过程中，按照软件工程的步骤，从设计到开发采用了面向对象的思想和技术，采用了SQL SERVER 2000数据库，使得本系统可以方便的和其他子系统进行数据交换。同时，注意从软件的图形应用界面上优化软件质量，使得本系统具有很强的可操作性。

二、需求分析

需求分析的目的是深入描述软件功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求。2．

1、客户需求分析

①能够对图书进行注册登记，也就是将图书的基本信息（如：书的编号、书名、作者、价格等）预先存入数据库中，供以后检索。

②能够对借阅人进行注册登记，包括记录借阅人的姓名、编号、班级、年龄、性别、地址、电话等信息。

③提供方便的查询方法。如：以书名、作者、出版社、出版时间（确切的时间、时间段、某一时间之前、某一时间之后）等信息进行图书检索，并能反映出图书的借阅情况；以借阅人编号对借阅人信息进行检索；以出版社名称查询出版社联系方式信息。

④提供旧书注销功能，对于淘汰、损坏、丢失的书目可及时对数据库进行修改。

⑤能够对使用该管理系统的用户进行管理，按照不同的工作职能提供不同的功能授权。⑥对所借图书情况进行登记，包括借阅时间、借阅人等 ⑦对超出借阅时间、损坏或丢失图书的读者进行相应处理 ⑧读者可以查询自己的信息 ⑨借书、还书、续借书

2．2 定义系统的边界和范围 该系统的边界为学校的图书馆

该系统的范围可包括“读者管理子系统”、“书籍管理子系统”、“借阅管理子系统”、“系统管理子系统” 2.3确定执行者

根据前面介绍的客户需求分析可以看出。“图书馆管理系统”有三个执行者，即“读者”、“图书管理员”、“系统管理员”

1）2）读者：查询个人信息、查询图书信息、借阅图书、返还图书、续借图书、接受相应处理

图书管理员：借书处理、还书处理、新旧书登记处理、办理相应处理手续

3）系统管理员：系统维护工作——学生信息管理、图书信息管理、系统状态维护 2.4确定用例

（1）“图书馆管理系统”中的用例

在第一层，根据客户对“图书馆管理系统”的整体业务功能要求，可选的用例有：

·基本业务功能管理

·基本数据修改 ·信息查询

·数据库管理

（2）“基本业务功能子系统”中的用例

在第二层，客户对“基本业务功能子系统”的整体业务功能要求，可选的用例有： ·借阅管理 ·借书

·续借书 ·还书

（3）“基本数据修改功能子系统”中的用例

在第二层，客户对“基本数据修改功能子系统”的整体业务功能要求，可选的用例有： ·读者信息管理 ·读者信息录入 ·读者信息修改 ·读者信息注销 ·书籍信息管理 ·书籍信息录入 ·书籍信息修改

·书籍信息注销（4）“信息查询子系统”中的用例

在第二层，客户对“信息查询子系统”的整体业务功能要求，可选的用例有： ·图书信息查询 ·读者信息查询

（5）“数据库管理子系统”中的用例

在第二层，客户对“数据库管理子系统”的整体业务功能要求，可选的用例有： ·借阅管理 2.5分层绘制用例图

根据系统需求分析中客户对系统的功能要求，我们一确定了系统和子系统的边界、执行者和用例，现在就可以绘制用例图了。

1． 最高层用例图

根据客户对“图书馆管理系统”的整体业务功能要求，可以绘制如图1-1所示的最高层用例图 2． 第2层用例图

在第2层用例图中包括四个用例图：基本业务功能子系统、基本数据修改功能子系统、信息查询子系统、数据库管理子系统。如下图所示：

System<>借书<>续借书图书管理员借阅管理<><>还书超期罚款<>系统管理员丢失罚款图1-2 基本业务功能子系统System图书信息管查询图书管理员读者信息查询读者图1-4 信息查询子系统 读者

System读者信息销毁<><>读者信息录入读者信息管理<>读者信息修改系统管理员书籍信息管理<>书籍信息录入<><>书籍信息修改图书管理员书籍信息销毁图1-3 基本数据修改功能子系统

System借阅管理系统管理员图1-5 数据库管理子系统

2.6 描述用例

1．“借书”用例

用例编号：0102（共有两层用例图，每层用2位数字表示，采用4位编号）用例名：借书

执行者：直接执行者：图书管理员，涉及到的执行者有：读者、系统管理员 目的：借阅图书

过程描述：

（1）图书管理员登陆基本数据修改功能子系统，点击“借阅管理”中的“借阅”（2）输入图书证编号

若输入不正确，则提示“您输入的借阅证号码有误，请重新输入！”；输入正确后，显示读者已借阅图书信息，提示超期未归还的图书；（3）输入图书编号

若读者已借满，提示“您已借满，请先归还部分图书再来借，谢谢！”；若读者可以正常 4 借阅，提示“您确定要借阅这本书吗？”

（4）确定借阅图书，则借阅证号增加一条借阅信息记录；读者选择 “放弃”，回到步骤（3）重新选择图书；

（5）读者成功借阅图书，系统管理员保存借阅记录并修改库存图书数量、读者借出数量。

（6）借阅完成，点击“退出”，退出系统。2．“还书”用例 用例编号：0103 用例名：还书

执行者：直接执行者：图书管理员，涉及到的执行者有：读者、系统管理员 目的：归还图书 过程描述：

（1）图书管理员登陆基本数据修改功能子系统，点击“借阅管理”中的“还书”；（2）输入图书证编号；

若输入不正确，则提示“您输入的借阅证号码有误，请重新输入！”；输入正确后，显示读者已借阅图书信息，提示超期未归还的图书，有超期未还的图书，调用“超期罚款”；若读者说自己丢失图书，调用“丢失罚款”

（3）输入要还的图书编号； 若输入错误，提示“您未借阅该图书！” 若输入正确，提示“您确定要归还这本书吗？”（4）读者选择“确定”，读者借阅的图书信息记录消失；读者选择 “放弃”，返回到步骤（3）

（5）完成还书，点击“退出”，退出系统；

（6）读者成功归还图书，系统管理员删除借阅记录，并修改数据库管理子系统的图书数量和读者借出数量。

3．“读者信息录入”用例

用例编号：0302 用例名：读者信息录入

执行者：直接执行者：系统管理员，间接执行者：读者 目的：录入新读者相关信息，包括姓名、身份、学院 过程描述：

（1）系统管理员登陆基本数据修改功能子系统，点击“读者信息录入”（2）写入读者相应信息，将读者信息保存至数据库

（3）发放图书证

（4）创建完成，读者信息录入成功，在数据库管理子系统增加图书信息，退出系统

4．“读者信息注销”用例 用例编号：0303 用例名：读者信息销毁

执行者：直接执行者：系统管理员，间接执行者：读者

目的：当读者由于工作地点变化或其他原因，无需再使用图书馆的图书资料时，应当为其办理注销

过程描述：

（1）系统管理员登陆基本数据修改功能子系统，点击“读者信息注销”（2）查询读者的借阅记录

若有未归还图书，给出提示：暂时不能注销

否则注销读者，提示：注销后，不能借阅图书 若不确定，返回上一层界面

（3）注销图书证，删除基本数据修改功能子系统中的读者信息（4）注销完成，在数据库管理子系统删除读者信息，退出系统 5．“书籍信息录入”用例 用例编号：0305 用例名：书籍信息录入

执行者：直接执行者：系统管理员，间接执行者：图书管理员，数据库管理子系统 目的：图书馆里的图书根据馆藏需求进行更新 过程描述：

（1）系统管理员登陆基本数据修改功能子系统，点击“书籍信息录入”

（2）写入图书相应信息

（3）图书管理员给图书进行分类编号，记录条形码信息（4）图书管理员为图书张贴条形码

（5）图书管理员检查图书编号是否入库

（6）在数据库管理子系统增加图书信息，书籍信息录入成功，退出系统 相应活动图如下：

系统管理员界面图书管理员数据库管理子系统登陆基本数据修改功能子系统点击书籍信息录入图书进行分类编号，记录条形码信息图书张贴条形码检查图书编号是否入库增加图书信息[否]退出系统[是]

6．“书籍信息注销”用例

用例编号：0306 用例名：书籍信息注销

执行者：直接执行者：系统管理员，间接执行者：图书管理员，数据库管理子系统

目的：当图书馆里藏书，由于受到毁损或其他意外的破坏而无法再使用的情况下，需要对馆藏图书进行注销。过程描述：

（1）系统管理员登陆基本数据修改功能子系统，点击“书籍信息注销”

（2）输入图书编号，若该书借阅出库，则暂时不能注销，提示“该书借阅中，不能注销”；若该书未被借阅，提示“确定要注销此书吗？”若不确定，返回上一层界面（3）成功注销图书后，在数据库管理子系统删除图书信息，退出系统

三、系统分析

3.1建立对象类（1）reader 类名：reader 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 功能：负责读者信息并对这些信息进行处理，便于对读者借阅信息进行统一管理。属性：读者的编号ID（reader_id）、姓名（reader_Name）、身份（identification）、学院（academy）、所借书籍的编号（borrowed）等 操作：借书和还书、接受相应处理

(2)system admin 类名：system admin 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 属性：编号和姓名等

操作：读者信息管理、书籍信息管理、借阅管理、（3）books admin 类名：books admin

类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 属性：编号和姓名等

操作：借阅管理、书籍信息录入、书籍信息修改、书籍信息注销（3）Books 类名：Books 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，可以共享 属性：书名、作者、书籍编码、类别、价钱、入库时间 操作：分类编号、记录条形码信息、（4）borrow 类名：borrow 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 属性：借阅书籍的编号、借阅时间、操作：借书、还书、续借书、交欠款、交罚款（5）data 类的类型：该类创建的对象是持久对象，存储在服务器上的数据库中，不可以共享 属性：书籍信息、读者信息、借阅信息

操作：读者信息录入、读者信息修改、读者信息注销、书籍信息录入、书籍信息修改、书籍信息注销、增加借阅信息、删除借阅信息 3.2 建立对象类图

reader+编号+姓名+身份+学院+所借书籍的编号+借书()+还书()+接受相应处理()data+书籍信息+读者信息+Attribute1+读者信息录入()+读者信息修改()+读者信息注销()+书籍信息录入()+书籍信息修改()+书籍信息注销()+增加借阅信息()+删除借阅信息()system admin+编号+姓名+读者信息管理()+书籍信息管理()+借阅管理()Books+书名+作者+书籍编码+类别+价钱+入库时间+分类编号()+记录条形码信息()borrow+借阅书籍的编号+借阅时间+借书()+还书()+续借书()+交欠款()+交罚款()books admin+编号+姓名+借阅管理()+书籍信息录入()+书籍信息修改()+书籍信息注销()图2-1 图书馆管理系统类图

四、系统设计

4.1顺序图建模

◆在“借书”用例中涉及的对象间的交互分析如下：

1）登录系统。图书管理员登陆“基本数据修改功能子系统”，对读者的借书要求进行处理。涉及的对象：

·消息的发送者：“系统管理员”对象 ·消息的接收者：“基本数据修改功能子系统借阅窗口”对象 传递的消息：

·消息：口令密码（）

·消息的类型：同步消息

·返回消息：口令密码正确或出错信息 2）输入图书证编号。涉及的对象：

·消息的发送者：“基本数据修改功能子系统借阅窗口”对象 ·消息的接收者：“基本数据修改功能子系统借阅窗口”对象

传递的消息：

·消息：核对图书证编号（）·消息的类型：自调用消息

·返回消息：图书证编号正确或出错信息 3）输入图书编号。涉及的对象：

·消息的发送者：“基本数据修改功能子系统借阅窗口”对象 ·消息的接收者：“reader”对象

传递的消息：

·消息：[最大借书额为0]:核对借书额（）·消息的类型：同步消息

·返回消息：可以借书 4）确定借阅图书。涉及的对象： ·消息的发送者：“reader”对象 ·消息的接收者：“reader”对象 传递的消息：

·消息：[确定借书]: 借阅证号增加借阅信息记录（）·消息的类型：自调用消息 ·返回消息：借书成功 5）修改数据库。涉及的对象： ·消息的发送者：“reader”对象 ·消息的接收者：“数据库管理系统借阅管理”对象

传递的消息：

·消息：[借书成功]: 保存借阅记录并修改库存图书数量、读者借出数量（）·消息的类型：同步消息

·返回消息：退出系统

根据以上确立的“借书”用例图中涉及的对象，建立“借书”用例的顺序图如图3-1：

基本数据修改功能子系统借阅窗口reader数据库管理系统借阅管理窗口 : 图书管理员1 : 登录系统()2 : 核对图书证编号()3 [最大借书额为0] : :核对借书额()4 [确定借书] : 借阅证号增加借阅信息记录()5 [借书成功] : 保存借阅记录并修改库存图书数量、读者借出数量()图3-1 “借书”用例顺序图

◆在“还书”用例中涉及的对象间的交互分析如下：

1）登录系统。图书管理员登陆“基本数据修改功能子系统”，对读者的还书要求进行处理。涉及的对象：

·消息的发送者：“系统管理员”对象 ·消息的接收者：“基本数据修改功能子系统还书窗口”对象 传递的消息：

·消息：口令密码（）

·消息的类型：同步消息

·返回消息：口令密码正确或出错信息

2）输入图书证编号。涉及的对象：

·消息的发送者：“基本数据修改功能子系统还书窗口”对象 ·消息的接收者：“基本数据修改功能子系统还书窗口”对象

传递的消息：

·消息：核对图书证编号（）

·消息的类型：自调用消息

·返回消息：图书证编号正确或出错信息

3）超期罚款处理。涉及的对象：

·消息的发送者：“基本数据修改功能子系统还书窗口”对象 ·消息的接收者：“基本数据修改功能子系统超期罚款窗口”对象 传递的消息：

·消息：[超期]：超期罚款（）·消息的类型：同步消息 ·返回消息：销毁超期信息

3）丢失罚款处理。涉及的对象：

·消息的发送者：“基本数据修改功能子系统还书窗口”对象 ·消息的接收者：“基本数据修改功能子系统丢失罚款窗口”对象

传递的消息：

·消息：[丢失]：丢失罚款（）·消息的类型：同步消息 ·返回消息：销毁超期信息

4）输入图书编号。涉及的对象：

·消息的发送者：“基本数据修改功能子系统还书窗口”对象 ·消息的接收者：“reader”对象 传递的消息：

·消息：[借阅]：核对是否借阅此书（）·消息的类型：同步消息 ·返回消息：是否借阅此书 5）确定还书。涉及的对象： ·消息的发送者：“reader”对象 ·消息的接收者：“reader”对象

传递的消息：

·消息：[确定还书]: 借阅证号删除借阅信息记录（）·消息的类型：自调用消息 ·返回消息：还书成功

6）修改数据库。涉及的对象：

·消息的发送者：“reader”对象 ·消息的接收者：“数据库管理系统借阅管理”对象

传递的消息：

·消息：[还书成功]: 删除借阅记录并修改库存图书数量、读者借出数量（）·消息的类型：同步消息 ·返回消息：退出系统

根据以上确立的“还书”用例图中涉及的对象，建立“还书”用例的顺序图如图：

基本数据修改功能子系统还书窗口基本数据修改功能子系统超期罚款窗口基本数据修改功能子系统丢失罚款窗口reader : 图书管理员1 : 登录系统()2 : 核对图书证编号()3 [超期] : ：超期罚款()4 [丢失] : ：丢失罚款()5 [借阅] : ：核对是否借阅此书()6 [确定还书] : : 借阅证号删除借阅信息记录()

图3-2 “还书”用例顺序图一

reader数据库管理系统借阅管理5 [确定还书] : : 借阅证号删除借阅信息记录()6 [还书成功] : :删除借阅记录并修改库存图书数量、读者借出数量()

图3-3 “还书”用例顺序图二

4.2 构件图建模

构件图主要用于建立系统的静态实现视图模型，通过构件之间的依赖关系描述系统软件的组织结构，展示了系统中的不同物理构件机器之间的联系。

图3-4所示的是图书馆管理系统部分构件图，图书管理员登陆“基本数据修改功能子系统”并成功通过验证后，进入基本数据修改功能子系统主界面

图书管理员登陆验证基本数据修改功能子系统主界面续借书借书还书丢失罚款超期罚款图3-4 基本数据修改功能子系统构件图

4.3 配置图建模

实用配置图定义的软硬件结构及通讯机制，表示软硬件系统之间的合作关系；使用构件图描述系统由哪些构件组成。

图书馆管理系统是一个客户/服务器和服务器/浏览器相结合的系统，可以同配置图显示系统的物理结构，如图3-5所示：

uml系统建模技术 第6篇

基于UML和HLA的装备维修保障体系中部分仿真过程建模,首先确定联邦目标,得出装备维修保障系统效能,确定仿真应用的`边界和范围,描述仿真应用中的对象及对象间交互.接着决定仿真应用中的联邦成员,开发联邦对象模型.通过运用程序设计语言实现编程,最后运行联邦,分析输出结果,实现仿真系统中的时间管理服务所有权管理服务.

作 者：石磊 刘佳 赵晓明 潘平俊 SHI Lei LIU Jia ZHAO Xiao-ming PAN Ping-jun 作者单位：石磊,赵晓明,潘平俊,SHI Lei,ZHAO Xiao-ming,PAN Ping-jun(空军工程大学电讯工程学院,陕西西安710077)

刘佳,LIU Jia(总参军代局西安地区代表室,陕西西安710077)

uml系统建模技术 第7篇

【摘要】在软件工程中，UML建模技术的应用十分广泛，具有可视化、定义良好以及功能强大等优点。基于此，笔者从UML建模技术的概念和优势入手，对软件工程中UML建模技术的应用模式和应用流程进行了分析，主要介绍了用例图、类图、序列图和协作图在软件工程中的应用，并将人才招聘系统作为研究对象，阐述了UML建模技术的实践应用，以期为相关研究提供参考。

【关键词】软件工程；UML建模技术；需求分析

前言

在进行软件的开发时，技术人员大都会通过面对对象描述的方法进行建模，该方法是将软件系统的对象看做是构建模块。在进行建模的过程中，UML建模技术可以创建系统的静态结构以及动态行为，可以有效提高建模的效率和准确性。因此，对于软件工程中的UML建模技术研究具有一定的现实意义与理论指导价值。

1.UML建模技术概述

UML是一种规范定义、文档化或者可视化的最标准的建模语言，可以应用于软件工程的各个阶段。UML建模语言拥有统一的符号以及语义，可以将所有项目根植与一种建模语言中，并对这些项目中的所有概念进行明晰的表示与定义，在很大程度上扩大了系统的应用范围，使UML建模技术的应用更为灵活。在UML中，主要包括图、事物以及关系这三个基本构造。具体而言，UML建模技术在软件工程中的应用主要有如下优势：第一，UML建模技术可以在系统模型中实现完全独立，虽然UML建模技术会与其余建模工具进行配合应用，但是并不会与系统的开发过程不产生交集；第二，UML建模技术在软件工程中的应用是面向对象的，打破了传统建模语言的差异性，可以通过统一的模型元素进行方法与图形的表述；第三，UML建模技术可以捕捉软件系统中的静态行为信息与动态行为信息，静态行为信息主要是指软件系统中对象，动态行为信息主要是从时间角度和状态角度对对象通讯的定义；第四，UML建模技术的和具体的实现没有关系，适用于所有语言平台或者工具平台，还能够应用于具有代码生成功能的交互式可视化建模工具，该工具可以为UML建模技术提供多种编程语言代码和程序构筑模型[1]。

2.软件工程中的UML建模技术应用模式

在软件工程中，UML建模技术主要通过视图的应用进行软件开发，UML建模技术一共可以提供八种图，实现软件系统开发的可视化以及模型化，以此获取软件系统的主要资料，从而明确软件系统的架构与体系。本文主要对常用的四种图进行分析：第一，用例图。在UML建模技术中，用例图是最基本的图。在软件工程中，需求分析阶段的重点在于需求获取，需求获取的重点在于系统模型的构建，系统模型构建的最佳方法就是用例图。用例图可以构建的用例模型可以为系统软件的开发奠定良好的基础。第二，类图。在UML建模技术中，类图主要用于表示不同实体（包括人、数据或者事物等）间的相关关系。在软件工程中，类图能够表示软件系统的静态结构，包括逻辑类图和实现类图这两种。其中，逻辑类图是指业务人员所说的事物种类，如保险-住房抵押-信贷-利率等；实现类图是指程序员负责的实体，但是并不会通过相同的属性进行描述，因为实现类图会进行HashMap或者Vec-tor等事物的引用。第三，序列图。在UML建模技术中，序列图能够主要用于具体用例流程的详细定义，主要通过自描述进行用例流程的定义，还能够表示用例流程中不同对象的不同调用关系。在实际的应用过程中，序列图的绘制过程较为简单，在横跨图的上部区域，不同的框代表每个类的对象，每个框中类的对象名称和类的名称使用空格/冒号/空格进行分隔，比如，MyReportGenerator：ReportGenera-tor。如果其中一个类对象向另一个类对象进行消息的发送，需要通过带有指向接收性质的连线来实现，技术人员需要将消息/方法的名称标注于于连线上。如果发送的消息较为重要，技术人员需要绘制带有指向发起性质的虚线，并将返回值标注于虚线上。第四，协作图。在UML1.1版本的时候，协作图被称作Collabo-rationDiagram，翻译为中文是协作图；在UML2.0版本的时候，协作图被称作CommunicationDiagram，翻译为中文是通讯图。但不论哪一种翻译方式，协作图都可以看做是序列图的全新表达方式。对于UML建模技术来说，序列图注重前后顺序，通过循环图或者分支结构来表示，而协作图则更为注重协同关系，协作图不能通过图像来表示[2]。

3.软件工程中的UML建模技术应用流程

在软件工程中，RationalRose能够满足现有全部建模环境的需求，在软件开发过程中，支持开发人员、分析人员和系统工程师将需求以及系统的机构转变为代码，从而实现需求以及系统的可视化。一般来说，软件开发过程包括需求分析、方案设计、方案实现、测试与配置等环节。

3.1需求分析环节

在软件工程的需求分析阶段，技术人员主要应用UML建模技术中的用例图，了解系统的所有需求，并对需求进行相应的描述。对于用例图而言，技术人员通过事件的应用实现用户与系统间的交互作用，并在用例图中表明用户能够实现的目标，还能够将功能分析以及需求分析中包含的系统模块，根据角色平均分配到不同用户中，提高系统模型的清晰度。

3.2设计环节

在软件工程的设计阶段，技术人员需要全面考虑所有软件开发技术的局限性，对需求分析阶段的系统模型进行进一步的扩展与细化。设计阶段的目标在于将系统模型转变为代码，对需求分析阶段提取的系统属性与操作进行细化，并添加更多的类处理，比如，用户接口、设备、数据库以及通信等。一般来说，软件工程的设计阶段包括两个部分，其一，结构设计，又被称作高层设计，主要任务是对包（即子系统）进行定义，主要定义的内容为包与包之间的依赖性以及通信机制，进一步实现结构的清晰化与简化，尽量减少各部分的依赖性，避免双向依赖关系的构建；其二，详细设计，这一部分主要是对包的细化，技术人员可以通过详细设计了解所有类的清晰全面描述。设计阶段中UML建模技术的应用包括类图和序列图这两种。首先，类图的应用，在软件工程中，类图属于静态视图，可以通过以下两种方式进行定义：通过问题域的概念进行定义、通过该类实际表示的内涵进行定义，技术人员需要根据系统需求分析以及系统用例进行类图的构建；然后，序列图的应用，在软件工程中，序列图属于动态视图，主要用于描述系统中各个对象的交互以及通讯，技术人员可以根据序列图了解对象实现某种功能时，是如何进行序列消息的发送与接受。

3.3实现环节

在软件工程中，实现环节就是指构造或者实现环节，主要工作内容为类的编程。一般来说，技术人员会将C#语言作为软件系统的开发环境，因为C#语言在逻辑试图转变为代码部件这一映射过程中，有显著的优势。在UML建模技术中，主要有以下几种图用于编码过程：第一，类的规格说明，不同类的规格说明体现了不同的属性与操作；第二，类图，能够显示软件系统中类的静态结构以及类之间的关系；第三，状态图，能够体现软件系统中类的对象现有的状态、需要处理的转移和转移需要触发的操作；第四，动态图，在编程过程中，动态图主要包括顺序图、活动图以及合作图这三种，主要用于体现对象应用该类对象的过程；第五，用例图及其规格说明，能够体现出软件系统的需求以及结果。

3.4测试与配置环节

当软件工程的系统编码全部完成之后，技术人员需要进行系统的全面测试，保障软件工程的质量。具体而言，测试环节分为系统测试、单元测试、验收测试以及集成测试这几种。对于系统测试来说，技术人员可以应用UML建模技术的用例图，测试开发的软件系统是否充分满足了用例图描述的需求；对于单元测试来说，技术人员可以应用UML建模技术的类图以及类的规格，对软件系统中单独的类或者成组的类进行测试；对于集成测试来说，技术人员可以应用UML建模就似乎的组件图以及合作图，测试软件系统中各个组件的合作状况[3]。

4.软件工程中的UML建模技术的应用实例

本文主要将在线人才招聘系统的市场管理和信息管理作为实例分析对象，进行软件工程中UML建模技术的应用研究。4.1人才招聘系统的登录界面设计对于人才招聘系统软件而言，登录界面的设计可以提高系统的管理水平。在进行登录界面的设计时，技术人员可以应用CustomLoginUI进行界面参数的传递，当用户输入登录信息并点击确定按钮之后，系统可以自动进行“sendMessage”，并应用HTTP进行服务器请求，在接收到CustomLoginUI的合法回复之后，即为用户登录成功，可以应用人才招聘系统进行相应的操作。4.2人才招聘系统中用例图的应用分析第一，人才招聘系统的管理人员会通过管理功能设定系统的基本信息，比如，招聘的岗位、岗位的任职要求和岗位的薪酬待遇等内容，招聘信息主要通过Web形式上传到Internet上。第二，应聘人员通过CustomLoginUI界面进行人才招聘系统的登录操作，当系统确认应聘人员的身份之后，即可登录系统。应聘人员可以在招聘信息下面填写个人信息，系统会将应聘人员的个人信息上传到在线人才管理系统中，个人信息也会通过Web形式上传到Internet上。第三，招聘人员可以在系统中查看应聘人员的个人信息，根据岗位的.要求以及应聘人员的履历，决定是否邀请应聘人员面试。需要邀请应聘人员时，招聘人员可以通过系统进行E-mail的发送。与此同时，管理人员需要将应聘人员的信息添加到人事档案库中，以数据文本的格式进行存储。第四，当招聘工作完成之后，管理人员需要将人才招聘系统关闭。在关闭的过程中，管理人员的决策可以看作是抽象角色，通过“fromUseCaseView”表示。管理人员实施的操作主要包括招聘活动的启动与停止、招聘信息的管理、人事档案与招聘信息的导出等。4.3人才招聘系统中类图的应用分析第一，类图的选择，技术人员需要根据人才资源系统的特点，通过同时得到类图的方式，应用stereotypeobject-entity、control、boundary等方法，确保角色可以有效应用于对象的通讯过程中，还能够保障序列图和协作图间的有效转换。第二，组件设计，技术人员需要将上一个步骤得到的类图进行实体映射，以此得到类图表。具体的映射方法如下：首先，将人才招聘系统中的实体进行单独的表的定义；然后，将实体表的继承网络结构删除，确保不同层次的实例具备一致的属性；最后，将人才招聘系统中的子类文件状态配置于相应的表中，并在组件中建立数据库，用于TaxDate等映射表的存储。第三，组件图的构建，技术人员需要通过控制类组件进行组件图的构建，如果技术人员采用的编程语言为C++，可以将控制类组件存储为（.h文件）或者（.ccp文件）。另外，对于源代码文件，技术人员可以应用包进行源代码的分组，并通过关联进行序列图的类信息显示。当组件图构建完成之后，技术人员需要将能够执行的主程序（即.exe文件）以及java语境链接库加入到组件图中，实现人才招聘系统的开发[4]。

5.结论

综上所述，UML建模技术可以提高软件开发的效率和有效性，值得推广应用。通过对软件工程中的UML建模技术分析可知，开发人员需要深入了解UML建模技术的各种视图及应用特点，在软件工程的各个阶段正确应用视图，充分发挥出UML建模技术的作用，提高软件工程的质量。希望本文可以为技术人员进行软件开发提供帮助。

参考文献

[1]陈冠元.软件工程中的UML建模技术[J].电子技术与软件工程,2018(05):47.

[2]刘传会.基于UML2.0顺序图的高可信实时软件建模技术研究[A].中国航空学会、中国航空研究院,2017,8.

[3]夏志龙.使用UML和Event-B构建基于云平台的应用软件模型[D].江苏科技大学,2016.

教学管理系统UML用例建模方法 第8篇

一、用例 (Use Case) 概念

用例 (Use Case) 的概念是Jacobson在1992年首先提出的。此后在Firesmith和Booch等几种软件开发方法中对于确切地描述用户需求中的功能需求;帮助发现系统中应设立哪些对象;核实每种功能需求是否有相应的对象予以满足等, 都起到了很好的促进作用, 因此受到人们的重视和好评。

二、系统需求分析

需求分析是系统开发中的一个重要步骤, 是整个系统开发的基础。需求分析的结果将直接影响到整个软件工程的成功与失败。如果需求定义错误 (如需求不完全、不合乎逻辑、不贴切或使人易于发生误解) , 那么不论以后的工作质量如何, 都必然导致系统开发的失败。大量实践证明, 信息系统产生的许多错误都是由于需求定义不准确或错误导致的。而且, 如果在需求定义阶段发生错误, 修改这些错误的代价是非常高的。因此, 信息系统开发中需求分析是系统成功的关键一步, 必须引起足够的重视。只有在正确的需求分析基础之上, 才能顺利完成系统的设计与实现工作。

三、用例 (Use Case) 建模

教学管理系统功能设计利用UML方法完成, 通过用例图描述了系统的主要功能及其使用的对象。

创建用例模型的工作包括:确定活动者和用例、描述用例、定义用例间的关系、最后确认模型。用例模型由用例图组成, 用例图展示了活动者、用例以及它们之间的关系。在创建用例模型时, 用户与开发者之间的积极合作和交流是十分重要的, 用户的参与使模型能够反映出用户所希望的细节, 并以用户的语言和术语来描述用例等。

USE CASE图可以按下列步骤建立:

1. 定义活动者。

活动者 (Actor) 是用户作用于系统的一个角色 (Role) 。活动者有自己的目标, 并且通过与系统的交互达到目标。

2. 定义USE CASE。

USE CASE本身是用户或其他系统与正在设计的系统的一个交互, 每一个USE CASE都是一个活动者与系统在交互中执行的有关事物序列。应当根据系统的需求找出全部的USE CASE, 并从活动者的角度给出事件流。当USE CASE执行时, 系统应提供给活动者服务。

3. 绘制USE CASE图。

USE CASE图是系统的外部行为视图。在确定了活动者和USE CASE的基础上绘制USE CASE图, 可以更清楚地了解系统的行为。绘制USE CASE图应先从顶层抽象开始, 然后逐步分解、精细化USE CASE图, 直到能清晰地表达问题、满足系统分析与建立模型的需要为止。基于前面的分析过程, 在此绘制了系统顶层用例图, 如图1所示。

四、结束语