软件工程实践-学生-UML建模案例分析
UML建模实验报告02
UML建模实验报告02UML建模实验报告021.实验目的本实验的目的是通过实际项目案例，了解和掌握使用UML建模工具进行软件系统建模的过程和方法。
2.实验过程本次实验我们选择了一个简单的在线购物系统作为项目案例。
首先，我们进行了需求分析，确定了系统的功能和特性。
然后，我们进行了领域建模，识别出了系统的核心概念和实体。
接下来，我们进行了用例建模，识别出了系统的用例，并绘制了用例图。
然后，我们进行了行为建模，设计了系统的顺序图和活动图。
最后，我们进行了结构建模，设计了系统的类图和对象图。
3.实验结果通过本次实验，我们成功完成了在线购物系统的建模过程，并获得了以下结果：1)需求分析：我们确定了系统的功能和特性，包括用户登录、浏览商品、添加到购物车、下订单等。
2)领域建模：我们识别了系统的核心概念和实体，包括用户、商品、购物车、订单等，并绘制了类图。
3)用例建模：我们识别了系统的用例，并绘制了用例图，包括登录、浏览商品、添加到购物车、下订单等。
4)行为建模：我们设计了系统的顺序图和活动图，包括用户登录、浏览商品、添加到购物车、下订单等的流程和交互。
5)结构建模：我们设计了系统的类图和对象图，识别了系统的类和对象，包括用户、商品、购物车、订单等。
4.实验总结通过本次实验，我们深入了解和体验了使用UML建模工具进行软件系统建模的过程和方法。
我们发现UML建模工具可以很好地帮助我们理清系统的功能和特性，识别出系统的核心概念和实体，设计系统的用例、顺序图、活动图、类图和对象图。
通过建模过程，我们可以更加清晰地理解系统的需求和设计，并与团队成员进行有效的沟通和协作。
同时，我们也发现UML建模工具的使用需要一定的学习和实践，尤其是对于一些高级建模概念和技术的掌握。
因此，我们认为在今后的实践中，需要进一步学习和应用UML建模工具，以提高我们的建模能力和技术水平。
5.实验改进建议根据本次实验的经验和总结，我们提出以下改进建议：1)在实验前进行必要的学习和准备，了解UML建模工具的基本概念和使用方法，以充分发挥工具的功能和效能。
UML建模案例分析
确定候选类： 学生、学习计划、成绩单、教授、课程、班级
3. 标识类属性
确定候选类的描述属性的相关方法：
（1）在候选类筛选过程中，有些名词或名词短语已经确定为描述属性，如“学位”为学生的描述属性、 “听课位置”、听课时间、学期是班级类的描述属性；
相关用例：
系统登录 建立学习计划 查询授课班级信息
5 建立用例和演员之间的关系
• 利用演员和用例的交叉引用表，来描述用例和演员之间的关系：
启动演员
用例 • 系统登录 • 建立学习计划 • 审核学习计划 • 注册课程班级 • 取消注册课程 • 查询授课班级信息 • 查询学生信息 • 查询学生成绩单 • 公布课程成绩 • 维护后台基础数据
图
UML语言定义了五种类型，9种不同的图，把它们 有机的结合起来就可以描述系统的所有视图。
用例图(Use case diagram) 从用户角度描述系统功 能,并指出各功能的操作者。
静态图(Static diagram),表示系统的静态结构。包 括类图、对象图、包图。
行为图(Behavior diagram)，描述系统的动态模型 和组成对象间的交互关系。包括状态图、活动图。
交互图(Interactive diagram), 描述对象间的交互关 系。包括顺序图、合作图。
实现图( Implementation diagram ) 用于描述系统的 物理实现。包括构件图、部件图。
SRS系统用例建模
1、了解系统需求，需要寻求以下问题答案
• （1）谁将使用待开发的系统？ • （2）系统需要提供什么有价值的服务？ • （3）当用户与系统交互时，他们期待什么效果？
学生最迟可以在学期的第一个星期末决定退出所选课程班级。
uml软件建模报告
课程设计报告题 目 学生宿舍管理系统课 程 名 称 软件系统分析与建模课程设计 院 部 名 称 龙蟠学院 专 业 计算机科学与技术 班 级 M10计算机科学与技术 学 生 姓 名 卢礼刚 学 号 ********** 课程设计地点 A201 课程设计学时 20 指 导 教 师 李 慧金陵科技学院教务处制成绩学生宿舍管理系统1.案例分析目标本案例采用UML的方式对学生宿舍管理系统进行分析和设计，通过对学生宿舍的建模来对UML进行更加详细的了解和熟悉。
基于以上我们对学生宿舍的了解和对学校宿舍楼管理老师的咨询，我们小组成员：包云卢礼刚2.背景分析2.1宿舍楼的基本情况学生住在宿舍楼中，每栋宿舍楼都会有若干名老师负责本宿舍楼的日常管理。
一、学生的基本信息：入校时，每位同学都有唯一的学号，并被分配到指定的宿舍楼和指定的宿舍，也会有一个宿舍号，其入校时间就是他的入住时间。
另外，为了管理上的方便，同一院系的学生的宿舍一般在一起，相应地会有其所在的院系名称。
宿舍的基本信息：每间宿舍都有唯一的宿舍号2.2用户对系统的要求一、宿舍楼管理员：a.信息要求：宿舍楼管理员能查询上面提到的宿舍楼的所有相关信息，包括某一学号的学生在宿舍楼中住宿的详细信息，夜归的详细信息和学生离返校的信息。
以利于对整个宿舍楼的全面管理。
b.处理要求：当学生基本信息发生变化时，宿舍楼管理员能对其进行修改。
比如，某些同学搬到其他的宿舍中去，他们在本宿舍楼中相应的记录就应该删去；或者学生转换专业，他们记录中院系的信息也要作相应的修改等等。
c．安全性与完整性要求：安全性要求：1.系统应设置访问用户的标识以鉴别是否是合法用户，并要求合法用户设置其密码，保证用户身份不被盗用；2.系统应对不同的数据设置不同的访问级别，限制访问用户可查询和处理数据的类别和内容；3.系统应对不同用户设置不同的权限，区分不同的用户，如区分普通用户（学生），管理员。
二、本宿舍楼的学生：信息要求：本宿舍楼的学生能查询其所在的宿舍的所有信息。
软件架构实验UML建模
通过分析参与者的活动，可以初步确定这样一些用例：
（1）查询信息，（2）学生管理，பைடு நூலகம்3）宿舍分配，（4）住宿管理，（5）基础数据管理，（6）财务管理，（7）时钟支持。
根据前面的需求分析，针对本实验分别建立系统的用例视图（Use-Case View）、逻辑视图（Logical View）。
分析用例，从用例中寻找对象和类。例如，通过分析宿舍分配管理子系统，可以发现以下实体类：学生、宿舍管理员、班级、楼栋、床位等。建立类图。
2.1、静态分析阶段，通过分析该系统的子系统，寻找出实体类，并建立类图。（由于子系统较多，所以就以上述所举的例子宿舍分配管理子系统为例建立类图）
2.2、系统的动态分析——用顺序图表示用例的实现，画出高校学生宿舍管理系统的登录顺序图。（以宿舍管理员登录管理系统进行住宿管理为例画出登录顺序图）
四、实验要求
1、根据上述描述中确定的用例，自己确定每个用例的参与者，并画出关于高校学生宿舍管理系统的用例视图（Use-Case View）。
2、逻辑视图（LogicalView）关注系统是如何实现用例中所描述的功能的，主要是对系统功能性需求提供支持，即在为用户提供服务方面，系统所应该提供的功能。在逻辑视图中，用户将系统更加仔细地分解为一系列的关键抽象，将这些大多数来自于问题域的事物通过采用抽象、封装和继承的原理，使之表现为对象或对象类的形式，借助于类图和类模板等手段，提供系统的详细设计模型图。类图用来显示一个类的集合和它们的逻辑关系有关联、使用、组合、继承关系等。
2.3、利用UML的活动图工具进行工作流程建模，画出学生入住业务流程（活动图）。（提示：
学生的入住业务流程，一般来说是，学生先到宿舍管理中心申请入住，然后学生到财务管理中心尽心缴费，宿舍管理中心回到学生管理中心进行学生信息的核对，如果学生缴费成功并且学生管理中心的学生身份认证正确，那么宿舍管理中心就给学生分配宿舍，否则，任何一个环节出现错误就会取消入住。）
软件工程与uml案例解析
软件工程与uml案例解析咱们来唠唠软件工程和UML（统一建模语言）。
一、软件工程那点事儿。
软件工程就像是盖房子，你不能乱盖一气，得有个规划。
比如说，有个小团队要开发一个电商APP。
首先得搞清楚需求，就像你要知道盖房子的人想要啥样的房子，几个卧室、客厅多大之类的。
这个电商APP呢，用户得能轻松注册登录、浏览商品、下单付款，商家得能管理商品库存、处理订单。
这就是需求分析的阶段。
然后就进入设计环节啦。
这就好比设计房子的蓝图，哪里是厨房，哪里是卫生间都得安排好。
在软件工程里，要考虑软件的架构，是用传统的三层架构（表示层、业务逻辑层、数据访问层）呢，还是搞点新花样，像微服务架构啥的。
对于这个电商APP，可能表示层得设计得特别漂亮，让用户看着舒服，业务逻辑层要处理好商品搜索、价格计算这些复杂的逻辑，数据访问层要稳稳地和数据库交互，确保数据不丢失、不出错。
二、UML闪亮登场。
UML就像是一种超级厉害的建筑绘图语言，不过是给软件用的。
1. 用例图。
拿电商APP来说，用例图能清晰地展示谁（参与者）在用这个APP干啥。
比如说，用户这个参与者，可以登录、搜索商品、下单；商家这个参与者，可以添加商品、查看订单。
用例图就像一张地图，告诉你这个软件世界里不同角色的行动路线。
画这个图的时候，就像在画一幅漫画，简单又直观。
2. 类图。
这就像是在给软件里的各种“角色”（类）画人物关系图。
在电商APP里，有用户类、商品类、订单类等等。
用户类可能有姓名、年龄、地址这些属性，还有登录、注册这些方法。
商品类有商品名称、价格、库存这些属性。
订单类和用户类、商品类有着千丝万缕的关系，比如一个订单对应一个用户，一个订单包含多个商品。
类图把这些关系都明明白白地摆出来，就像给软件里的元素做了一次详细的家族族谱。
3. 时序图。
时序图可有趣了。
它像是在演一场戏，按照时间顺序展示对象之间的交互。
比如说用户下单这个过程，用户先选择商品，然后系统检查库存，库存够的话就生成订单，再从用户账户里扣钱。
21年电大软件工程形考3使用 UML进行系统建模实验报告
使用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建模实例分析PPT课件
UML建模 实例分析
-
1
电梯控制监视系统
背景
18层楼，2部电梯 （m层楼，n部电梯）
需求
控制：电梯上下运行载客至指定楼层 监视：当前电梯位置及状态
-
2
主要需求描述
初始所有电梯停在1楼，处于等待服务 状态
乘客通过按动每层楼的按钮呼叫电梯 当电梯到达所请求的楼层的时候，它
将打开门5秒钟，然后关上门 乘客通过按动电梯内控制面板上的按
-
14
课内实验
要求： 学习体系结构设计思路 掌握UML模型图画法（用例图、类图、
活动图、状态图、协作图、序列图） 提交设计说明文档
-
15
钮来与电梯系统进行交互
-
3
主要需求描述
如果乘客在电梯内按了去第X层的按钮， 电梯将移向第X层
如果没有新的呼叫，电梯将停在最后 到达的楼层
其他更多需求描述
中途呼叫请求的处理 多部电梯响应的协调 服务效率与能耗的平衡
-
4
建模总流程
需求分析 关键问题识别 体系结构设计 初始模型设计 主体模型设计 模型评估与改进 模型细化与完善
-
8
初始模型设计
目的：以粗颗粒度、粗线条方式来对 系统进行初步设计
途径：没有固定的套路，根据所设计 的系统特点，可以有不同的构思方法
一般情况下，可以从用例图、类图、 活动图开始着手
-
9
用例图 类图 活动图 状态图 协作图 序列图
主体模型设计
-
10
模型评估与改进
模型是否正确 模型是否一致 模型是否便于维护 模型是否能进一步改进
-
5
需求分析 明确系统边界
哪些该做，哪些不该做
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
功能需求模块
信息浏览查询模块 基本业务模块
数据库管理模块
§1.2 数据信息管理模块
• 数据信息管理模块包含的功能： ① 教师信息管理 ② 课程简介信息管理 ③ 文件上传信息的管理
数据信息模块
文件上传信息管理 课程简介信息管理 教师信息管理
§1.3 基本业务模块
• 基本业务模块包含的功能： ① 文件上传 ② 文件下载 ③ 消息发布 ④ 消息修改和更新 ⑤ 页面维护 ⑥ 用户注册批准
• 13、无论才能知识多么卓著，如果缺乏热情，则无异 纸上画饼充饥，无补于事。Sunday, June 21, 202021-Jun-
2020.6.21
• 14、我只是自己不放过自己而已，现在我不会再逼自 己眷恋了。20.6.Байду номын сангаас103:42:1421 June 202003:42
3. 系统管理员进行网站维护的活动图
§3 系统中的类
• 1. 类图的生成 • 2. 各个类之间的关系
1. 类图的生成
① 参与者相关的类 ② 一些其他的类
（1）参与者相关的类
（2）一些其他的类
2. 各个类之间的关系
§4 系统的配置与实现
系统的配置图
•
1、有时候读书是一种巧妙地避开思考 的方法 。20.6. 2120.6. 21Sunday, June 21, 2020
•
7、最具挑战性的挑战莫过于提升自我 。。20 20年6 月上午3 时42分 20.6.21 03:42J une 21, 2020
•
8、业余生活要有意义，不要越轨。20 20年6 月21日 星期日3 时42分 14秒03 :42:142 1 June 2020
•
9、一个人即使已登上顶峰，也仍要自 强不息 。上午 3时42 分14秒 上午3时 42分03 :42:142 0.6.21
UML建模案例分析
-网络教学系统UML建模
• §1 网络教学系统的需求分析 • §2 系统的UML基本模型 • §3 系统中的类 • §4 系统的配置与实现
§1 网络教学系统的需求分析
• §1.1 系统功能需求 • §1.2 数据信息管理模块 • §1.3 基本业务模块 • §1.4 信息浏览、查询模块
•
2、阅读一切好书如同和过去最杰出的 人谈话 。03:4 2:1403: 42:1403 :426/2 1/2020 3:42:14 AM
•
3、越是没有本领的就越加自命不凡。 20.6.21 03:42:1 403:42 Jun-202 1-Jun-2 0
•
4、越是无能的人，越喜欢挑剔别人的 错儿。 03:42:1 403:42: 1403:4 2Sunda y, June 21, 2020
• 10、你要做多大的事情，就该承受多大的压力。6/21/2
020 3:42:14 AM03:42:142020/6/21
• 11、自己要先看得起自己，别人才会看得起你。6/21/2
谢 谢 大 家 020 3:42 AM6/21/2020 3:42 AM20.6.2120.6.21
• 12、这一秒不放弃，下一秒就会有希望。21-Jun-2021 J une 202020.6.21
§2.2 系统的用例图
• 创建用例图之前首先需要确定参与 者。
• 系统中的参与者主要有三类： ① 教师 ② 学生 ③ 系统管理员
§2.2 系统的用例图
• 1. 系统用户参与的总的用例图 • 2. 学生参与的用例图 • 3. 教师参与的用例图 • 4. 系统管理员参与的用例图
1. 系统用户参与的总的用例图
基本业务模块
用户批准注册
页面维护 消息修改和更新 消息发布 文件上传 文件下载
§1.4 信息浏览、查询模块
• 信息浏览、查询模块主要用于网页 上信息的浏览、搜索，包括：
① 网页信息浏览 ② 文章信息搜索
信息浏览查询模块
文章信息搜索 网页信息浏览
§2 系统的UML基本模型
• §2.1 建立UML初始模型 • §2.2 系统的用例图 • §2.3 系统的时序图 • §2.4 系统的协作图 • §2.5 系统的状态图 • §2.6 系统的活动图
•
5、知人者智，自知者明。胜人者有力 ，自胜 者强。 20.6.21 20.6.21 03:42:1 403:42: 14June 21, 2020
•
6、意志坚强的人能把世界放在手中像 泥块一 样任意 揉捏。 2020年 6月21 日星期 日上午3 时42分 14秒03 :42:142 0.6.21
§1.1 系统功能需求
• 系统的功能需求主要包括以下几个方面：
① 学生可以登录网站浏览信息、查找信息 和下载文件。
② 教师可以登录网站输入课程简介、上传 课件文件、发布消息、修改和更新消息。
③ 系统管理员可以对页面维护以及批准用 户的注册申请。
§1.1 系统功能需求
• 系统主要包括以下几个模块： ① 数据库管理模块 ② 基本业务模块 ③ 信息浏览、查询模块
• 1. 用户登录系统的协作图 • 2. 学生下载文件的协作图
1. 用户登录系统的协作图
2. 学生下载文件的协作图
§2.5 系统的状态图
§2.6 系统的活动图
• 1. 用户登录系统的活动图 • 2. 教师上传课件的活动图 • 3. 系统管理员进行网站维护的活动
图
1. 用户登录系统的活动图
2. 教师上传课件的活动图
2. 学生参与的用例图
3. 教师参与的用例图
4. 系统管理员参与的用例图
§2.3 系统的时序图
• 1. 系统管理人员管理网站的时序图 • 2. 用户登录系统的时序图 • 3. 学生下载文件的时序图
1. 系统管理人员管理网站的时序图
2. 用户登录系统的时序图
3. 学生下载文件的时序图
§2.4 系统的协作图