UML学习

利用use case描述用户的价值，一个完整用例的定义： 参与者 前置条件 场景 后置条件

用例：

描述一件事物通常从3个方面去进行: 

1.  结构 （事物的本质） 

2.  功能 （事物可利用的价值） 

3.  使用者观点 （事物对使用者的意义）

软件恰恰就是一种还不存在的东西，我们不能从结构、功能的观点去描述它，最好的方法就是从使用者的观点去描述它。

产品认同感：

假如习惯使用功能分解来看待系统，提供大量的功能点，指望“用户”像UNIX高手一样自己从指令集中找到合适的指令来完成工作，不熟悉相关的使用者一定感到痛苦而无认同感。

一个简单的例子：

从功能的角度去描述一个电视：

1. 能开关  2. 能显示，可以调频道  3. 可以调声音

从用例的角度去描述一个电视：一个人要观看电视节目：先打开开关，调到自己喜欢的频道，如果声音不适合可以调节一下。

对比以上两种，可品味出不同的味道来。

边界的使用：（软件设计面临很大的信息量，既要实现需求，又要保证性能，要具有扩展能力，还有友好易用）

设定一些边界可有效地降低系统复杂度

1. 将实现需求的任务交给分析模型，在这个边界内只考虑需求实现

2. 将扩展能力交给框架设计，在这个边界内专心设计灵活的框架

3. 在框架的约束下把分析模型转化为设计模型

可视化模型划分：人、事、物和规则

1. 业务模型： 参与者(actor)，用例(use case)

2. 概念模型 （分析模型）、（转化为计算机能理解的模型）： 边界类（事），实体类（物），控制类（规则）

3. 设计模型（概念模型实例化）： 边界类（转化为操作界面或系统接口），控制类（转化为计算程序或控制程序：工作流，算法体），实体类转化为（数据块表，XML，文档或其他带有持久化特征的类）

用例与用户Story的区别

要了解二者异同，首先来看各自的概念： 

Use Case(用例) ：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。 

User Story(用户故事)：描述对软件（或系统）用户或客户有价值的功能,只是需求描述，而不是详细的需求规范。

从概念上，用例包括了业务用例和系统用例。user story更多的是一种业务用例，而软需描述的更多的是系统用例。

从定义上其实可以看出来，Use Case是UML中一个重要的概念，他采用actor和系统交互的方式来描述用户需求，

使用了一套逻辑上相对完整的事件流来定义，他包括了名称、描述、主要事件流、扩展流、异常流、前置条件和后置条件等等元素，可见他描述需求是相当详细的，在RUP过程中使用得比较多。

User Story描述用户需求则是离客户更近一步，

他所使用的描述语言类似于“作为XXXX，我希望xxxxxx”这种方式，

例如，作为用户，我希望能够查看订单列表，简单的描述用户需要的东西。

而没有定义如何交互等事件流方式，这种需求描述形式是比较抽象的，使用User Story在敏捷项目中使用比较多，当然Use Case 也适合敏捷项目。

因此可以看出，这里并不存在两种方法孰好孰坏的差别，而是说在不同的场景中使用合适的需求描述方式，

Use Story更适合比较早期的 探索需求阶段，因为他 表述起来非常的简单，一个 User Story 只需要几句话就可以完成， 

另外一个因素就是 用户需求的细节是非常易变的，而其高层描述却是相对稳定的 ， 

所以我们可以通过使用 User Story 的方法来从高层确定其需求(包括功能性的和非功能性的)，

这些单独的Use Story相当于系统中可能要实现的一点，而由我们通过与用户交流所得到的所有 User Story 则构成了一个面，

它就是整个系统所需要实现的功能，举个例子， “作为用户，我希望能够查看订单列表”，非常简洁，但是阐述清楚了谁需要什么的需求；

而Use Case更适合于 需求分析阶段，因为该阶段需要比较详细的、更系统的需求分析，

而Use Case能够满足这一切，不过，由于这里需求进行了具体化处理，因此用户可能在变换交互方式的时候，

那么对于User Story来讲不会变的东西，而对于Use Case来讲可能就会有所有变更。