企业综合信息管理系统UML需求建模用例图活动图教学文稿

合集下载

uml建模与设计模式绘制流程图实训步骤及内容

uml建模与设计模式绘制流程图实训步骤及内容
UML（Unified Modeling Language）建模和设计模式绘制流程图的实训步骤及内容可以分为以下几个部分：
1. 确定需求：首先，明确需要建模和设计的系统或软件的需求。

了解系统的功能、特性和约束条件，明确需求背景和使用场景。

2. 选择适当的UML图：根据需求和实际情况，选择合适的UML图，例如用例图、类图、序列图、活动图等。

每个UML图都有不同的用途和表达能力，根据需求选择合适的图形。

3. 绘制用例图：根据需求，绘制用例图来描述系统的功能需求和角色之间的关系。

用例图是用来描述系统功能和用户之间的交互关系的图形。

4. 绘制类图：根据需求，绘制类图来描述系统中的类、属性和方法之间的关系。

类图是用来描述系统中静态结构的图形。

5. 绘制序列图：根据需求，绘制序列图来描述系统中对象之间的交互流程和时间顺序。

序列图是用来描述系统中动态行为的图形。

6. 绘制活动图：根据需求，绘制活动图来描述系统中的业务流程和操作步骤。

活动图是用来描述系统中流程的图形。

7. 应用设计模式：根据需求和问题的性质，应用合适的设计模式来解决问题。

设计模式是一种被广泛接受的、可重复使用的解决方案，可以提高系统的可维护性和扩展性。

8. 优化和评估：根据建模和设计结果，进行优化和评估。

检查模型的准确性和一致性，找出潜在的问题和改进空间。

在整个实训过程中，需要遵循良好的建模和设计规范，确保模型的清晰和可理解性。

并且在绘制流程图时，要注重细节的准确性，保证图形的易读性和可操作性。

《系统分析与设计》课程教学大纲

《系统分析与设计》课程教学大纲课程英文名称：System analysis and design课程代码：R0902635 学时数：56 学分数：3.5课程类型：专业基础课程适用学科专业：软件工程先修课程：《面向对象程序设计》，《软件工程基础》，《数据库原理及应用》执笔者：编写日期：审核人：一、课程简介《系统分析与设计》是软件工程专业的专业基础课程。

学生通过该课程的学习，可掌握面向对象软件系统分析与设计的基本原理、方法与技术，培养软件系统建模分析、系统分析与设计、软件模块设计、软件界面设计等专业能力。

Software system architecture design is a professional basic course of software engineering. Through the study of this course, students can master the basic principles, methods and technologies of object-oriented software system analysis and design, and cultivate the professional abilities of software system modeling analysis, software system architecture design, software module design, software interface design, etc.二、课程目标课程达成度评价指标点达成度评价三、教学计划（一）教学内容、要求及教学方法本课程共56学时，课堂讲授40学时，课内实验16学时。

教学内容由如下章节组成：第1章系统分析与设计概述（CM1） 4学时教学方法：课堂面授。

采用课堂知识点讲授的教学方法，让学生理解课程内容的概念、原理和相关技术。

UML-企业综合信息管理系统--销售管理子系统

企业综合信息管理系统——销售管理子系统一、客户需求分析1、业务组织结构“企业综合信息管理系统”的用户是企业各级管理部门的工作人员、公司经理和系统操作人员。

该系统主要提供“财务管理”、“人力资源管理”、“生产调度管理”、“进销存管理”、“生产设备安全管理”和“行政事物管理”等方面的服务。

（1）财务管理企业“财务管理”部门管理企业的所有资金往来。

包括产品销售后资金的回收、购买原材料的资金支取、组织产品生产的开销、员工工资的发放、差旅费用的报销、固定资金的折旧、行政办公费用的支出等。

（2）人力资源管理“人力资源管理”部门负责对企业员工进行管理。

包括对员工进行招聘、录取、辞退工作，对各部门人员需求进行调配，考核，奖励惩罚等。

（3）生产调度管理“生产调度管理”部门负责企业的产品生产调度工作。

包括制定原材料采购计划、产品生产计划等。

（4）进销存管理“进销存管理”部门实际上负责整个企业产品的销售、原材料的购进、产品及原材料的存储和产品的售后服务。

