软件工程实践-学生-UML建模案例分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

课程设计报告题 目 学生宿舍管理系统课 程 名 称 软件系统分析与建模课程设计 院 部 名 称 龙蟠学院 专 业 计算机科学与技术 班 级 M10计算机科学与技术 学 生 姓 名 卢礼刚 学 号 ********** 课程设计地点 A201 课程设计学时 20 指 导 教 师 李 慧金陵科技学院教务处制成绩学生宿舍管理系统1.案例分析目标本案例采用UML的方式对学生宿舍管理系统进行分析和设计，通过对学生宿舍的建模来对UML进行更加详细的了解和熟悉。

基于以上我们对学生宿舍的了解和对学校宿舍楼管理老师的咨询，我们小组成员：包云卢礼刚2.背景分析2.1宿舍楼的基本情况学生住在宿舍楼中，每栋宿舍楼都会有若干名老师负责本宿舍楼的日常管理。

一、学生的基本信息：入校时，每位同学都有唯一的学号，并被分配到指定的宿舍楼和指定的宿舍，也会有一个宿舍号，其入校时间就是他的入住时间。

另外，为了管理上的方便，同一院系的学生的宿舍一般在一起，相应地会有其所在的院系名称。

宿舍的基本信息：每间宿舍都有唯一的宿舍号2.2用户对系统的要求一、宿舍楼管理员：a.信息要求：宿舍楼管理员能查询上面提到的宿舍楼的所有相关信息，包括某一学号的学生在宿舍楼中住宿的详细信息，夜归的详细信息和学生离返校的信息。

以利于对整个宿舍楼的全面管理。

b.处理要求：当学生基本信息发生变化时，宿舍楼管理员能对其进行修改。

比如，某些同学搬到其他的宿舍中去，他们在本宿舍楼中相应的记录就应该删去；或者学生转换专业，他们记录中院系的信息也要作相应的修改等等。

c．安全性与完整性要求：安全性要求：1.系统应设置访问用户的标识以鉴别是否是合法用户，并要求合法用户设置其密码，保证用户身份不被盗用；2.系统应对不同的数据设置不同的访问级别，限制访问用户可查询和处理数据的类别和内容；3.系统应对不同用户设置不同的权限，区分不同的用户，如区分普通用户（学生），管理员。

二、本宿舍楼的学生：信息要求：本宿舍楼的学生能查询其所在的宿舍的所有信息。

软件工程与uml案例解析咱们来唠唠软件工程和UML（统一建模语言）。

一、软件工程那点事儿。

软件工程就像是盖房子，你不能乱盖一气，得有个规划。

比如说，有个小团队要开发一个电商APP。

首先得搞清楚需求，就像你要知道盖房子的人想要啥样的房子，几个卧室、客厅多大之类的。

这个电商APP呢，用户得能轻松注册登录、浏览商品、下单付款，商家得能管理商品库存、处理订单。

这就是需求分析的阶段。

然后就进入设计环节啦。

这就好比设计房子的蓝图，哪里是厨房，哪里是卫生间都得安排好。

在软件工程里，要考虑软件的架构，是用传统的三层架构（表示层、业务逻辑层、数据访问层）呢，还是搞点新花样，像微服务架构啥的。

对于这个电商APP，可能表示层得设计得特别漂亮，让用户看着舒服，业务逻辑层要处理好商品搜索、价格计算这些复杂的逻辑，数据访问层要稳稳地和数据库交互，确保数据不丢失、不出错。

二、UML闪亮登场。

UML就像是一种超级厉害的建筑绘图语言，不过是给软件用的。

1. 用例图。

拿电商APP来说，用例图能清晰地展示谁（参与者）在用这个APP干啥。

比如说，用户这个参与者，可以登录、搜索商品、下单；商家这个参与者，可以添加商品、查看订单。

用例图就像一张地图，告诉你这个软件世界里不同角色的行动路线。

