本文探讨了上下文图如何描绘系统边界，用例图的元素及关系，包括参与者、用例及其关联、泛化、包含和扩展。还介绍了标准用例规约内容，以及如何创建有意义的功能树和理解用例本质。适合理解用户需求和系统设计者使用。
目 录
1. 上下文图的作用是什么？能帮助你理解什么？
①作用：帮助确定我们产品中交互的角色和系统。上下文图定义了所开发的系统和系统外部实体（如使用人员、硬件设备和其它信息系统）之间的边界和接口。划定系统的边界，并显示系统和其他系统或者人员、设备等等的交互情况。
②有了上下文图，我们可以更好的确定我们开发的产品中使用者、将会使用到的系统、以及需要设计的系统。能够帮助我们更好的了解系统和系统，系统和使用者之间的交互情况。
2. 用例图各符号代表的意思和使用的场景？
①用例图主要用途
用例图的主要目的是帮助软件开发设计者以一种可视化的方式理解系统的功能需求。
用例视图可以清晰的显示出谁是相关的用户、用户希望系统能够提供什么样的服务，以及用户需要为系统提供的服务等等，也能够让软件开发人员更好地实现这些元素。
②用例图的基本元素
参与者(Actor)：表示的是一个系统用户，也就是与应用程序进行交互的用户、组织或者外部系统。
用例(Use Case)：表示的是对系统提供的功能、服务的一种描述。
③用例之间的关系
| 用例之间的关系 |
| （1）关联关系 定义：参与者与用例之间通常用关联关系来描述。 表示方法：带箭头的实线，箭头指向用例。
|
| （2）泛化关系 定义：一个用例可以被特别列举为一个或多个子用例，这被称为用例泛化。泛化关系在类间也有。子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变已继承的行为。 表示方法：带空心箭头的实线，箭头指向被泛化（被继承）的用例，即父用例。 易错点：泛化关系的箭头不是指向被泛化，而是指向被继承。泛化和继承是不同的方向。泛化是从下到上的抽象过程，继承是从上到下，从一般到特殊的过程。
|
| （3）包含关系 定义：其中一个用例（基础用例）的行为包含了另一个用例（包含用例）的行为。基础用例可以看到包含用例，并依赖于包含用例的执行结果。但是二者不能访问对方的属性。 表示方法：虚线箭头+<<include>>字样，箭头指向被包含的用例。 使用情况： （1）如果两个以上用例有重复的功能，则可以将重复的功能分解到另一个用例中。其他用例可以和这个用例建立包含关系。 （2）一个用例的功能太多时，可以用包含关系创建多个子用例。
|
| （4）扩展关系 定义：是把新行为插入到已有用例的方法。 表示方法：虚线箭头<<extend>>字样，箭头指向被扩展的用例（即基础用例）。 作用：为处理异常或构建灵活系统框架提供了一种有效的方法。 对比：包含与扩展的区别。在扩展关系中，基础用例没有扩展也是完整的，而在包含关系中，基础用例依赖于包含用例的执行结果。
|
3. 标准的用例规约包括哪些内容？
①用例规约：在用例图中，针对每一个用例描述它的详细信息。
②每一个用例的用例规约都应该包含以下内容：
简要说明：简要介绍该用例的作用和目的。
角色：本用例所参与的所有角色。
基本流：表示用例正常的场景。在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。
异常流：描述与该用例相关的非功能性需求(包括性能、可靠性、可用性和可扩展性等)和设计约束(所使用的操作系统、开发工具等)。
前置条件：执行用例之前系统必须所处的状态。
后置条件：用例执行完毕后系统可能处于的一组状态。
备选流：描述用例发生过程中偶尔或者异常发生的场景。
4. 什么样的功能树是一个有意义的功能树？
功能树必备条件：
（1）面向使用，体现使用价值
（2）覆盖全面，没有范围遗漏
一个好的功能树应当表现系统功能的划分。一个好的功能树一个将功能相近或相似的功能模块归为一类并切忌用角色划分功能树。
5. 用例是什么？
用例图的目的是对系统进行业务建模，具体来说就是用户对系统进行的一项功能性需求描述，可以直观的表达用户使用系统的业务目的。
用例是对用户目标或用户需要执行的业务工作的一般性描述，是一组相关的使用场景。描述了系统与外部角色之间交互。使用场景则是某个用例的一条特定路径，是用例的特定的实例对象。类似于类和对象的关系，类是用例，每一个使用场景都是用例的一个对象。
6. 一个用例需要具备的特征：
①能完整的表达用户的需求或者目的。
②必须包含参与者即系统的真实用户或系统。
③动宾短语形式的描述。
7. 用例适用需求：
①用例适用于描述用户的功能性需求，它描述的是一个系统做什么，而不是说明怎么做。
②用例适用于增量开发，一方面通过优先级指导增量开发，另一方面用例开发的本身也是强调采用迭代的、宽度优先的方法进行开发。
1276
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
