用例建模实验报告

软件系统分析与设计实验报告学院：计算机科学与技术学院专业：软件工程学号：*********姓名：***实验名称：图书管理系统用例建模时间：一、实验内容与要求本实验要求学生对学校的图书馆管理系统进行需求分析，对系统功能进行用例建模，画出用例图，类图以及相应的时序图。

在使用UML对系统建模时，学会使用UML建模工具，熟悉工具中的功能。

二、用例分析1、读者“借书还书系统”用例图(f书书(from Use Cases)1．1、行为者：主要行为者：读者。

1．2、前置条件：读者进入图书管理系统。

1．3、事件流：1.3.1、主要事件流：1.3.1.1：读者检索所需图书信息，并查看；1.3.1.2：读者检索到所需图书，登录系统，开始借书；1.3.1.3：系统查询图书信息，图书数目是否可借；1.3.1.3.1：图书显示可借，借书成功；1.3.1.3.2：图书显示不可借，借书失败；1.3.1.4：进入续借图书界面，续借图书；1.3.1.5：系统查看预约记录，1.3.1.5.1：没有冲突，续借成功；1.3.1.5.2：有冲突，续借失败；1.3.3.1：1.3.1.6：读者归还图书；1.3.1.6.1：归还时间没有逾期，归还成功；1.3.1.5.2：归还时间逾期，逾期处罚，归还成功；1.3.2、备选事件流：1.3.2.1：图书检索信息失败，未检索到图书，重新输入信息检索；1.3.2.2：未曾检索到用户检索的图书，系统显示相关联的信息的图书；1.3.2.3：用户名或密码输入错误，登录系统失败，重新输入用户名或密码登录；1.3.2.4：系统显示图书不可借后，进入图书预约界面，输入信息预约图书；1.3.3、异常事件流：1.3.3.1：读者登录系统失败，未曾注册用户；1.3.3.1.1：返回系统注册用户后，重新登录。

1．4、后置条件：退出系统。

1．5、1．6、扩展点：无。

2、“图书信息管理系统”用例图书书书书书书(f书书书书(from Use Cases)(from Use Cases)2．1、行为者：主要行为者：管理员；2．2、前置条件：管理员打开图书信息管理系统；2．3、事件流：2.3.1：主要事件流：2.3.1.1：图书管理员输入管理员登录信息，登录系统；2.3.1.2：进入图书信息管理界面，查看已有图书信息，是否有需要购入图书；2.3.1.2.1：录入新购进图书信息，并确认；2.3.1.3：进入读者信息管理界面，管理已有用户信息；2.3.1.4：进入信息通知界面，查看已有用户图书借阅、预约情况；2.3.1.4.1：查看读者所预约图书，自动查询图书信息，确认是否已有可借图书，有则通知读者；2.3.1.4.2：查询读者已借图书信息，根据已借时间及归还时间分类；2.3.1.4.2.1：所借图书即将逾期，启动系统提醒功能；2.3.1.4.2.2：所借图书已经逾期，启动逾期及处罚通知功能；2.3.2：备选事件流：2.3.2.1：管理员用户名或登录名错误，重新登录；2.3.2.2：需要购进新图书，存储信息，通知相关人员；2.3.2.3：读者预约图书没有可借图书，不予通知；2.3.2.4：预约通知提醒后，删除该预约记录；2.3.2.5：读者所借图书距离归还时间仍很久，无需通知；2.3.3：异常事件流：2.3.3.1：登录失败超过一定次数后，系统冻结该用户名，一段时间后可以重用；2．4、后置条件：退出系统；2．5、扩展点：无。

UML建模实验报告02UML建模实验报告021.实验目的本实验的目的是通过实际项目案例，了解和掌握使用UML建模工具进行软件系统建模的过程和方法。

2.实验过程本次实验我们选择了一个简单的在线购物系统作为项目案例。

首先，我们进行了需求分析，确定了系统的功能和特性。

然后，我们进行了领域建模，识别出了系统的核心概念和实体。

接下来，我们进行了用例建模，识别出了系统的用例，并绘制了用例图。

然后，我们进行了行为建模，设计了系统的顺序图和活动图。

最后，我们进行了结构建模，设计了系统的类图和对象图。

3.实验结果通过本次实验，我们成功完成了在线购物系统的建模过程，并获得了以下结果：1)需求分析：我们确定了系统的功能和特性，包括用户登录、浏览商品、添加到购物车、下订单等。

2)领域建模：我们识别了系统的核心概念和实体，包括用户、商品、购物车、订单等，并绘制了类图。

