UML 之用例与用例图那些不得不说的事

2.1 用例

2.2 参与者

2.3 脚本

2.4 关系

2.5 用例图

2.6 用例描述

2.7 用例分析步骤

2.8 常见问题

2.1 用例

        使用文字描述活动者使用系统功能的交互过程

        椭圆+动宾结构（主谓结构） 动态建模部分

2.2 参与者

        使用系统的那个（人或者别的什么玩意）：系统以外，使用系统，与系统交互的

        参与者之间可以存在关系

2.3 脚本

        贯穿一个用例的一条单一路径，可以类比为一条时间线

2.4 关系

关系很复杂

用例与参与者之间有关联关系（参与者与用例的关系）.

用例之间的关系有:泛化、包含、扩展.

泛化：带空心箭头的实线，表示一般与特殊，更像同一种物体的不同个体，类和对象？，但……是……泛化关系的箭头不是指向被泛化，而是指向被继承。泛化和继承是不同的方向。is a

举个好栗子：

包含：整体与部分，其中一个用例（基础用例）的行为包含了另一个用例（包含用例）的行为。has a

多说无益，来个例子：把大象放进冰箱------------------->打开冰箱

扩展：在原来的用例基础上增加了新的步骤序列，将常规的动作放在基本用例中，将可选的或只在特定条件下才执行的动作放在它的扩展用例中，箭头指向被扩展的用例。is a

例子：就是多做了一点可做可不做的事，就这样

2.5 用例图

显示参与者+关系+用例的图

2.6 用例描述

是对用例功能的描述，就是介绍用例是干啥的

用例描述一般包括的内容：

用例的目标

用例是怎么启动的

用例结束后系统的状态

参与者与用例之间的消息如何传送

用例中除了主路径外, 其它路径是什么

其它需要描述的内容

描述用例时的原则是尽可能写得“充分”（就是越多越好喽？）

用例的描述格式：

描述用例时易出现的错误：

只描述系统的行为, 没有描述参与者的行为（不够）

只描述参与者的行为, 没有描述系统的行为（不够）

在用例描述中就设定了对用户界面的设计的要求（手太长）

描述过于冗长（不是说越详细越好吗？）

2.7 用例分析步骤

找出系统外部的参与者和外部系统, 确定系统边界和范围（找外部）

确定每一个参与者所期望的系统行为（猜内部）

把这些系统行为命名为用例（想内部）

使用泛化、包含、扩展等关系处理系统行为的公共或变更部分（加关系）

编制每一个用例的脚本（理顺序）

绘制用例图（画出来）

区分主要事件流和异常事件流, 如果需要, 可以把异常事件流处理为单独的用例（分主异）

细化用例图, 解决用例间重复与冲突的问题.（做细化）

2.8 常见问题

都是没有答案的问题，放弃吧