当前课程知识点：软件工程 > 第8章 用例建模 > 8.1 用例建模概念 > 讲课视频
各位同学大家好
在这一小节中
我将对用例建模的概念
和意义进行介绍
在产品开发过程中
需求的管理尤为重要
高校管理需求的工具多种多样
用例建模便是其中之一
随着项目的开展
我们可以通过
一系列的需求活动管理
去挖掘系统的相关信息
通过分析问题理解干系人的需求
在定义系统的过程中
我们可以利用简略地用例规约
对系统的功能
和业务过程进行表示
融入领域相关信息后
对系统进行细化完善
形成更加详细的用例规约描述
在这个过程中
我们逐步形成了完整的用例模型
进而可以管理变化的需求
那么用例模型
到底包含了系统的哪些信息
用例模型可以很好地
描述系统的功能性需求
在UML中一个用例模型
通常由若干个用例图组成
用来表示系统实现的业务过程
描述系统的工作方式
首先我们可以通过用例模型
将干系人的需求
和软件的需求建立关联
确认与系统交互的人或者对象
即我们所谓的参与者
定义系统的边界
捕捉和表达系统的理想行为
也就是用例
这个模型就像我们
去餐馆看到的菜单
通过菜单我们知道
这个餐厅可以提供哪些菜品
所属菜系 相应价格
等相关的信息
这就如同我们通过用例模型
来理解以及表示
系统为我们提供的服务
所以通过用例模型
有利于对需求进行验证和确认
并辅助规划开发的过程
用例模型可以包含
文本描述和用例图描述
用例图有利于宏观的了解系统
文本描述则给出了
参与者和用例的具体信息
所以用例建模的过程中
更重要的是对用例进行描述
而画图只是其中的一小部分工作
文本描述中包含了
用例模型概要以及用例规约描述
模型概要中简要介绍了
系统的功能与意义
列出相关的参与者和用例
在每一个具体的用例规约中
将详细描述用例中会发生
什么操作或事件
涉及的非功能性需求
和规则约束等
也就是要对每一个
用例的事件流进行描述
用例模型的另一种表示是用例图
下面通过银行ATM机的例子
让大家对用例图
建立一个直观的认识
用例图用来显示一组用例参与者
以及它们之间的关系
再给大家看一个
具体的用例图之前
先请大家思考几个问题
ATM会涉及哪些业务
会和什么对象进行交互
这些不同的对象
又是如何和系统进行交互的
这里给大家10秒钟的时间去思考
这个是其中一种设计模式
供大家思考 图中包含了
四种不同的身份的用户
五个用例以及
它们之间的关联关系
不知道和大家的预期是否一致
除了上述的三个问题之外
我们可以从中发现更丰富的信息
比如发现用例的优先级
这个信息有利于
在开发过程中进行进度规划
就这个例子而言
最重要的莫过于取款功能
如果缺失了这个功能
则整个ATM系统
就没有存在的价值了
其它的类似于存款转账等
更多的是给系统锦上添花的功能
这是一种划分
用例优先级的判断规则
同时我们也可以
根据用例服务的对象来判断
为主要客户和参与者
提供的业务服务
一定是优先级很高的用例
其它的功能另类似于
提供额外的管理
或者技术操作的用例
并非系统的主要业务
也并不直接服务于主要参与者
所以相对优先级较低
例如图中的收取存款
和日常维护等用例
例如打印日志
开启服务备份系统
等一类管理性的用例
是系统所必需的
但非首要的用例
可以在其它的用例图中进行组织
基于ATM机系统的用例模型认识
接下来我们继续学习
用例图中的元素和相关表示方法
首先与系统交互的人或外部系统
我们称之为参与者
用来表示系统与参与者提供的
有价值的服务功能的是用例
我们通过椭圆形来表示
通过关联来描述用例图中
用例与参与者之间的交互关系
在图中通常与直线
或者带箭头的直线来表示
接下来我们来详细介绍一下
这三个建模元素
首先是用例
用例定义了系统的一系列行为
通过此可以为参与者提供有价值
且可观测的结果
这里有几个地方
需要大家额外注意
首先是用例的命名
表示系统的功能服务
因此这应该是一个动宾结构
例如应该命名为注册课程
而不是课程注册
再看定义中
用例用来表示系统的行为
代表功能性需求
要牢记系统是这个服务的提供商
同时这个功能实际上
涵盖了一系列的原子操作
代表着参与者和系统之间的
交互过程
这些操作是原子性的
每一个都应该是完全执行
或者完全不执行的
用例往往用来和用户确认需求
辅助开发团队规划开发进度
因此定义的用例的服务对象
一定是系统最终的使用用户
也就是参与者
而不要为了开发人员
或者需求分析师定义用例
而且这些用例
一定要有可观测的结果
这样才可以用来确认
系统是否达到了用户的预期目标
如何定义一个有价值的用例
是比较具有挑战的
应该注意用例定义的力度要适中
过细的力度定义体现为用例
不能为参与者提供足够的价值
这个时候需要和其它的用例合并
形成一个相对完整的流程
来达到参与者的目的
另外一种情况是过粗力度的定义
比如说选课系统中
一个叫做操作选课系统的用例
就太过宽泛了
我们可以根据不同角色用户的
使用目的或者使用方式
将这个用例拆分细化
概括而言 用例描述了
系统的功能性需求
每个用例给出的
是一个细化的系统行为需求
用例表示系统为参与者
提供的服务和价值
参与者与系统的每种不同的
交互方式都是一个用例
琼取所有的用例
可得到完整的需求描述
用例的特点在于通过自然语言
描述参与者与系统的交互活动
描述系统的职责
描述系统必须做什么
而非如何做
这就像系统将销售记录
写入数据库
这样的用例是并不合时宜的
因此又利模型的一个重要作用
就是作为黑箱测试设计的参考
同时
用例提供需求的上下文情境
将系统的需求
用逻辑序列进行表述
解释说明为什么需要这个系统
其一理解的性质便于确保
与干系人的理解是一致的
规范化的表达形式
让其拥有较强的复用性
可以应用于文档撰写和系统设计
测试等各个环节
在定义用例的时候
我们往往需要依赖参与者的信息
那设计参与者的时候
应该注意哪些问题
首先来看参与者通常表示什么
这里需要在系统的实际使用用户
和参与者之间做一个转换
不同的使用者
用同样的模式与系统进行交互
同时一个使用者也以不同的身份
使用相同的系统
例如学生可能是选课同学
也可能是助教
银行柜台人员
可能是银行的客户等等
所以我们应该注重
用户所承担的角色
在命名的时候
要体现出角色的特性
例如在选课系统中
有这样两个使用者
成为两个用户实例
李雷和韩梅梅
李雷和寒梅梅都具有学生的角色
所以他们都具有注册课程的权利
而李雷作为教授身份的时候
还具有提交成绩的权利
因此参与者的定义
是依据角色而划分的
我们需要将用户角色
和用户实例进行区分
第三个需要建模的元素是关联
表示参与者与用例
之间的交互通道
我们通常用一条直线
来表示这种交互关系
系统中往往有很多参与者
与同一个用例相关联
我们通常将获取用例
提供价值的参与者
定义为主参与者
主参与者是服务的主要受益方
但并不一定是
主动发起交互的一方
在用例模型中
我们通常使用箭头
来表示交互的发起方和接收方
箭头代表的信息约束性较强
因此建议仅当有明确需求说明时
按照箭头的使用规范进行表示
通过火警报警器的例子
说明一下箭头的使用规范
在这两个图中
均有系统交互人员主动发起交互
监控火警报警器
这两个图的区别在于
上图中明确表明了
被动传感器与警报器的交互模式
被动传感器需要接收系统的消息
等待系统询问当前状态
进而与监控系统进行交互
而主动传感器正相反
需要主动传递信息
给系统进行交互
例如定时给系统
上传自己当前的状态
混合传感器不指明交互箭头
表示可以作为消息的发起方
或者接收方
例如定时每60秒上传状态信息
当超过75秒后
系统若仍未收到其信息
将会向混合传感器发起询问消息
在下图中没有箭头则表示
对于主被动传感器的交互方式
无明确的约束
根据箭头的意义
我们可以明确箭头的使用约束
第一 如果图中
标明了箭头相应的信息
也应该在用例文本
描述中有所体现
标志在何种情况下进入用例
二 箭头表示并不是必须的
仅当需求中有明确的
定义时才进行使用
三 一种异常的表示
是如果有两个或两个以上的箭头
指向了同一个用例
在大部分情形下
是一个指向用例的箭头
其余的箭头应该是
由力指出或无方向
四 箭头的方向
只表示消息的传递方向
而不表示那个参与者创建用例
或者是用例服务的受益方
一个交互代表着参与者
与系统之间的一个完整对话
以注册课程为例
学生登录到系统
系统验证学生登录成功后
学生可向系统发起请求
获取课程信息
随后系统向课程目录系统
发起信息查询的请求
课程目录系统
返回相关的课程的信息
系统再将相应的信息展现给学生
学生进而可以选择课程
系统进一步处理请求
将相关的课程纳入课程票
以上的过程形成了
一个完整的事件流
在用例的文本描述中进行撰写
大家会发现
上述的过程仅仅是我们平常
与选课颗系统交互的情境之一
很多时候系统会根据
我们不同的信息进入不同的场景
因此我们可以将场景
理解为用例的一个实例
一个用例会有不同的场景
也就意味着会有不同的事件流
我们在文本描述时需要
将这些不同的场景分别进行描述
例如课件中所给出的
这两个场景样例
场景可以表达正面的行为需求
也可以表达反面的
不希望发生的交互
还可以包括并行机制
在每个选择点
进行一种情况的具体描述
而例二是情境的重要辩体
表明了会对企业
产生严重影响的事件流
在后面的详细介绍中
我们会给出具体的例子
-1.1 软件无处不在
--讲课视频
-1.2 软件的本质特性
--讲授视频
-1.3 软件工程的产生与发展
--讲授视频
-1.4 软件工程的基本概念
--讲授视频
-1.5 软件质量实现
--讲授视频
-1.6 业界人士谈软件工程
-测验题--作业
-讨论题
--讨论题
-作业题
--第一张 作业题
-2.1 编程过程与规范
--讲课视频
-2.2 良好的编程实践
--讲课视频
-2.3 Python集成开发环境
--讲课视频
-2.4 代码静态检查
--讲课视频
-2.5 代码性能分析
--讲课视频
-2.6 结对编程实践
--讲课视频
-2.7 刘贺谈软件工程
--讲课视频
--讨论
-测验题--作业
-作业题
--第二章 作业题
-3.1 单元测试概述
--讲课视频
-3.2 黑盒测试方法
--黑盒测试方法
-3.3 白盒测试方法
--基本概念
--代码覆盖标准
--基本路径测试
-3.4 单元测试工具
--单元测试工具
--html
-测验题--作业
-作业题
--第三章 作业题
--作业题附件
-4.1 软件过程
--讲课视频
-4.2 软件过程模型
--讲课视频
-4.3 敏捷开发过程
--讲课视频
-4.4 微软公司开发过程
--邹欣经理自我介绍
--微软开发过程之一
--微软开发过程之二
-测验题--作业
-5.1 团队组织与管理
--讲课视频
-5.2 项目沟通管理
--讲课视频
-5.3 软件项目计划
--讲课视频
-5.4 软件项目估算
--讲课视频
-测验题--作业
-讨论题
--讨论
-6.1 敏捷开发之Scrum
-- 敏捷开发之Scrum
--html
-6.2 用户故事与估算
--讲课视频
-6.3 团队协作工具Tower
-6.4 配置管理
--讲课视频
-6.5 配置管理工具Git
--讲课视频
-测验题--作业
-作业题--作业
-7.1 需求工程师
--讲课视频
-7.2 需求定义
--讲课视频
-7.3 需求的类型
--讲课视频
--讲课视频（2）
-7.4 需求工程过程
--讲课视频
-7.5 需求的主要来源
--讲课视频
-7.6 需求获取技术
--讲课视频
--讲课视频二
--讲课视频三
-7.7 撰写需求文档
--讲课视频
-测验题--作业
-讨论题
--讨论
-8.1 用例建模概念
--讲课视频
-8.2 用例建模过程
--讲课视频
-8.3 用例建模精讲
--讲课视频
-8.4 建模工具介绍
--讲课视频
-8.5 微信抢票应用案例
--讲课视频
-测验题--作业
-讨论题
--讨论
-9.1 面向对象分析
--讲课视频
-9.2 CRC卡片分拣法
--讲课视频-1
--讲课视频-2
-9.3 面向对象设计
--讲课视频-1
--讲课视频-2
-9.4 类图建模
--讲课视频-1
--讲课视频-2
-第9章 面向对象分析与设计--测验题
-讨论题
--讨论
-10.1 顺序图概念
--讲课视频
-10.2 顺序图建模
--讲课视频
-10.3 顺序图风格
--讲义视频
-10.4 状态建模
--讲课视频
-10.5 状态图
--讲课视频
-10.6 状态图精讲
--讲义视频
-测验题--作业
-讨论题
--讨论
-11.1 软件体系结构概念
--讲授视频
-11.2 软件设计原则
--讲授视频
-11.3 软件体系结构风格（一）
--讲授视频
-11.4 软件体系结构风格（二）
--讲授视频
-11.5 软件体系结构风格（三）
--讲授视频
-11.6 软件设计过程
--讲授视频
-11.7 Web系统架构设计
--讲授视频
-11.8 数据库选择策略
--讲授视频
-测验题--作业
-作业题
--html
--html
--html
-作业题--作业
-12.1 交互设计概述
--讲授视频
-12.2 交互设计目标
--讲授视频
-12.3 GUI设计原则
--讲课视频
-12.4 KLM效率模型
--Video
-12.5 Fitts定律
--讲授视频
-12.6 交互设计过程
--讲授视频
-测验题--作业
-13.1 软件测试概念
--讲课视频
-13.2 软件测试类型
--讲课视频
-13.3 软件功能测试
--讲课视频
-13.4 软件性能测试
--讲课视频
-测验题--作业
-14.1 软件部署与交付
--讲课视频
-14.2 软件演化与维护
--讲课视频
-测验题--作业
-第一部分：基础知识
-第二部分：编程与测试（选做）