3)用例建模：我们识别了系统的用例，并绘制了用例图，包括登录、浏览商品、添加到购物车、下订单等。

4)行为建模：我们设计了系统的顺序图和活动图，包括用户登录、浏览商品、添加到购物车、下订单等的流程和交互。

5)结构建模：我们设计了系统的类图和对象图，识别了系统的类和对象，包括用户、商品、购物车、订单等。

4.实验总结通过本次实验，我们深入了解和体验了使用UML建模工具进行软件系统建模的过程和方法。

我们发现UML建模工具可以很好地帮助我们理清系统的功能和特性，识别出系统的核心概念和实体，设计系统的用例、顺序图、活动图、类图和对象图。

通过建模过程，我们可以更加清晰地理解系统的需求和设计，并与团队成员进行有效的沟通和协作。

同时，我们也发现UML建模工具的使用需要一定的学习和实践，尤其是对于一些高级建模概念和技术的掌握。

因此，我们认为在今后的实践中，需要进一步学习和应用UML建模工具，以提高我们的建模能力和技术水平。

5.实验改进建议根据本次实验的经验和总结，我们提出以下改进建议：1)在实验前进行必要的学习和准备，了解UML建模工具的基本概念和使用方法，以充分发挥工具的功能和效能。

实验报告课程名称UML软件建模实验名称图书管理系统的分析与设计专业计算机科学与技术班级1002班学号201003010237姓名李志鹏指导教师张铁楠2013年9 月10 日目录实验一用例建模 (3)实验二静态结构建模 (7)实验三动态行为建模 (10)实验四物理模型 (27)实验一用例建模实验报告实验名称图书管理系统的用例建模评分实验日期2013 年9 月12 日第五、六节课指导教师张铁楠姓名李志鹏专业班级计算机1002 班学号201003010237一、实验目的熟悉用例图的基本功能和使用方法，掌握如何使用建模工具绘制用例图方法。

二、实验环境1.硬件：●处理器：●内存：●硬盘空间：●显卡：2.软件：Rational Rose 2003或Microsoft Visio 2003三、实验内容与要求完成对系统的需求建模，得到用例模型后，应针对每个用例进行业务分析，说明其具体的业务流程，现系统分析部指派您完成该项任务。

要求：对其中主要功能的用例书写书面用例。

对每个用例的进一步描述可以活动图，这一部分在动态建模来完成。

四、实验步骤1)用例模型的建立本系统共设置四个活动者。

分别是TT_People、TT_Registrar、TT_Reader和TT_Database。

其中TT_People泛指与系统发生关系的人；TT_Registrar为系统管理员，负责添加、修改图书信息；TT_Reader为所有读者，读者可能发生借书、续借、还书的行为；TT_Database为存储各种信息的数据库对象。

另：考虑到现实图书馆中还存在“图书馆管理员”这一角色，但其所起的作用仅为代替读者完成各种系统操作，故没有设置此活动者。

系统中共有五个用例。

TT_Addinfo、TT_Modifyinfo、TT_Borrow、TT_Renew和TT_Return。

TT_Addinfo表示管理员添加图书信息；TT_Modifyinfo表示修改图书信息；TT_Borrow表示读者借阅图书；TT_Renew表示读者续借图书；TT_Return 表示读者归还图书。

UML建模课程实验二、UML用例模型的设计班级：信息0702 组别：指导老师：徐凯波姓名：王姗学号：2007030331205一、实验要求：掌握利用UML建模工具建立用例模型的方法二、实验内容：利用UML建模工具设计用例模型三、实验环境：Windows 2000 Professional以上环境、Rational Rose2003、Sybase Power Designer 10四、操作步骤：本系统是学生选课管理系统，学生可以通过登录该系统查询课程信息、选课、查询个人选课记录；管理员可以通过登录该系统修改课程信息、查询课程信息、添加课程信息、删除课程信息以及对学生的信息进行维护。

