这周主要画了用例图和写用例描述。一开始对用例图的绘制只是表面上的理解，真正动手画的时候，出现了不少问题，一方面对用例的概念比较模糊，另一方面是如何确定用例间的关系存在一定的难度，很多用例间的关系比较模糊，或者没遇到过，所以遇到了不少问题。下面主要罗列了如何确定参与者、确定用例的一些方法，以及用例描述说明。
用例图描述
用例图不显示用例的详细信息：它只概括用例、参与者和系统之间的某些关系。特别是，用例图不显示每个用例为实现目标所执行步骤的顺序。
用例图有四个部分：
- 用例（Use Case)：表明系统能做什么事情
- 参与者（Actor)：是对系统使用者的抽象
- 系统边界：清晰表达出系统的范围
- 关系 ：角色的继承、关联、泛化、包含(Include)、扩展(Extend)、比较少用到的用例继承
关系介绍
关联(Association)：是指角色与用例之间的关系，有三种：无箭头，指向用例的箭头，指向执行者的箭头。一般来说，箭头的尾部用来表示启动交互的一方，头部用来表示被启动的一方。不过箭头的解释容易把人弄晕，建议全部画成没有箭头就行了。
包含(Include)：包含关系用来把一个较复杂的用例所表示的功能分解成较小的步骤。包含用例是必须的，如果缺少包含用例，基用例就是不完整的。
扩展(Extend)：在某用例的基础上，还能做什么事情，带有”《extend》”标志的虚线的箭头方向，箭头方向表明了谁扩展谁。
泛化关系是两个用例或两个参与者之间的关系。泛化关系其实可以通俗理解为面向对象关系中的继承。将拥有一种类似的结构和行为的多个用例中的共性抽象为父用例，子用例继承父用例中的所有。
识别参与者
发现参与者，可以根据以下问题来寻找系统的参与者：
谁或什么在使用系统；
交互中，他们扮演什么角色；
谁安装系统；
谁启动和关闭系统；
谁维护系统；
与该系统交互的是什么系统；
谁从系统获取信息，谁提供信息给系统；
参与者相关的注意问题：
参与者对于系统而言是外部的，它们在系统控制之外。
参与者直接同系统交互，可以帮助定义系统边界。
参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或事物。
一个人和事物与系统发生交互时，可以扮演多个角色。例：某个研究生担任某教授的助教，从职业的角度看，他扮演了两个角色----学生和助教。
每个参与者需要有一个具有业务语义的名字。
每个参与者必须有简短的描述，从业务角度描述参与者是什么。
参与者可以具有分栏，表示参与者属性和它可接受的事件。
参与者可以使用用泛化关系来描述多个参与者之间的公共行为。
识别用例的方法：从分析系统的参与者开始，考虑每个参与者是怎样使用系统的。
以下几个问题可以帮助识别用例：
<1>特定参与者希望系统提供什么功能；
<2>系统是否存储和检索信息，若是，这个行为由哪个参与者触发；
<3>当系统改变状态时，通知参与者吗；
<4>存在影响系统的外部事件吗；
<5>是哪个参与者通知系统这些事。
用例描述
参见以下博客：
一个完整的用例描述
需要注意的是：
- 前置条件描述了执行用例之前系统必须满足的条件。这些条件必须在执行用例之前得到满足，如果条件不满足，则用例不会执行。
- 后置条件将在用例成功完成以后得到满足，它提供了系统的部分描述。后置条件可以在用例结束后监察系统,如系统状态或持久数据用例完成后所剩下的。用例的后置条件应该是不存在的，即执行可选择的流动;它不应该只适用于主流。如果某件事可能失败，你会在事后说:“行动完成了，或者如果某件事失败了，行动就没有完成”，而不是“行动完成了”。