（5）生产设备安全部门“生产设备安全管理”部门负责企业所有生产设备和工作人员的安全生产管理。

包括企业生产设备登记造册，即使维修设备等。

（6）行政事务管理“行政事务管理”部门负责对企业的行政事务进行管理。

包括制定计划购买办公用品，对员工的福利、工资进行审批、发放等。

2、具体功能要求（1）销售管理*制定销售计划*与客户签订销售合同*检查合同履约率*组织生产*对产品进行入库、出库处理*财务管理部门收取客户货款*售后服务（2）采购部门*制定原材料采购计划*与客户签订采购计划*检查合同约率*库存管理部门对原材料进行入库验收、存储*财务管理部门支付货款（3）库存管理*产品入库管理*原材料入库管理*原材料出库管理*产品出库管理*库存管理*采购管理部门组织采购*生产调度部门安排生产*财务管理部门对库存货物资产进行核算3.需求补充说明（1）数据保存进销存管理子系统需要长久包保存在数据库中的数据有：采购合同，销售合同，历年履约合同，库存货物清单，货物损毁报表，入库单，出库单，库存货物资产核对表（2）系统的用户进销存管理子系统的用户包括客户、仓库管理员、销售人员、采购人员、公司经理、财务管理系统、生产调度管理系统等（3）系统运行用户界面销售合同管理用户界面，采购合同管理用户界面，仓库货物清单管理用户界面（4）系统运行的软件、硬件环境执行者：采购人员，销售人员，仓库管理员，客户，公司经理，生产调度管理子系统，财务管理子系统二、系统的UML建模（1）“企业综合信息管理系统”中的用例财务管理，人力资源管理，生产调度管理，进销存管理，生产设备安全管理，行政事务管理。

UML系统建模基础教程教学资料ppt课件

UML统一建模语言
三、用例的重要元素
2、用例的粒度
用例的粒度指的是用例所包含的系统效力或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之那么包含的功能越少。
假设用例的粒度很小，得到的用例数就会太多。反之，假设用例的粒度很大，那么得到的用例数就会很少。
假设用例数目过多会呵斥用例模型过大和引入设计困难大大提高。假设用例数目过少会呵斥用例的粒度太大，不便于进一步的充分分析。
UML统一建模语言
一、什么叫用例图
2、用例图的作用
用例图是需求分析中的产物，主要作用是描画参与者和用例之间的关系，协助开发人员可视化的了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家可以以可视化的方式对问题进展讨论，减少了大量交流上的妨碍，便于对问题达成共识。
用例图可视化地表达了系统的需求，具有直观、规范等优点，抑制了纯文字性阐明的缺乏。
UML统一建模语言
三、用例的重要元素
1、识别用例
任何用例都不能在短少参与者的情况下独立存在。同样，任何参与者也必需求有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开场，在这个过程中往往会发现新的参与者。
可以经过以下问题来寻觅用例： 1 参与者希望系统提供什么功能？ 2 参与者能否会读取、创建、修正、删除、存储系统的某种信息？假设是的话，参与者又是如何完成这些操作的？ 3 参与者能否会将外部的某些事件通知给系统？ 4 系统中发生的事件能否通知参与者？ 5 能否存在影响系统的外部事件。
UML统一建模语言
二、用例图的构成要素
3、系统边境
在工程开发过程中，边境是一个非常重要的概念。这里说的系统边境是指系统与系统之间的界限。通常我们所说的系统可以以为是由一系列的相互作用的元素构成的具有特定功能的有机整体。

UML系统需求分析建模实例包括业务建模

UML系统需求分析建模实例包括业务建模一、背景某公司为了提高内部管理效率，决定开发一个在线人事管理系统。

该系统主要目标是帮助公司员工和管理人员更好地进行人事管理工作，包括员工信息管理、薪资管理、请假管理等功能。

二、业务建模1. 参与者- 员工：具有查看和修改个人信息的权限。

- 人事部门：负责对员工信息进行管理、薪资管理和请假管理。

- 管理员：拥有所有功能权限。

2. 用例图用例图展示了系统的功能视图，包括主要的参与者和他们的交互。

（图1：用例图）3. 用例描述- 查看个人信息：员工可以查看自己的个人信息，包括个人资料、联系方式和工作历史。