（一）第一层（二）学生选课管理系统五、遇到的问题和解决方法：用例图作为整个系统建模最开始的阶段，是最基础的部分，在刚开始的时候的确遇到了不少问题。

首先是确定要做一个关于什么时候的系统，系统不能做的太小也不能太大，最好该系统能接近日常生活。

在一开始的时候我想做一个关于图书管理系统，但是由于选择图书管理系统的同学太多，所以就放弃了这一想法，后来通过看书、PPT以及在网上查阅资料，最终我决定做一个关于学生选课管理系统，因为作为一名学生，学生选课管理系统比较贴近我的生活。

确定完选题之后，第二步就是要确定该系统的角色和用例。

在这一过程中，我出现了很多错误，在做用例图时，我是先从角色（小人）出发，都有谁参与了该系统，然后想该系统的功能，但总是想的不全面，于是在课下的时候，我找到老师，徐老师说用例图首先应从系统出发，想想该系统都能实现哪些功能，然后在考虑都有哪些角色参与了该系统，在徐老师细心的指导下，我确定该用例图应包括：登陆系统功能、查询课程信息功能、选课功能、查询个人选课记录功能、修改课程信息功能、添加课程信息功能、删除课程信息功能以及对学生的信息进行维护功能等。

参与该系统的角色有：学生、管理员。

确定好角色与系统功能后，绝应该在RationalRose软件中将用例图画出来，在这一过程中我经常搞混<<extend>>和<<include>>、还有箭头的指向，我发现课上老师讲的知识，虽然认真听了，但用在实际的操作中，还是会出现错误，我又从新翻看课本以及PPT，最终在老师的帮助下弄清楚了<<extend>>和<<include>>含义，一张完整的用例图就完成了，为以后的实验奠定了一个好的基础。

昆明理工大学信息工程与自动化学院学生实验报告（2012 —2013 学年第 2 学期）课程名称：软件工程开课实验室：信自楼445 2013 年5月17日一、实验目的：1) 掌握 UML 的用例建模的方法。

2) 实践用 UML 建立用例模型。

3）用PowerDesigner绘制电话订购系统用例图。

4) 熟悉使用PowerDesigner软件，绘制描述取款用例的活动图。

5）画其它图形来熟悉SybasePowerDesigner软件。

二、实验内容：了解用例建模相关知识，熟悉使用Power Designer，绘制活动图、用例图。

UML 用例模型（也称需求模型）用于描述的是外部执行者所理解的软件系统的功能，也即用户对系统的功能性需求。

用例模型由若干用例图组成。

一幅用例图包含的模型元素有系统、用例、执行者，以及它们之间（包括执行者与系统之间、用例之间）的相互关系。

其中用例代表系统的功能，执行者代表使用这些功能的用户。

用例经常被作为独立的单位进行需求获取、分析设计、实施、测试和部署。

但事实上，用例之间有一定的相关性，表现为涉及的对象相近和若干用例处于一个相关的业务流中。

这些相关的用例构成了结构设计时定义子系统的依据。

三、所用仪器微型计算机一台 SybasePowerDesigner15.1软件四、实验过程及截图：1、用例建模相关知识A.用例建模的步骤包括：1) 确定系统范围、用例和执行者；2) 描述用例；3) 用例分类、确定用例之间的关联；4) 建立用例图；5) 定义用例图的层次结构；6) 审核用例模型。

B．用例的文字描述应包括以下内容：1) 用例的目的（功能）；2) 该用例在什么情况下被哪个执行者启动执行；3) 用例与执行者之间交互哪些消息来通知对方作出决定；4) 交互的主消息流及因此被使用或修改的实体；5) 用例中可供选择的异常事件流；6) 用例结束标志：给执行者返回一个可识别的值。

