UML系统建模与分析设计-需求分析与用例建模PPT课件
合集下载
02需求分析与用例建模
9.3 面向对象的需求分析
– 用例组织： 对用例图分层
9.3 面向对象的需求分析
– 用例组织注意：在建模的开始阶段，不要对它 进行过细的分解，以免使得模型中出现过多的 用例而影响了对系统功能和结构的总体把握。
3.5.3 层次化用例图
用例的粒度问题
(1) 用例的粒度问题 对于一个目标系统进行用例分析后得到
财务管理系统、生产调度管理系统。
（3）系统运行用户界面 销售合同管理用户界面 采购合同管理用户界面 仓库货物清单管理用户界面
（4）系统运行的软件、硬件环境 1）系统运行的软件环境 2）系统运行的硬件环境
3.6.2 确定系统范围和系统边界
1．进销存管理子系统的业务范围 2．进销存管理子系统的系统边界
• 9.3.4 系统需求建模 – 系统需求建模：将业务需求转化成系统需 求。
• 业务需求主要是从用户的角度去分析系统的业务流 程；
• 系统需求则是从开发者的角度去分析业务流程，并 得出新系统要实现的功能。
– 系统用例模型比业务用例模型更详细、更 具说明性。
9.3 面向对象的需求分析
• 9.3.4.1 系统参与者与系统用例
– 系统用例：为了反映用户界面约束之类的实现 细节，从业务用例中导出应用性的用例，称为 系统用例。
• 可以从一个业务用例中导出一个或多个系统用例。 • 开发人员使用这种用例说明详细的需求，辅助评价和规划，交
流编程需求，形成用户文档的基础。
9.3 面向对象的需求分析
• 9.3.4.2 确定用例间的关系：包含、泛化和扩展
• 请用ＵＭＬ画出其用例图，并写出详细的用例描述。
练习二
3.6 需求分析用例建模案例
3.6.1 客户需求分析
课件—UML系统建模与分析设计(1)
信息隐蔽和局部化——封装 3. 信息隐蔽和局部化 封装 4. 继承与派生
对象之间的联系纽带——消息 5. 对象之间的联系纽带 消息
6. 多态性 多态性(Polymorphism) 多态性(Polymorphism)是指同一个消息 为不同的对象接收时, 为不同的对象接收时,可产生不同的动作 或执行结果. 或执行结果.
将分析结果作为设计基础,无明显分界; 将分析结果作为设计基础,无明显分界; 都必须标识关键实体和动作; 都必须标识关键实体和动作; 信息具有层次性; 信息具有层次性; 提供一组将层次化的数据结构映射到程 序结构的步骤; 序结构的步骤; 数据结构由顺序,选择和重复 种构造成 数据结构由顺序,选择和重复3种构造成 分表示. 分表示.
4. 螺旋模型(spiral model) 螺旋模型( ) 螺旋模型的四类活动: 螺旋模型的四类活动:
制定计划. 制定计划. 风险分析. 风险分析. 实施开发. 实施开发. 客户评估. 客户评估.
5 . 智能模型(intelligent model) 智能模型( )
1.3.2 软件开发模型的选择 要综合考虑以下几个因素: 要综合考虑以下几个因素: (1)软件规模 ) (2)软件类型 ) – 系统软件的开发. 系统软件的开发. – 实时软件的开发. 实时软件的开发. – 商业应用软件的开发. 商业应用软件的开发. – 嵌入式软件的开发. 嵌入式软件的开发. – 人工智能软件的开发. 人工智能软件的开发.
其控制结构仅由顺序, 其控制结构仅由顺序,选择与重复等有 限的基本控制结构表示. 限的基本控制结构表示.
2. 模块化程序设计方法
模块之间的接口应尽可能简明清晰: 模块之间的接口应尽可能简明清晰: 单独模块的修改不影响其它模块的功能; 单独模块的修改不影响其它模块的功能; 模块化应具有可修改性, 模块化应具有可修改性,易读性和可验 证性. 证性.
UML系统建模与分析设计.ppt
统、角色和用例
等三种模型元素，
以及它们之间的
关系。
贸易经理
营销人员
设置边界
更新帐目
风险分析 交易估价
《使用》 《使用》
评价
进行交易
《扩展》
超越边界
记账系统 销售人员
2020/10/16
软件工程方法
4
用例模型描述的是外部执行者(Actor)所理解的系 统功能。它描述了待开发系统的功能需求。
它驱动了需求分析之后各阶段的开发工作,不仅在 开发过程中保证了系统所有功能的实现,而且被用 于验证和检测所开发的系统,从而影响到开发工作 的各个阶段和 UML 的各个模型。
2．定义系统的边界:一个系统的所有元素与系统以外的事物的 分界线。
2020/10/16
软件工程方法
8
1.4 确定执行者（参与者，角色） aActor
执行者（actor）是指在系统外部与系统交互的人或其他系统，它以某 种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图 符来表示。
执行者类型：参与者不仅可以由人承担，还可以是其它系统、硬件设备、 甚至是时钟 ： 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中， 银行后台系统就是一个参与者； 2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系 统时，IC卡读写器就是一个参与者； 3）时钟：当系统需要定时触发时，时钟就是参与者
•将需求规约变为可视化模型，并得到用户确认；
•给出清晰、一致的关于系统做什么的描述，确定系统的功能要 求；
•提供从功能需求到系统分析、设计、实现各阶段的度量标准；
•为最终系统测试提供基准，据此验证系统是否达到功能要求；
•为项目目标进度管理和风险管理提供依据。
课件—UML系统建模与分析设计(7)PPT课件
（1）一个结构良好的构件图应具备的特点
✓ 侧重描述系统静态视图的某一侧面； ✓ 只包含那些对描述该侧面内容有关的模型元素； ✓ 提供与抽象层次一致的描述，只显示有助于理解该构
件图的必要的修饰； ✓ 图形不要过于简化，以防产生误解。
（2）绘制一个构件图时应注意的问题
➢ 为构件图标识一个能准确表达其意义的名字； ➢ 摆好各个构件的位置，尽量避免连接线的交叉； ➢ 语义相近的模型元素尽量靠近； ➢ 用注解和颜色提示重点部位； ➢ 谨慎采用自定义构造型元素； ➢ 采用尽量少的图符标记描述构件图，保持所有构件
4．构件的组织形式
（1）用包来组织构件。 （2）用构件之间的交互关系来组织构件。
2021/3/6
UML系统建模与分析设计
9
7.2.2 构件的分类
（1）源代码构件 （2）二进制构件 （3）可执行构件
7.2.3 构件的接口
接口描述一个构件能提供服务的操作， 是一个有操作而无实现的类。
2021/3/6
UML系统建模与分析设计
（ 2
1 ）
➢都可以实现一组接口；
） 构
➢抽象的方式不同；
构
件
件 ➢都可以参与依赖、继承、 与 ➢抽象的级别不同；
与
类
类 关联等关系和交互； 的
的 显
➢访问方式不同；
相 同
➢都可以被嵌套；
著 不 ➢与包的关系。
点
同
➢都可以有实例。
点
2021/3/6
UML系统建模与分析设计
8
3．软件构件的特点
（1）接口。 （2）操作。 （3）实例化。 （4）与配置环境的亲合性。 （5）能与同环境下其它构件进行交互。 （6）构件可以是可执行代码、二进制代码和源代码形式。 （7）可替换的物理实体。 （8）系统的组成部分。 （9）构件是软件复用的基本单元。
✓ 侧重描述系统静态视图的某一侧面； ✓ 只包含那些对描述该侧面内容有关的模型元素； ✓ 提供与抽象层次一致的描述，只显示有助于理解该构
件图的必要的修饰； ✓ 图形不要过于简化，以防产生误解。
（2）绘制一个构件图时应注意的问题
➢ 为构件图标识一个能准确表达其意义的名字； ➢ 摆好各个构件的位置，尽量避免连接线的交叉； ➢ 语义相近的模型元素尽量靠近； ➢ 用注解和颜色提示重点部位； ➢ 谨慎采用自定义构造型元素； ➢ 采用尽量少的图符标记描述构件图，保持所有构件
4．构件的组织形式
（1）用包来组织构件。 （2）用构件之间的交互关系来组织构件。
2021/3/6
UML系统建模与分析设计
9
7.2.2 构件的分类
（1）源代码构件 （2）二进制构件 （3）可执行构件
7.2.3 构件的接口
接口描述一个构件能提供服务的操作， 是一个有操作而无实现的类。
2021/3/6
UML系统建模与分析设计
（ 2
1 ）
➢都可以实现一组接口；
） 构
➢抽象的方式不同；
构
件
件 ➢都可以参与依赖、继承、 与 ➢抽象的级别不同；
与
类
类 关联等关系和交互； 的
的 显
➢访问方式不同；
相 同
➢都可以被嵌套；
著 不 ➢与包的关系。
点
同
➢都可以有实例。
点
2021/3/6
UML系统建模与分析设计
8
3．软件构件的特点
（1）接口。 （2）操作。 （3）实例化。 （4）与配置环境的亲合性。 （5）能与同环境下其它构件进行交互。 （6）构件可以是可执行代码、二进制代码和源代码形式。 （7）可替换的物理实体。 （8）系统的组成部分。 （9）构件是软件复用的基本单元。
—UML系统建模与分析设计幻灯片
2021/5/15
UML系统建模与分析设计
19பைடு நூலகம்
２．软件开发 〔1〕概要设计 建立系统总体构造和各模块之间的关系； 定义各个功能摸块的接口； 设计全局数据库或数据构造； 规定设计约束； 制定组装测试方案。 〔2〕详细设计 对概要设计进展细化； 建立文档资料。
2021/5/15
UML系统建模与分析设计
； 必须是首次开发的新系统并且淘汰全部老系统时。
2. 渐增模型〔incremental model〕
2021/5/15
UML系统建模与分析设计
10
慎重考虑使用渐增模型的情况： 不能充分理解客户需求或客户需求有可能迅速发生
变化； 事先拟采用的技术迅速发生变化； 客户突然提出一些新的功能需求； 长时期内仅有有限的资源保证〔开发人员和资金〕
〔5〕按使用的频度划分 一次性使用软件。 使用频度较高的软件。
〔6〕按软件失效的影响程度划分 一般性软件。 关键性软件。
2021/5/15
UML系统建模与分析设计
6
1.2 软件的开展与软件工程
软件工程的指导性原那么： 变动的软件需求。 稳妥的设计方法。 高效的软件开发支持技术。 有效的过程管理。
软件工程具有里程碑意义的进展：
4
2．软件的分类
〔1〕按软件的功能划分
系统软件。
支撑软件。
应用软件。
〔2〕按软件的规模划分
微型软件。
小型软件。
中型软件。
大型甚至超大型软件。
〔3〕按软件工作方式划分
实时处理软件。
分时软件。
交互式软件。
批处理软件。
2021/5/15
UML系统建模与分析设计
5
〔4〕按软件效劳对象的范围划分 工程软件。 产品软件。
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）售后服务
（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建模案例.ppt
7
2.1 系统的用例图
创建用例图之前首先需要确定参与者。 系统的参与者主要有三类： ① 读者（也可称为借阅者） ② 图书馆管理员 ③ 图书馆管理系统维护者
8
2.1 系统的用例图
(1) 借阅者请求服务的用例图 (2) 图书馆管理员处理借书、还书等的用例图 (3) 系统管理员进行系统维护的用例图
9
(1) 借阅者请求服务的用例图
10
(2) 图书馆管理员处理借书、还书等的用例图
11
(3) 系统管理员进行系统维护的用例图
12
2.2 系统的类图
(1) 系统中主要的类 (2) 各个类之间的关系
13
(1) 系统中主要的类
① 参与者相关的类 ② 系统中用到的其他类
14
① 参与者相关的类
15
24
(7) 借阅者预订书籍的时序图
theItem: Item
25
2.4 系统的协作图
(1) 系统管理员添加书籍的协作图 (2) 系统管理员删除书籍的协作图
(3) 图书管理员处理借书的协作图 (4) 图书管理员处理还书的协作图
(5) 借阅者预留书籍的协作图
26
(1) 系统管理员添加书籍的协作图
删除和更新书目，增加、删除和更新借阅者帐户， 增加和删除书籍。 ⑤ 系统管理员还可以查询书籍信息和借阅者信息。
5
面向结构的分析、设计如何实现？ 画出顶层数据流图。 设想下与用例图的关系。
2 系统的UML基本模型
2.1 系统的用例图 2.2 系统的类图 2.3 系统的时序图 2.4 系统的协作图 2.5 系统的状态图 2.6 系统的活动图 2.7 系统的组件图 2.8 系统的部署图
软件工程概论 UML建模案例之
2.1 系统的用例图
创建用例图之前首先需要确定参与者。 系统的参与者主要有三类： ① 读者（也可称为借阅者） ② 图书馆管理员 ③ 图书馆管理系统维护者
8
2.1 系统的用例图
(1) 借阅者请求服务的用例图 (2) 图书馆管理员处理借书、还书等的用例图 (3) 系统管理员进行系统维护的用例图
9
(1) 借阅者请求服务的用例图
10
(2) 图书馆管理员处理借书、还书等的用例图
11
(3) 系统管理员进行系统维护的用例图
12
2.2 系统的类图
(1) 系统中主要的类 (2) 各个类之间的关系
13
(1) 系统中主要的类
① 参与者相关的类 ② 系统中用到的其他类
14
① 参与者相关的类
15
24
(7) 借阅者预订书籍的时序图
theItem: Item
25
2.4 系统的协作图
(1) 系统管理员添加书籍的协作图 (2) 系统管理员删除书籍的协作图
(3) 图书管理员处理借书的协作图 (4) 图书管理员处理还书的协作图
(5) 借阅者预留书籍的协作图
26
(1) 系统管理员添加书籍的协作图
删除和更新书目，增加、删除和更新借阅者帐户， 增加和删除书籍。 ⑤ 系统管理员还可以查询书籍信息和借阅者信息。
5
面向结构的分析、设计如何实现？ 画出顶层数据流图。 设想下与用例图的关系。
2 系统的UML基本模型
2.1 系统的用例图 2.2 系统的类图 2.3 系统的时序图 2.4 系统的协作图 2.5 系统的状态图 2.6 系统的活动图 2.7 系统的组件图 2.8 系统的部署图
软件工程概论 UML建模案例之
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需求建模(用例图+活动图)PPT幻灯片
中包含编号自动生成用例。
异常事件流处理：
（1）标识码有效性检查失败：系统检测标识码有效性失败，
允许重新输入。
（2）编号也可以由合同管理员手动输入，系统自动进行唯一
性检查。出现错误，允许重新输入。
2．“修改合同”用例
……………
2020/10/4
15
2020/10/4
16
2020/10/4
8
3.6.5 分层绘制用例图
1．最高层用例图
2020/10/4
9
2．第2层用例图
2020/10/4
10
3．第3层用例图
2020/10/4
11
4．第4层用例图
2020/10/4
12
2020/10/4
13
3.6.6 描述用例
1．“增加销售合同”用例
用例编号：04010101（共有4层用例图结构，每层用2位数字表 示， 采用8位编号。）
用例名： 增加销售合同 执行者: 人执行者：合同管理员、客户、公司经理。系统执
行者：“财务管理子系统”和“生产调度管理子系
统”。
目 的: 合同管理员将与客户签订的销售合同的详细内容录 入管理系统，用于对销售合同进行统计、查询、检查 是否履约等，监控正在履约的合同。
类 型：端点、主要的、基本的 级 别： 一级
2020/10/4
3
3．需求补充说明
（1）数据保存 •采购合同：每个合同执行期可能多达几个月，合同 需要长期保留。 •销售合同：每个合同执行期可能多达几个月，合同
需要长期保留。
•历年履约合同：履约后的合同需要长期（几十年） 保留，以备查使用。
•库存货物清单：库存货物量随出、入库有所消长， 长期保存。
需求分析——UML用例图PPT课件
-32-
第32页/共84页
要点：用例止于系统边界
描述交互，而不是内在的系统活动
-33-
第33页/共84页
要点：有意义的目标
设定查询条件
会员
选择零件
会员
检索零件
-34-
第34页/共84页
要点：结果值由系统生成
出纳员
吃饭
系统需要处理的，由系统生成
-35-
第35页/共84页
要点：业务语言而非技术语言
• “非程序员杂志”第26到30期UML工具一览，列出了约129个UML开发工具
-7-
第7页/共84页
内容安排
• UML概述 • 理解需求 • 需求，难在何处？ • 以用例为中心组织需求 • 基于用例的需求分析过程
-8-
第8页/共84页
认识问题
分析问题
解决问题
以开发者的身份站在开发团队的 角度分析问题
Booch93 OMT-2
统一 化
Booch91 OMT-1 其他方法 OOSE
分散
的
Grady Booch Jim Rumbaugh
第4页/共84页
Ivar Jacobson各 部
分
-4-
UML发展现状
• 目前通用的是UML 1.x版 • 主要UML 1.3、UML 1.4 • 2003年3月正式发布UML 1.5
-24-
第24页/共84页
相关术语
场景：是用来描述用户和系统之间交互的顺序的步骤 用例：是为了达到某一用户目标而组合在一起的一组场景
用例图：用来显示在系统（或其它实体）内的用例与系统参与者之间的关系
用例模型：是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契 约。用例模型用作分析、设计和测试活动的基本输入。
第32页/共84页
要点：用例止于系统边界
描述交互，而不是内在的系统活动
-33-
第33页/共84页
要点：有意义的目标
设定查询条件
会员
选择零件
会员
检索零件
-34-
第34页/共84页
要点：结果值由系统生成
出纳员
吃饭
系统需要处理的，由系统生成
-35-
第35页/共84页
要点：业务语言而非技术语言
• “非程序员杂志”第26到30期UML工具一览，列出了约129个UML开发工具
-7-
第7页/共84页
内容安排
• UML概述 • 理解需求 • 需求，难在何处？ • 以用例为中心组织需求 • 基于用例的需求分析过程
-8-
第8页/共84页
认识问题
分析问题
解决问题
以开发者的身份站在开发团队的 角度分析问题
Booch93 OMT-2
统一 化
Booch91 OMT-1 其他方法 OOSE
分散
的
Grady Booch Jim Rumbaugh
第4页/共84页
Ivar Jacobson各 部
分
-4-
UML发展现状
• 目前通用的是UML 1.x版 • 主要UML 1.3、UML 1.4 • 2003年3月正式发布UML 1.5
-24-
第24页/共84页
相关术语
场景：是用来描述用户和系统之间交互的顺序的步骤 用例：是为了达到某一用户目标而组合在一起的一组场景
用例图：用来显示在系统（或其它实体）内的用例与系统参与者之间的关系
用例模型：是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契 约。用例模型用作分析、设计和测试活动的基本输入。
课件—UML系统建模与分析设计1共43页文档
2019/12/8
UML系统建模与分析设计
12
使用演化模型时应注意：
演化模型也是通过系统各个可执行的中间版本 以渐增的形式来开发系统的，但是客户需求可 以分步逐渐了解，不用在初始时就确定。
在模型中，可以预先定义一部分客户需求，然 后在每个后继的中间版本中再逐步增加需求， 一点点完善。
在开发每个中间版本时，开发过程中的活动和 任务可以顺序地或部分重叠平行地被加入到这 些中间版本中。
2019/12/8
UML系统建模与分析设计
36
1.5.2 面向对象系统开发过程
2019/12/8
UML系统建模与分析设计
37
（1）需求分析阶段。 （2）系统分析阶段。 （3）系统设计阶段。 （4）系统实现、测试、使用、维护阶段。
2019/12/8
UML系统建模与分析设计
38
1.5.3 几种典型的面向对象方法简介
2019/12/8
UML系统建模与分析设计
13
4. 螺旋模型（spiral model） 螺旋模型的四类活动：
制定计划。 风险分析。 实施开发。 客户评估。
2019/12/8
UML系统建模与分析设计
14
5 . 智能模型（intelligent model）
2019/12/8
UML系统建模与分析设计
2019/12/8
UML系统建模与分析设计
17
1.3.3 软件生存周期
2019/12/8
UML系统建模与分析设计
18
１．软件定义
（1）软件系统的可行性研究 1）经济可行性研究。 2）技术可行性研究。 3）法律可行性研究。 4）方案的选择。
（2）需求分析 1）任务。 软件功能需求： 软件性能需求： 软件系统运行环境： 2）按需求建模。 3）软件需求规格说明（Software
UML在需求分析阶段的应用(共57张PPT)
•粒度：每个对象的大小。在该系统中一条数据的大小大约是
200B。 •容量：系统需要保存对象的数量。在系统中，每台计算 机最多管理6台天车，每台天车每天最多工作50次，则系统每 天最多需要保存300条记录，则每年需要保存的数据不超过 10万条。
非功能需求分析
•检索机制：为了便于检索，需要给每一条数据一个唯 一的编号。
数据传输错误或丢失数据的情况。
（2）打印各种统计报表。 （3）系统能够方便地启动和运行，维护
简单。
用户需求
4、系统开发人员 （1）系统有良好的可扩展性。 （2）提供模拟仪表，能够产生数据。方
便系统的开发、调试和安装。
需求分析与描述
序号 用户需求
软件需求 功能需求 可以实现
1
输入数据的过程尽量简洁，按 X
此处，领域指的是用户的业务领域，也 5、根据上面的分析，画出类图
3、对概念类进行泛化处理 名词可能会成为领域模型中的类或类中的属性，动词和动词词组可能会成为类中的方法或类间的关联。
就是需要解决问题的领域。 使用概念类图建立领域模型（分析对象模型）;
（3）仪表提供串行输出接口，可以把重量数据发送出去，数据的传输格式符合RS-232标准。 Auto Weight系统是一个自动称重系统中的软件部分。
•数据更新：数据需要长期保存，每次只增加数据， 不需要修改和删除。 •可靠性：要求数据能够可靠的存储。
领域模型分析
领域模型分析——找出领域概念
在进行用例分析的同时，还需要进行领 起重小车又由起升机构、小车运行
使用顺序图描述系统与外界的交互过程（动态模型）. 案例：Auto Weight系统
域分析，建立领域模型，绘制系统顺序 桥式起重机的桥架沿铺设在两侧高架上的轨道纵向运行，起重小车沿铺设在桥架上的轨道横向运行，构成一矩形的工作范围，就可以充分利用桥架
200B。 •容量：系统需要保存对象的数量。在系统中，每台计算 机最多管理6台天车，每台天车每天最多工作50次，则系统每 天最多需要保存300条记录，则每年需要保存的数据不超过 10万条。
非功能需求分析
•检索机制：为了便于检索，需要给每一条数据一个唯 一的编号。
数据传输错误或丢失数据的情况。
（2）打印各种统计报表。 （3）系统能够方便地启动和运行，维护
简单。
用户需求
4、系统开发人员 （1）系统有良好的可扩展性。 （2）提供模拟仪表，能够产生数据。方
便系统的开发、调试和安装。
需求分析与描述
序号 用户需求
软件需求 功能需求 可以实现
1
输入数据的过程尽量简洁，按 X
此处，领域指的是用户的业务领域，也 5、根据上面的分析，画出类图
3、对概念类进行泛化处理 名词可能会成为领域模型中的类或类中的属性，动词和动词词组可能会成为类中的方法或类间的关联。
就是需要解决问题的领域。 使用概念类图建立领域模型（分析对象模型）;
（3）仪表提供串行输出接口，可以把重量数据发送出去，数据的传输格式符合RS-232标准。 Auto Weight系统是一个自动称重系统中的软件部分。
•数据更新：数据需要长期保存，每次只增加数据， 不需要修改和删除。 •可靠性：要求数据能够可靠的存储。
领域模型分析
领域模型分析——找出领域概念
在进行用例分析的同时，还需要进行领 起重小车又由起升机构、小车运行
使用顺序图描述系统与外界的交互过程（动态模型）. 案例：Auto Weight系统
域分析，建立领域模型，绘制系统顺序 桥式起重机的桥架沿铺设在两侧高架上的轨道纵向运行，起重小车沿铺设在桥架上的轨道横向运行，构成一矩形的工作范围，就可以充分利用桥架
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第三章 需求分析与用例建模
本章目的：
• 了解可行性研究与风险分析的方法 • 掌握可行性分析报告的书写格式 • 掌握客户需求分析的要点及需求分析规格说
明报告的书写格式 • 掌握通过绘制用例图及其正文描述来完成客
户需求分析的方法
• 掌握UML的用例模型建模方法
2021/3/9
授课：XXX
1
3.1 可行性研究与风险分析
3．描述用例
•用例名： •简单名： •路径名：
2021/3/9
授课：XXX
13
用例的文字描述应包括以下内容:
•用例的目的（功能）；
•该用例在什么情况下被哪个执行者启动执行；
•用例与执行者之间交互哪些消息来通知对方作出决定；
•交互的主消息流及因此被使用或修改的实体；
•用例中可供选择的异常事件流；
•用例结束标志：给执行者返回一个可识别的值。
•反映系统动态特性： •综合系统的全部因素： •突出系统的重要因素： •结构简单：
3.1.3 法律可行性分析
3.1.4 开发方案可行性分析研究
1. 提出待选方案 2. 评价待选方案 3. 确定开发方案
2021/3/9
授课：XXX
4
3.1.5 可行性分析报告文档格式
2021/3/9
授课：XXX
5
3.2 客户需求分析与用例建模
2021/3/9
授课：XXX
21
3.3.1 确定对象类
（1）发现潜在对象
•与系统交互的角色。 •系统的工作环境场所。 •概念实体、发生的事件或事情。
•部门和设备。 •与系统有关的外部实体。
（2）标识对象名的原则
•使用单个名词或名词短语标识对象名；
•对象名称必须有意义、简洁明了、含义明确、易于理解；
23
3.3.2 标识对象类的属性
（1）发现和确定对象潜在的属性 （2）识别和筛选对象属性的原则 （3）识别和筛选属性应注意的问题 （4）属性的命名原则
3.3.3 标识对象类的操作
（1）寻找潜在的对象类操作 （2）筛选、确定操作 （3）命名操作名 （4）操作的说明 （5）操作的分类：
2021/3/9
1．定义系统的范围 2．定义系统的边界
2021/3/9
授课：XXX
9
3.2.4 确定执行者
执行者（actor）是指在系统外部与系统交互的人或 其 他系统，他以某种方式参与了系统内用例的执行。
1．定义执行者时应注意的几个问题
（1）执行者之间可以有继承关系
2021/3/9
授课：XXX
10
（2）执行者代表一种角色而不是具体某个人 （3）对同一个人担任角色的限制 （4）执行者可分成主执行者和副执行者 （5）执行者还可细分为主动执行者和被动执行者
授课：XXX
24
3.3.4 标识对象类之间的关联（协作）
（1）建立实例连接 （2）消息传递 （3）筛选对象间的关联
3.3.5 复审类的定义
复审方法犹如“击鼓传花”。
3.3.6 定义类的结构和层次
（1）一般-特殊结构 （2）整体-部分结构 （3）子系统
2021/3/9
2．寻找和确定执行者
2021/3/9
授课：XXX
11
3.2.5 确定用例
1.用例的特征 。
响应性。 回执性。 完整性。
2021/3/9
授课：XXX
12
2．寻找和确定用例
•系统为了维持正常运转需要增加的功能和信息的交互； •这些这些信息从何而来，到哪里去？ •实现当前系统（可能是人工系统而不是自动化系统）的关 键问题是什么？
3.1.1 经济可行性研究
1.系统成本费用分析
•设备购置费用。 •系统开发费用。 •系统安装、运行和维护费用。 •人员培训费用。
2.系统效益分析
•经济效益。 •社会效益。
2021/3/9
授课：XXX
2
2021/3/9
授课：XXX
3
3.1.2 技术可行性分析
1.风险分析 2.资源分析 3. 技术分析
•尽量使用用户熟悉的行业标准术语。
2021/3/9
授课：XXX
22
（3）筛选对象
根据以下特征来选择和确定最终的对象：
•关键性。 •可操作性。 •信息含量。 •公共属性 。 •公共操作。 •关键外部信息。 （4）对象分类： •有形性。 •包含性。 •顺序性。 •持久性。 •完整性。
2021/3/9
授课：XXX
3.2.1 建造需求模型——用例建模
用例建模的主要目标是：
•将需求规约变为可视化模型，并得到用户确认；
•给出清晰、一致的关于系统做什么的描述，确定系统的功能 要求；
•提供从功能需求到系统分析、设计、实现各阶段的 度量标准；
•为最终系统测试提供基准，据此验证系统是否达到 功能要求；
•为项目目标进度管理和风险管理提供依据。
2021/3/9
授课：XXX
6
用例建模的步骤：
•确定系统的范围和边界； •确定系统的执行者和用例； •对用例进行描述； •定义用例之间的关系； •审核用例模型。
2021/3/9
授课：XXX
7
3.2.2 用例图
2021/3/9
授课：XXX
8
3.2.3 定义系统的边界和范围
系统边界包括：
•整个组织：如一个企业； •一个组织的某个部门：如企业的财务处； •计算机系统的硬件/软件边界：如企业的进、销、 存计算机管理系统。
授课：XXX163．包含关联源自4．使用关联2021/3/9
授课：XXX
17
考虑用例的 关联类型
2021/3/9
授课：XXX
18
2021/3/9
授课：XXX
19
3.2.7 用例图实例
2021/3/9
授课：XXX
20
3.3 定义系统的对象和类
类 - 责 任 - 协 作 者 （ Class-ResponsibilityCollaborator， 简称CRC）技术：
举例：
用例名称：学生选课 执行者：学生
目的：完成一次学生选课的完整过程。
类型：主要的、基本的
级别：一级
2021/3/9
授课：XXX
14
过程描述： （1）学生输入标识码（ID），系统识别标识码的有效性；
（2）对学生进行注册识别； （3）流览本学期预开课程； （4）选择学生自己要上的课程并确认； （5）退出系统，系统给出所选课程列表及相应学分合计。
异常事件流处理：
（1）标识码有效性检查失败，允许学生重新输入（3次机会）。 （2）注册识别失败，没有注册（尙未交学费）的学生不能选课。 （3）选择课程确认失败，所选几门课程中在上课时间上发生冲
突时，系统提示重选。
2021/3/9
授课：XXX
15
3.2.6 用例之间的关联
1．继承关联
2．扩展关联
2021/3/9
本章目的：
• 了解可行性研究与风险分析的方法 • 掌握可行性分析报告的书写格式 • 掌握客户需求分析的要点及需求分析规格说
明报告的书写格式 • 掌握通过绘制用例图及其正文描述来完成客
户需求分析的方法
• 掌握UML的用例模型建模方法
2021/3/9
授课：XXX
1
3.1 可行性研究与风险分析
3．描述用例
•用例名： •简单名： •路径名：
2021/3/9
授课：XXX
13
用例的文字描述应包括以下内容:
•用例的目的（功能）；
•该用例在什么情况下被哪个执行者启动执行；
•用例与执行者之间交互哪些消息来通知对方作出决定；
•交互的主消息流及因此被使用或修改的实体；
•用例中可供选择的异常事件流；
•用例结束标志：给执行者返回一个可识别的值。
•反映系统动态特性： •综合系统的全部因素： •突出系统的重要因素： •结构简单：
3.1.3 法律可行性分析
3.1.4 开发方案可行性分析研究
1. 提出待选方案 2. 评价待选方案 3. 确定开发方案
2021/3/9
授课：XXX
4
3.1.5 可行性分析报告文档格式
2021/3/9
授课：XXX
5
3.2 客户需求分析与用例建模
2021/3/9
授课：XXX
21
3.3.1 确定对象类
（1）发现潜在对象
•与系统交互的角色。 •系统的工作环境场所。 •概念实体、发生的事件或事情。
•部门和设备。 •与系统有关的外部实体。
（2）标识对象名的原则
•使用单个名词或名词短语标识对象名；
•对象名称必须有意义、简洁明了、含义明确、易于理解；
23
3.3.2 标识对象类的属性
（1）发现和确定对象潜在的属性 （2）识别和筛选对象属性的原则 （3）识别和筛选属性应注意的问题 （4）属性的命名原则
3.3.3 标识对象类的操作
（1）寻找潜在的对象类操作 （2）筛选、确定操作 （3）命名操作名 （4）操作的说明 （5）操作的分类：
2021/3/9
1．定义系统的范围 2．定义系统的边界
2021/3/9
授课：XXX
9
3.2.4 确定执行者
执行者（actor）是指在系统外部与系统交互的人或 其 他系统，他以某种方式参与了系统内用例的执行。
1．定义执行者时应注意的几个问题
（1）执行者之间可以有继承关系
2021/3/9
授课：XXX
10
（2）执行者代表一种角色而不是具体某个人 （3）对同一个人担任角色的限制 （4）执行者可分成主执行者和副执行者 （5）执行者还可细分为主动执行者和被动执行者
授课：XXX
24
3.3.4 标识对象类之间的关联（协作）
（1）建立实例连接 （2）消息传递 （3）筛选对象间的关联
3.3.5 复审类的定义
复审方法犹如“击鼓传花”。
3.3.6 定义类的结构和层次
（1）一般-特殊结构 （2）整体-部分结构 （3）子系统
2021/3/9
2．寻找和确定执行者
2021/3/9
授课：XXX
11
3.2.5 确定用例
1.用例的特征 。
响应性。 回执性。 完整性。
2021/3/9
授课：XXX
12
2．寻找和确定用例
•系统为了维持正常运转需要增加的功能和信息的交互； •这些这些信息从何而来，到哪里去？ •实现当前系统（可能是人工系统而不是自动化系统）的关 键问题是什么？
3.1.1 经济可行性研究
1.系统成本费用分析
•设备购置费用。 •系统开发费用。 •系统安装、运行和维护费用。 •人员培训费用。
2.系统效益分析
•经济效益。 •社会效益。
2021/3/9
授课：XXX
2
2021/3/9
授课：XXX
3
3.1.2 技术可行性分析
1.风险分析 2.资源分析 3. 技术分析
•尽量使用用户熟悉的行业标准术语。
2021/3/9
授课：XXX
22
（3）筛选对象
根据以下特征来选择和确定最终的对象：
•关键性。 •可操作性。 •信息含量。 •公共属性 。 •公共操作。 •关键外部信息。 （4）对象分类： •有形性。 •包含性。 •顺序性。 •持久性。 •完整性。
2021/3/9
授课：XXX
3.2.1 建造需求模型——用例建模
用例建模的主要目标是：
•将需求规约变为可视化模型，并得到用户确认；
•给出清晰、一致的关于系统做什么的描述，确定系统的功能 要求；
•提供从功能需求到系统分析、设计、实现各阶段的 度量标准；
•为最终系统测试提供基准，据此验证系统是否达到 功能要求；
•为项目目标进度管理和风险管理提供依据。
2021/3/9
授课：XXX
6
用例建模的步骤：
•确定系统的范围和边界； •确定系统的执行者和用例； •对用例进行描述； •定义用例之间的关系； •审核用例模型。
2021/3/9
授课：XXX
7
3.2.2 用例图
2021/3/9
授课：XXX
8
3.2.3 定义系统的边界和范围
系统边界包括：
•整个组织：如一个企业； •一个组织的某个部门：如企业的财务处； •计算机系统的硬件/软件边界：如企业的进、销、 存计算机管理系统。
授课：XXX163．包含关联源自4．使用关联2021/3/9
授课：XXX
17
考虑用例的 关联类型
2021/3/9
授课：XXX
18
2021/3/9
授课：XXX
19
3.2.7 用例图实例
2021/3/9
授课：XXX
20
3.3 定义系统的对象和类
类 - 责 任 - 协 作 者 （ Class-ResponsibilityCollaborator， 简称CRC）技术：
举例：
用例名称：学生选课 执行者：学生
目的：完成一次学生选课的完整过程。
类型：主要的、基本的
级别：一级
2021/3/9
授课：XXX
14
过程描述： （1）学生输入标识码（ID），系统识别标识码的有效性；
（2）对学生进行注册识别； （3）流览本学期预开课程； （4）选择学生自己要上的课程并确认； （5）退出系统，系统给出所选课程列表及相应学分合计。
异常事件流处理：
（1）标识码有效性检查失败，允许学生重新输入（3次机会）。 （2）注册识别失败，没有注册（尙未交学费）的学生不能选课。 （3）选择课程确认失败，所选几门课程中在上课时间上发生冲
突时，系统提示重选。
2021/3/9
授课：XXX
15
3.2.6 用例之间的关联
1．继承关联
2．扩展关联
2021/3/9