- 修改个人信息：员工可以修改自己的个人信息，如联系方式和地址等。

- 管理员登陆：管理员可以使用管理员账号登陆系统。

- 管理员工信息：管理员可以查看和修改员工信息，包括添加员工、删除员工和修改员工信息等。

- 薪资管理：人事部门可以查看和修改员工薪资信息。

- 请假管理：人事部门可以管理员工的请假信息，包括请假申请和批准等。

4. 状态图状态图描述了系统中的一个对象或参与者的状态变化。

（图2：状态图）5. 类图类图展示了系统中的类以及它们之间的关联。

（图3：类图）三、系统分析1. 需求分析对于查看个人信息的用例，系统应该提供一个界面给员工输入自己的员工号，然后显示员工的个人信息。

对于修改个人信息的用例，系统应该提供一个界面给员工输入员工号和想修改的信息，然后保存修改后的信息。

对于管理员登陆的用例，系统应该提供一个界面给管理员输入管理员账号和密码进行登陆。

对于管理员工信息的用例，系统应该提供一个界面给管理员查看和修改员工信息，包括添加、删除和修改员工信息。

对于薪资管理的用例，系统应该提供一个界面给人事部门查看和修改员工薪资信息。

对于请假管理的用例，系统应该提供一个界面给人事部门管理员工的请假信息，包括请假申请和批准。

2. 非功能性需求- 界面友好：系统应该提供直观、易用的界面来满足用户的需求。

UML系统建模与分析设计-需求分析与用例建模PPT课件

异常事件流处理：
（1）标识码有效性检查失败，允许学生重新输入（3次机会）。（2）注册识别失败，没有注册（尙未交学费）的学生不能选课。（3）选择课程确认失败，所选几门课程中在上课时间上发生冲
突时，系统提示重选。
2021/1/16
-
15
3.2.6 用例之间的关联
1．继承关联
2．扩展关联
2021/1/16
-
16
3．包含关联 4．使用关联
2021/1/16
-
17
考虑用例的关联类型
2021/1/16
-
18
2021/1/16
-
19
3.2.7 用例图实例
2021/1/16
-
20
3.3 定义系统的对象和类
类 - 责任 - 协作者（ Class-ResponsibilityCollaborator，简称CRC）技术：
2021/1/16
-
41
（4）“采购管理子系统”中的用例（第三层） • 制定采购计划； • 签订采购合同； • 货物入库检验； • 支付货款； • 检查合同履约。（5）“库存管理子系统”中的用例（第三层） • 入库管理； • 出库管理； • 库存管理。
2021/1/16
-
42
3.6.5 分层绘制用例图
2021/1/16
-
35
2．具体功能要求
本案例只对其中的“进销存管理子系统”进行详细的需求分析用例建模。
（1）销售管理 1）制定销售计划 2）与客户签订销售合同 3）检查合同履约率 4）生产调度管理部门组织生产 5）库存管理部门对产品进行入库、出库处理 6）财务管理部门收取客户货款 7）售后服务

UML系统需求分析建模实例包括业务建模(ppt28张)

系统用例着重于要设计的软件系统。参与者如何与软件系统进行交互？我们在系统用例说明中书写的事件流应该足够详细，从而用作编写系统测试脚本的出发点。系统用例几乎总是以黑盒形式编写的。它们描述了软件系统之外的参与者如何与将被设计的系统进行交互。系统用例详细阐明了系统需求。系统用例模型的目的是从涉众的角度说明需求，而不是设计如何满足需求。
后记Ｉ－系统分析
ห้องสมุดไป่ตู้
员工报销申请用例实现的分析类时序图
后记II-系统分析
VOPC类图
后记II-系统设计