2、电话订购系统用例图《》电话订购系统用例图（167）3、描述取款用例的活动图4、为了熟悉SybasePowerDesigner软件我还画了如下图形：（1）能结构图266功能结构图（2）数据流图（3）图书库存五、实验总结和分析：通过本次实验对用UML用例模型描述软件系统的功能性需求有了一定的了解，功能性需求是说有具体的完成的内容的需求。

---------------------------------------------------------------最新资料推荐------------------------------------------------------05-建立用例模型模型实验1. 实验环境及设备要求⑴每人需要有可接入 Internet 的计算机一台，并可登录网络化实验管理域跟踪系统。

⑵计算机安装有 Microsoft Visio 2003。

2. 实验目的⑴掌握用例模型的设计与创建方法。

⑵掌握如何使用 Microsoft Visio 2003 建立用例图模型。

3. 实验（设计）任务某汽车配件公司，向顾客供应汽车配件，顾客是汽车用户或是汽车修配厂，配件公司的货源来自各种不同的配件制造工厂或批发商。

顾客可以当时购买，也可以预先订货，公司负责托运。

汽车配件公司管理系统由销售、采购和会计三个系统组成。

系统的主要逻辑功能和基本目标如下：⑴顾客的订货要求有三种形式，一是邮寄订货单，二是打电话，三是直接到汽车配件公司营业部来办理。

⑵不管用哪种方式，都以一种标准的订货单格式输入到系统内。

⑶对每一张订货单必须首先加以验证，是否填写正确。

验证的内容包括汽车配件名称、规格、编号、顾客名称、地址、电话、开户银行、帐号等信息。

⑷如果正确无误才能给以处理。

⑸如果有错误、应当输出错误信息，通知业务人员加以纠正。

1 / 5⑹按订货项目检索配件库存，确定是否能够满足顾客的要求。

⑺如果当前的库存量能够完全满足顾客的要求，销售子系统开出发货单给顾客提货，并记入应收款明细帐以备会计收款，同时记入，销售历史存档，还要修改该配件库存量。

⑻如果这项配件的当前库存量不能全部满足顾客的订货要求，只能暂时提供一部分，那么对这部分配件办理销售业务(同第 7 条) ；同时还要把暂时不能满足的部分记录到暂存订货单文件中，通知采购子系统向供应商订货。

⑼如果这项配件现在一件也没有，就要把这张订货单记录到暂存订货单文件中，并通知采购子系统向供应商订货。

实验一熟悉ROSE并建立用例模型一、实验目的1）掌握Rational Rose的特点、运行环境及获取方法；2）掌握Rational Rose基本使用方法；3）掌握使用Rational Rose绘制用例图的步骤；二、实验内容根据《简单的学生选课管理系统》采用面向对象分析方法给出系统的用例模型（用例图及课程注册用例描述）。

三、建模思路1、系统角色分析学生选课管理系统主要满足三方面的需求，分别是学生用户、教师用户和管理员用户，也即三类用户角色（1）学生用户是主要需求者，主要功能需求是查询新学期将开设的课程和讲课教师情况，选择自己要学习的课程进行“课程注册”，并可以查询成绩单；（2）教师用户主要功能需求是查询新学期将开设的课程和选课学生情况，并可以登记成绩单；（3）管理员的功能需求较复杂，进行教师信息、学生信息和课程信息的维护，开启和关闭“课程注册”。

2、rose建模步骤2.1.环境简介2.1.1 Rational Rose可视化环境组成Rose界面的五大部分是浏览器、文档工具、工具栏、框图窗口和日志。

1、浏览器：用于在模型中迅速漫游。

2、文档工具：用于查看或更新模型元素的文档。

3、工具栏：用于迅速访问常用命令。

4、框图窗口：用于显示和编辑一个或几个UML框图。

5、日志：用于查看错误信息和报告各个命令的结果。

2.1.2浏览器和视图浏览器是层次结构，用于在Rose模型中迅速漫游。

在浏览器中显示了模型中增加的一切，如参与者、用例、类、组件等等。

浏览器中包含四个视图：Use Case视图、Logical视图、Component视图和Deployment 视图。

点击每个视图的右键，选择new就可以看到这个视图所包含的一些模型元素。

2.1.3框图窗口我们可以浏览模型中的一个或几个UML框图。