画这个图的时候，就像在画一幅漫画，简单又直观。

2. 类图。

这就像是在给软件里的各种“角色”（类）画人物关系图。

在电商APP里，有用户类、商品类、订单类等等。

用户类可能有姓名、年龄、地址这些属性，还有登录、注册这些方法。

商品类有商品名称、价格、库存这些属性。

订单类和用户类、商品类有着千丝万缕的关系，比如一个订单对应一个用户，一个订单包含多个商品。

类图把这些关系都明明白白地摆出来，就像给软件里的元素做了一次详细的家族族谱。

3. 时序图。

时序图可有趣了。

它像是在演一场戏，按照时间顺序展示对象之间的交互。

比如说用户下单这个过程，用户先选择商品，然后系统检查库存，库存够的话就生成订单，再从用户账户里扣钱。

使用UML进行系统建模实验报告[图书管理系统]一．实验目的针对指定软件系统的需求进行分析和设计；使用Microsoft Visio软件，绘制UML 图。

二．实验设备计算机、Microsoft Visio软件。

三．实验内容及步骤1、介绍这篇文档提供了对图书馆图书管理系统的系统架构的总揽，从不同的视角描述了该系统。

同时介绍了图书馆图书管理系统的功能性需求，通过用例说明书、物理模型、静态结构模型和动态行为模型来进行全面的展示介绍。

2、实验要求图书馆图书管理系统的域描述如下：在图书管理系统中，要为每个借阅者建立一个账户，并给借阅者发放借阅卡（借阅卡可以提供借阅卡号、借阅者名），账户中存储借阅者的个人信息、借阅信息以及预定信息。

持有借阅卡的借阅者可以借阅书刊、返还书刊、查询书刊信息、预定书刊并取消预定，但这些操作都是通过图书管理员进行的，也即借阅者不直接与系统交互，而是图书管理员充当借阅者的代理与系统交互。

在借阅书刊时，需要输入所借阅的书刊名，书刊的ISBN/ISSN 号，然后输入借阅者的图书卡号和借阅者名，完成后提交所填表格，系统验证借阅者是否有效（在系统中存在账户），若有效，借阅请求被接受，系统查询数据库系统，看借阅者所借阅的书刊是否存在，若存在，则借阅者可借出书刊，建立并在系统中存储借阅记录。

借阅者还书后，删除关于所还书刊的借阅记录。

如果借阅者所借的书刊已被借出，借阅者还可预定该书刊，一旦借阅者预定的书刊可以获得，就将书刊直接寄给预定人（为了简化系统，预定书刊可获得时就不通知借阅者了）。

另外，为了简化系统，也不考虑书刊的最长借阅期限，假设借阅者可以无限期地保存所借阅的书刊。

对上述图书管理系统的域描述进行分析，可以获得如下功能性需求：（1）借阅者持有借阅卡（借阅者名和借阅卡号）；（2）图书管理员作为借阅者的代理借书；（3）图书管理员作为借阅者的代理预定书刊；（4）图书管理员作为借阅者的代理取消预定；（5）图书管理员作为借阅者的代理还书；（6）图书管理员可以创建新的借阅者账户；（7）图书管理员可以修改借阅者的账户信息；（8）图书管理员可以删除已存在的借阅者账户；（9）图书管理员可以添加新书刊种类；（10）图书管理员可以修改书刊种类信息；（11）图书管理员可以删除系统中的书刊种类；（12）图书管理员可以在系统中添加书刊信息；（13）图书管理员可以编辑书刊信息；（14）图书管理员可以删除书刊信息；对上述系统进行建模，按照下列要求完成实验报告。

软件工程试验一：用例图
班级：信121
姓名：黄成运
学号：2108191211112
一、试验目的
通过本次试验使学生掌握UML建模语言的基础知识和rose软件的基本用法，并进一步熟练掌握绘制业务用例框图和用例文档基本步骤和方法。