系统架构选择什么框架基于框架和架构的时序图
• • • • • • • • • • • • • • • • • • • •
1、想要体面生活，又觉得打拼辛苦；想要健康身体，又无法坚持运动。人最失败的，莫过于对自己不负责任，连答应自己的事都办不到，又何必抱怨这个世界都和你作对？人生的道理很简单，你想要什么，就去付出足够的努力。 2、时间是最公平的，活一天就拥有24小时，差别只是珍惜。你若不相信努力和时光，时光一定第一个辜负你。有梦想就立刻行动，因为现在过的每一天，都是余生中最年轻的一天。 3、无论正在经历什么，都请不要轻言放弃，因为从来没有一种坚持会被辜负。谁的人生不是荆棘前行，生活从来不会一蹴而就，也不会永远安稳，只要努力，就能做独一无二平凡可贵的自己。 4、努力本就是年轻人应有的状态，是件充实且美好的事，可一旦有了表演的成分，就会显得廉价，努力，不该是为了朋友圈多获得几个赞，不该是每次长篇赘述后的自我感动，它是一件平凡而自然而然的事，最佳的努力不过是：但行好事，莫问前程。愿努力，成就更好的你！ 5、付出努力却没能实现的梦想，爱了很久却没能在一起的人，活得用力却平淡寂寞的青春，遗憾是每一次小的挫折，它磨去最初柔软的心智、让我们懂得累积时间的力量；那些孤独沉寂的时光，让我们学会守候内心的平和与坚定。那些脆弱的不完美，都会在努力和坚持下，改变模样。 6、人生中总会有一段艰难的路，需要自己独自走完，没人帮助，没人陪伴，不必畏惧，昂头走过去就是了，经历所有的挫折与磨难，你会发现，自己远比想象中要强大得多。多走弯路，才会找到捷径，经历也是人生，修炼一颗强大的内心，做更好的自己！ 7、“一定要成功”这种内在的推动力是我们生命中最神奇最有趣的东西。一个人要做成大事，绝不能缺少这种力量，因为这种力量能够驱动人不停地提高自己的能力。一个人只有先在心里肯定自己，相信自己，才能成就自己！ 8、人生的旅途中，最清晰的脚印，往往印在最泥泞的路上，所以，别畏惧暂时的困顿，即使无人鼓掌，也要全情投入，优雅坚持。真正改变命运的，并不是等来的机遇，而是我们的态度。 9、这世上没有所谓的天才，也没有不劳而获的回报，你所看到的每个光鲜人物，其背后都付出了令人震惊的努力。请相信，你的潜力还远远没有爆发出来，不要给自己的人生设限，你自以为的极限，只是别人的起点。写给渴望突破瓶颈、实现快速跨越的你。 10、生活中，有人给予帮助，那是幸运，没人给予帮助，那是命运。我们要学会在幸运青睐自己的时候学会感恩，在命运磨练自己的时候学会坚韧。这既是对自己的尊重，也是对自己的负责。 11、失败不可怕，可怕的是从来没有努力过，还怡然自得地安慰自己，连一点点的懊悔都被麻木所掩盖下去。不能怕，没什么比自己背叛自己更可怕。 12、跌倒了，一定要爬起来。不爬起来，别人会看不起你，你自己也会失去机会。在人前微笑，在人后落泪，可这是每个人都要学会的成长。 13、要相信，这个世界上永远能够依靠的只有你自己。所以，管别人怎么看，坚持自己的坚持，直到坚持不下去为止。 14、也许你想要的未来在别人眼里不值一提，也许你已经很努力了可还是有人不满意，也许你的理想离你的距离从来没有拉近过......但请你继续向前走，因为别人看不到你的努力，你却始终看得见自己。 15、所有的辉煌和伟大，一定伴随着挫折和跌倒；所有的风光背后，一定都是一串串揉和着泪水和汗水的脚印。 16、成功的反义词不是失败，而是从未行动。有一天你总会明白，遗憾比失败更让你难以面对。 17、没有一件事情可以一下子把你打垮，也不会有一件事情可以让你一步登天，慢慢走，慢慢看，生命是一个慢慢累积的过程。 18、努力也许不等于成功，可是那段追逐梦想的努力，会让你找到一个更好的自己，一个沉默努力充实安静的自己。 19、你相信梦想，梦想才会相信你。有一种落差是，你配不上自己的野心，也辜负了所受的苦难。 20、生活不会按你想要的方式进行，它会给你一段时间，让你孤独、迷茫又沉默忧郁。但如果靠这段时间跟自己独处，多看一本书，去做可以做的事，放下过去的人，等你度过低潮，那些独处的时光必定能照亮你的路，也是这些不堪陪你成熟。所以，现在没那么糟，看似生活对你的亏欠，其实都是祝愿。