改变框图中的元素时，Rose自动更新浏览器。

同样用浏览器改变元素时，Rose自动更新相应框图。

这样，Rose就可以保证模型的一致性。

UML实验报告（5篇）第一篇：UML实验报告UML 实验报告实验一用例图一、实验结果1、整理实验结果2、小结实验心得体会用例模型用于需求分析阶段，它描述了待开发系统的功能需求，并驱动了需求分析之后各阶段的开发工作。

用例图是UML中用来对系统的动态方面进行建模的7种图之一。

用例图描述了用例、参与者以及它们之间的关系。

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

通过本次实验，我熟悉Rational Rose 建模环境，更加清楚的了解了用例图的语义和功能，如何清晰明了的识别参与者、用例，学会了如何使用事件流描述用例。

同时掌握了用例间的类属关系、Include 关系和Extend关系的语义、功能和应用。

最后通过本次实验学习了如何使用用例图为系统的上下文以及系统的需求建模。

二、思考题1、如果要删除参与者、用例，请问是在导航窗口删除，还是在绘图窗口删除？答：都可以删除，但在绘图窗口中有两种删除方式：一种是只删除参与者、用例，而不改变其在导航窗口中的存在，另一种是从建模中完全删除。

2、如果要删除参与者和用例的联系，用例和用例的联系，请问是在绘图中删除，还是在参与者或用例的设置对话框中删除？答：都可以删除。

实验二类对象模型的建立一、实验结果 1．整理实验结果。

2．小结实验心得体会。

类图是面向对象系统建模最常用的图，描述了类图、接口集、协作以及它们之间的关系。

类图描述了系统的静态设计视，该视主要体现系统的功能需求，即系统应该提供给用户的服务。

通过本次实验，加深了我对类图语义的理解和功能的应用，掌握了类之间的联系，关联、依赖、聚合等，同时基本掌握了在Rational Rose中绘制类的关联、依赖、泛化关系。

二、思考题选中一个模型对象，点击鼠标右键，比较快捷菜单项“Edit——Delete”与“Edit——Delete from Model”，它们二者之间区别在哪里？答：“Edit——Delete”只删除绘图窗口中的图形，而不改变其在导航窗口中的存在；“Edit——Delete from Model” 是从建模中完全删除。

实验报告2.类图的绘制类图(Class diagram)是最常用的UML图，显示出类、接口以及它们之间的静态结构和关系，它用于描述系统的结构化设计，类图(Class diagram)最基本的元素是类或者接口。

本实验中，我们依据一个剧院购票系统的类构成情况，进行类图的绘制。

本例中，共有顾客(Customer)，预定（Reservation），季票（Seasonal），单次票（One Time），门票（Ticket），表演（Performance）和剧院（Theatre）七大类。

我们首先将各类及功能图绘制完成，如下图。

接下来，根据各类之间的相互关系，我们对将各类通过不同方式连接。

容易理解，顾客类具有预定的功能，即预定类与客户类相关联，并具有单向性。

而预定的过程分为季票预定和单次预定，两者相结合构成预定类的从属类。

无论通过哪种方式成功订票，顾客都将获得门票，顾门票类是季票类和单次票类的关联类；同时，门票显示表演场次，因此，门票类同时是表演类的关联类。

最后，表演在特定剧场开展，故表演类和剧场类为聚合相关关系。

根据上述关系，我们绘制了该例的类图。

3.序列图的绘制序列图（Sequence Diagram）是一种UML行为图，它通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。

它可以表示用例的行为顺序，当执行一个用例行为时，时序图中的每条消息对应了一个类操作或状态机中引起转换的触发事件。

我们以用户调用一个数组内容的过程为例。

该过程中共有三个对象：用户接口（UserInterface），数据控制（DataControl）和数据源（DataSource），三者分别对应一条生命线，如下图。

当用户请求调用数组内容时，用户接口端向数据控制端发送一个请求，这时控制端将向数据源发送请求数组大小的指令。

数据源检索后，向控制端返回数组大小。

此时，控制端开始根据数组大小进行循环，逐个向数据源申请调用数组内容，数据源一一返回。