二、试验要求
根据实验题目内容，完成相应的实验任务。

三、实验内容
1.一个新的音像商店准备采用计算机系统向比较广泛的人群销售或租借录像带和
光碟。

该音像商店将存有大约1000 盘录像带和500 张光碟，所有的录像带和光碟都有一个条码，可以使用条码扫描仪来支持销售和返还，客户会员卡也同时条码化。

客户可以预定录像带并在指定日期来取。

系统必须拥有灵活的搜索机制来回答客户的询问。

根据上述描述，请你给出音像租赁销售系统的业务用例模型和系统用例模型，任选一个系统用例写出用例文档。

2.可以根据本小组自定的系统完成用例图和用例文档。

四、实验结果
客户信息管理业务用例图
该客户信息管理主要实现对客户信息的增加、删除、修改和查询。

系统用例图。

UML中的用例图实践案例UML（统一建模语言）是一种用于软件开发的标准化建模语言，它提供了一套丰富的图形符号和概念，用于描述和设计软件系统的各个方面。

其中，用例图是UML中最为常用和重要的一种图形表示方法，它用于描述系统的功能需求和用户与系统之间的交互关系。

本文将通过一个实践案例，介绍用例图在软件开发中的具体应用。

假设我们要开发一个在线购物系统，该系统包括用户注册、浏览商品、添加购物车、下单、支付等功能。

首先，我们需要明确系统的角色和用例。

在这个案例中，系统的角色包括用户、管理员和支付网关。

用户可以注册账号、浏览商品、添加购物车、下单和支付；管理员可以管理商品信息；支付网关负责处理支付请求。

接下来，我们可以使用用例图来表示这些角色和用例之间的关系。

首先，我们可以在用例图中用椭圆形表示各个用例。

在本案例中，我们可以用椭圆形表示注册账号、浏览商品、添加购物车、下单和支付等用例。

然后，我们可以用矩形表示各个角色，即用户、管理员和支付网关。

接着，我们可以使用实线箭头来表示角色与用例之间的关系。

例如，用户可以注册账号，我们可以在用户和注册账号之间画一条实线箭头来表示这种关系。

除了角色和用例之间的关系，用例图还可以表示用例之间的关系。

在本案例中，用户可以浏览商品、添加购物车、下单和支付，这些用例之间存在一定的先后顺序。

我们可以使用虚线箭头来表示这种顺序关系。

例如，用户可以先浏览商品，然后将商品添加到购物车，最后下单和支付。

我们可以在浏览商品和添加购物车之间画一条虚线箭头，表示用户在浏览商品后可以将商品添加到购物车。

此外，用例图还可以表示用例之间的包含和扩展关系。

在本案例中，用户下单时可能需要选择配送地址，我们可以将选择配送地址作为一个包含关系，用一个带有加号的实线箭头表示。

另外，用户下单时还可以选择使用优惠券，这可以作为一个扩展关系，用一个带有箭头和加号的虚线箭头表示。

通过用例图，我们可以清晰地描述系统的功能需求和用户与系统之间的交互关系。

UML业务建模实例分析在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。

我们在日常生活中也经常和ATM打交道。

本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。

参与者"银行储户"和ATM机。

简化后的ATM机仅有取款、存款及其余功能。

其余功能不做详细说明。

图5.1 自动取款机（ATM）系统用例图银行储户在ATM机上完成取款、存款及其他业务。

图5.2所示的银行系统类图和图3.5是类似的，只是将工作人员换成了ATM。

整个银行系统包括了帐户库、银行储户库及ATM系统。

许多单个的帐户组成了帐户库。

帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。

六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。

setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。

getType获取帐户类型，返回类型为char，无参数。

setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。

getAccountNumbe获取帐户号，返回类型为int，无参数。

caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。

getBalance获取帐户余额，返回类型为double，无参数。

许多银行储户组成了储户库。

ATM系统包含了许多ATM机。

银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。