UML系统分析与设计02－用例图和活动图（下）

UML系统分析与设计02－⽤例图和活动图（下）在上⼀篇《》中，我们主要讲解了在需求分析中的⽤例分析和绘制的⽅法和技巧，但是⽤例图只告诉我们系统要“做什么”，⾄于“怎么做”却并没有很直观的描述。

为了更形象的说明我们的系统是如何⼀⼀满⾜⽤户需求的，并向⽤户提供“怎么做”的细节描述，我们将使⽤“活动图”来对⽤例进⾏补充性说明。

[ 注意：UML中并没有说“活动图”是⽤于对“⽤例图”补充说明，但就我个⼈⽽⾔我更喜欢这样来定义它，并在实践中进⾏应⽤。

][ 技巧：UML图⼀般会分为静态图和动态图。

⽤例图属于静态图，⽽后⽽所述的“活动图”属于动态图。

在我们对某个问题进⾏分析和设计时⼀般都会使⽤静态图和动态图相结合的⽅式来进⾏说明和描述。

]四、 Activity Diagram（VS2010⼯具⽰例图）五、活动图1、活动图中的三板斧通过上图我们会发现，其实Activity Diagram还是有很多元素的，其实在我们的⼯作中你会发现在⼤部分时候我们并不需要对于这“⼗⼋般武艺”样样精通，其实只需三板斧即可！第⼀板：开始－结束第⼆板：分⽀－合并第三板：分叉－联结当然，要让这三板斧连贯起来我们还得有节点“Action”和线“Connector”。

(上⾯的命名为我个⼈习惯，可能有误)2、参考⽰例①：“创建唱⽚”⽰例：②：“管理订单”⽰例：③：当然还有很多其它的元素这⾥并没有提到，我们将在后继说明中陆续讲解，我个⼈认为在当前的分析阶断，重点⽤“三板斧”来解决。

在架构设计和概要设计时我们还会⽤到其它的⼀些元素。

3、没有“泳道”“泳道”UML在进⾏“活动图”时，⼀个⾮常直观好⽤的⼯具，但在VS2010中去并未提供，很遗憾在最新的VS11Bate版中也未提供对“泳道”的⽀持，感兴趣的朋友也只能⽤替代⽅案了。

⽅法如下：从“Sinple Shapes”中拖⼊⼀个“Rectangle”,分别设置它的“Line Thickness”为“0.01”、“Color”为“=DarkGray”。

跟我学统一建模语言UML——UML用例图及在项目中的应用示例

1.1跟我学统一建模语言UML——UML用例图及在项目中的应用示例1.1.1UML用例图及在项目中的应用示例1、什么是用例图（1）用例图在面向对象需求分析方法中，通常使用用例（Use Case）来获取软件系统的需求。

Use Case通过描述“系统”和“活动者”之间的交互状况来描述软件系统的行为。

通过分解系统目标，Use Case描述活动者为了实现这些目标而执行的所有步骤。

（2）为什么要采用用例图来描述需求用例图是一种图形化的工具，它用简单的图形元素表示出系统的参与者、用例以及它们之间的联系。

通过用例图能够较好地避免了表达的歧义性，便于用户和系统开发人员理解系统的需求，取得共识。

（3）用例图中的参与者和用例之间的通信参与者和用例之间的使用关系，在用例图中表示为一个带箭头的直线。

如下为某项目中的用例图示例：（4）用例图的主要作用1)利用用例图可以实现从用户角度来描述系统所应该具有的功能，同时并能够指出各功能的操作者；也能够显示出与软件系统进行交互的外部参与者及其使用方式。

2)通过用例图可以表示正在构造的新系统应该具有什么的功能,同时对已经构造完毕的系统，则反映了系统能够完成什么样的功能注意：1)用例内容描述包含了定义系统实际需求和功能的重要信息。

2)除了可以用用例以外，用户还可以选择另一种方式：绘制活动图3)然而，记住以下这一点是很重要的：用例应该便于与最终用户沟通，如果采用比较正式的结构，如活动图，可能会使人们不习惯对用例的内容进行解释，从而造成沟通上的不便。

（5）用例图的组成元素在一个UML的用例图中，一般主要包含有系统边界（有的UML工具软件部创建出系统边界线）、参与者、用例和用例关系（通信、使用和扩展等三种形式）。

