这周学习的内容：这周和平常是一样的，我们在课堂上学习了三个小时，老师讲了用例图，类图，序列图，状态图。我们了解了用例图，用例图（use case diagram）就是由主角、用例以及它们之间的关系构成的图。该图说明了用例模型中的关系。类图(Class diagram)由许多（静态）说明性的模型 元素（例如类、包和它们之间的关系，这些元素和它们的内容互相连接）组成。类图可以组织在（并且属于）包中，仅显示特定包中的相关内容。类图(Class diagram)是最常用的 UML图，显示出类、接口以及它们之间的静态结构和关系；它用于描述系统的结构化设计。序列图(Sequence Diagram)有多种含义和用法。 序列图可以指遗传物质上核苷酸序列物理图的简称，是人类基因组计划中的最基础的工作，是人类基因组在分子水平上最高层次、最为详尽的物理图，测定总长为1M、由约30亿对核苷酸组成的基因组DNA序列。状态图（Statechart Diagram）是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应的。通常创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。状态机由状态组成，各状态由转移链接在一起。状态是对象执行某项活动或等待某个事件时的条件。转移是两个状态之间的关系，它由某个事件触发，然后执行特定的操作或评估并导致特定的结束状态。我们用老师发下来的软件画了用例图，起初，我们都管 参与者叫小人，后来老师纠正了我们的错误，觉得特搞笑，也很开心。
这周的阅读内容：
用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示一个外部用户能够观察到的系统功能模型图。用例图多用于静态建模阶段（主要是业务建模和需求建模），帮助开发团队以一种可视化的方式理解系统的功能需求。下面将从各个部分来分析和理解用例图。
参与者（Actor）
在系统外部与系统直接交互的人或事物；需要注意以下两点：
- 参与者是角色而不是具体的人，它代表了参与者在与系统打交道的过程中所扮演的角色。所以在系统的实际运作中，一个实际用户可能对应系统的多个参与者。不同的用户也可以只对应于一个参与者，从而代表同一参与者的不同实例。
- 参与者作为外部用户（而不是内部）与系统发生交互作用，是它的主要特征。
在UML中，参与者使用如图所示的一个小人表示：
用例（Use Case）
系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。用椭圆表示，椭圆中的文字简述系统的功能：
子系统（Subsystem）
用来展示系统的一部分功能，这部分功能联系紧密。
关系（Relationship）
用例图中涉及的关系有：
- 关联
- 泛化
- 包含
- 扩展
关联（Association）
表示参与者与用例之间的交互，通信途径，任何一方都可发送或接受消息。
箭头指向：指向消息接收方。
泛化（Inheritance）
在编程中，泛化关系是一种很重要的关系，我们随处可见。
泛化关系是一般和特殊关系，就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
箭头指向（需要特别注意）：指向父用例。
包含（Include）
包含关系用来把一个较复杂用例所表示功能分解成较小的步骤。包含用例是必须的，如果缺少包含用例，基用例就不完整；包含用例必须被执行。
箭头指向：指向分解出来的功能用例。
扩展（Extend）
扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性。
箭头指向（需要特别注意）：指向基用例
下图提供一个完整的系统的用例图，让大家有一个感官上的全面认识。
总结
用例图虽然作为UML中的一部分，给团队成员提供一种形象的系统表述，但是，用例图也由它本身的缺陷，用例图一般在需求分析阶段就给出了，有的时候对于系统的需求，并不能很好的表述，对于没有UML背景的人来说，更是一种痛苦与折磨，但是，话又说回来，作为软件开发人员，没有UML背景是说不过去的；有的时候，我们需要借助用例图对客户讲解系统，而让客户去理解用例图则是很困难的。
虽然，在用例图中的关系种类不是很多，也不是很复杂，但是UML的表示确实很让人费解的，别的还好，特别是扩展（Extend）和包含（Include），表示方式都一样的，仅靠上面的说明来进行区分，在一个复杂的系统中，是很容易看错的，从而理解出错，同时，扩展（Extend）中的箭头指向一直是让我很费解的，为什么需要让箭头指向基用例呢？
鉴于用例图有的时候并不能清楚地表达功能需求，开发中大家通常用用例描述表来补充某些不易表达的用例，请大家参考下图：