2、应用Use Case方法最主要的优点（1）在于它是用户导向的用户可以根据自己所对应的Use Case来不断细化软件系统项目的需求。

此外，使用Use Case还可以方便地得到软件系统功能的测试用例。

企业综合信息管理系统UML需求建模(用例图+活动图)

管理课件
2
（2）采购管理
1）制定原材料（零部件）采购计划 2）与客户签订采购合同 3）检查合同履约率 4）库存管理部门对原材料进行入库验收、存储 5）财务管理部门支付货款
（3）库存管理
1）产品入库管理 2）原材料（零部件）入库管理 3）原材料（零部件）出库管理 4）产品出库管理 5）库存管理 6）采购管理部门组织采购 7）生产调度管理部门安排生产 8）财务管理部门对库存物资进行核算
与其它用例的关联：过程描述（1）中包含身份验证用例；（4）
中包含编号自动生成用例。
异常事件流处理：
（1）标识码有效性检查失败：系统检测标识码有效性失败，
允许重新输入。
（2）编号也可以由合同管理员手动输入，系统自动进行唯一
性检查。出现错误，允许重新输入。
2．“修改合同”用例
……………
2020/11/27
•制定产品销售计划； •签订销售合同； •督促客户付款；
•监督产品发货；
•检2020查/11/2合7 同履约；
管理课件
7
（4）“采购管理子系统”中的用例（第三层） • 制定采购计划； • 签订采购合同； • 货物入库检验； • 支付货款； • 检查合同履约。（5）“库存管理子系统”中的用例（第三层） • 入库管理； • 出库管理； • 库存管理。
3.6 需求分析用例建模案例
3.6.1 客户需求分析
1．业务组织结构（综述）
“企业综合信息管理系统”的用户是企业各级管理部门的工作人员、公司经理和系统操作人员。该系统主要提供 “财务管理”、“人力资源管理”、“生产调度管理”、 “进销存管理”、“设备安全管理”、和“行政事务管理” 等方面的服务。
2020/11/27

UML 用例图、关系图、活动图

网上查询读者扩展预定扩展
查询图书馆工作人员取消预定
还书
通知
借书
武当山旅游门户网站（）分类信息
注意

在画用例图时要特别注意：用例图是系统分析、设计和实现的一个最基础的图形，在初期是不一定要考虑太多的处理细节。一个用例内部的具体处理细节是由其他图形工具描述的，用例图只是反映系统的总体功能，以及与这些功能的相关的角色。有些人可能在画“借书”用例时，情不自禁地就考虑了“输入读者号和书号”，“检查图书是否在库？”，“图书数量减1”，“添加读者借书记录”等等，一旦考虑了这些细节，就会发现用例图画不下去了。因此，读者注意用例图中不要考虑处理细节。
武当山旅游门户网站（）分类信息
注意：

活动图描述多个角色之间的处理非常有效，一张活动图只能有一个开始状态，但可以有多个结束状态。一个活动可以与多个实体对象相关，这里的相关指的是一种访问操作。在上面 “借书”活动图中，“检查读者有效” 的活动，要访问“读者”对象和“借还书记录”对象，检查“读者编号”的有效性和读者借书数量。
状态图中的转移可以由三部分组成：事件[条件]/动作
武当山旅游门户网站（）分类信息
角色

角色是指与系统交互的人或物。角色可以有四种类型：系统的使用者、硬件设备、外部系统和时间。

系统使用者是最重要的角色，例如，在图书信息管理系统中的系统使用者有读者和图书馆的工作人员，包括采购、编目和办公室的工作人员。其他外部应用系统。硬件设备，不同的硬件设备具有不同的特性和不同的处理方式。时间作为角色,经过一定的时间触发系统中的某个事件。
认识活动图认识活动图图书馆图书信息管理系统借书活动图图书馆图书信息管理系统借书活动图借书申请检查读者有效性读者信息借书记录读者无效图书无效检查图书有效性检查预订预订记录清除预订记录图书信息借书记录修改图书信息创建借书记录图书信息读者无效借书超期图书无效有预订读者流通组工作人员读者图书编号活动图中的主要图形元素活动图中的主要图形元素泳道