（一）：业务用例和系统用例
抛开前一篇文章谈的总体思路，我们今天来谈一下需求分析工作实质性的做些什么。在这里，我们，将主要关注于分析层面，也即
UML中的用例模型和逻辑模型。
在这里要申明的是逻辑模型并不能完全算需求分析阶段的工作，因为它包含了设计模型的概念，但是我又把它归纳了一块到需求分析阶段，原因在于逻辑模型中存在了业务对象模型和分析模型的概念。
言归正传，先来看用例模型。
用例模型
用例模型包含了两部分：业务用例模型和系统用例模型。从字面的意义来看，确实很难分清两者究竟在做些什么工作。因此我们要重点解释一下。
业务用例模型的目的在于：
1． 描述企业的内部组织结构
2． 描述企业各部门的业务
3． 关注于角色和系统的交互界面
系统用例模型的目的在于：
1． 关注于演示对系统的需求
2． 抛弃部门的功能，更加细化
3． 系统用例模型应该划分子系统以对应不同的功能
这二者最大不同点在于：业务用例模型仅关注于企业部门的业务，而系统用例模型则关注于系统本身实现后的互动。
图素
业务用例模型和系统用例模型有共同的图素，但是在意义上是完全不同的
角色：
业务用例模型
系统用例模型
对于角色来说，业务用例模型有两种角色的变体，分别是业务角色和业务员工。系统用例模型则没有业务员工，只有业务角色。而它们的含义又是不同的。
在业务用例模型中，业务角色代表企业外的角色，业务员工代表企业内的角色。例如对于商店来说顾客就是它的业务角色，而售货员就是它的业务员工。
在系统用例模型中，业务角色代表系统外的角色。例如对于销售管理系统来说，任何一个操作员都是业务角色，因为它不属于系统内。
用例：
业务用例模型
系统用例模型
对于用例来说，业务用例模型因为需要描述部门的业务，因此它将使用一般用例的变体：业务用例。而系统用例模型则只需要使用用例的本体就可以了。二者的区别在于，业务用例的粒度很粗，它只描述部门的总体业务；用例的粒度很细，需要描述到系统中业务场景的工作。
业务用例模型工作流程
Step-1 ：创建业务用例对象模型的包
使用包的变体“ Business Use Case Model ”：
Step-2 ：创建用例对象的角色
创建业务员工和业务角色。
Step-3 ：创建组织结构图
制作业务用例模型时，需要通过扩展的关系来将各个业务员工和业务角色组织起来，形成组织结构图。（说明：需要通过抽象将业务员工的组织关系描述得清晰一些，而业务角色可能没有阶层的关系）
组织结构图的包应该使用包的变体“ organization Unit ”：
Step4 ：创建业务用例
使用业务用例和业务员工、业务角色来粗略的描述部门的业务工作。
系统用例模型工作流程
Step-1 ：创建系统用例对象模型的包
直接创建包就可以了：
Step-2 ：创建用例对象的角色
创建业务角色
Step-3 ：创建系统用例
使用业务角色和系统用例来详细描述系统的工作，业务角色对用例的关系应该设置为“ use ”，系统用例之间的关系将使用“
extend ”、“ include ”来描述。
系统用例的名字很重要，因为它将直接影响关系的描述。（在任何一个项目开展时都要对名字本身进行约束，动宾结构，还是主动结构）
比如：有一个系统用例，名为“维护商品信息”，显然如果有一个业务角色为“商品管理员”，那这个业务角色对“维护商品信息”的信息就应该是：
而“维护商品信息”这个用例的粒度太粗，因此还需要细化它，假使，“查询商品信息”和“更新商品信息”都和“维护商品信息”是有关系的，那么它们之间的关系就应该使用“
extend ”、“ include ”来描述。请先看下图：
“查询商品信息”和“维护商品信息”是扩展（ extend ）的关系，“更新商品信息”和“维护商品信息”是包含（
include ）的关系。
这样的图示说明了什么？请记住，扩展关系是指对于被扩展方（在这里指“维护商品信息”），扩展方（在这里指“查询商品信息”）是非必要实现的，也即没有“查询商品信息”，一样可以叫做“维护商品信息”。但是相对包含关系就不一样，“更新商品信息”对于“维护商品信息”来说是必须实现的一个用例，如果没有“更新商品信息”就没有“维护商品信息”了。此外，对于扩展关系，还有一个条件，就是扩展方应该在被扩展方用例实现的基础上进行的扩展。因此对于上图，若要表达的更清晰，则可以这样画：
这样的结果，告诉了看这个用例的人一个这样的信息：更新商品信息后可以查询其他商品信息。
请再看一个例子：
这个用例图告诉了我们这样的信息：
Step-1
商品管理员首先要提取商品信息
Step-2
在提取商品信息的同时，需要获取商品单价，这是必须完成的
Step-3
提取商品信息后可以更新商品信息和打印商品信息
Step-4
对于打印商品信息而言合计商品总量是必须完成的一个工作
从刚才的图中我们只看到了用例的关系和系统角色在各个阶段所做的一个大体工作，但是对于系统用例来说，每个用例都应该进行必要的描述（这点对于用例来说就是场景的描述）。
在下一篇中，我们将具体谈用例的描述和逻辑模型的工作。
（二）：用例描述和逻辑模型
前文介绍了系统用例，在这一节中，我们将讨论的是用例描述 和逻辑模型 的工作。
从任何一个环节我们都会看到用例，但是仅仅依靠用例本身的图来描述用例是不够的，为什么呢？因为用例它所要描述的是一个场景，换句话说，就是用例是描述了某件详细的事情。如果作为一个场景的话必然要考虑这么几个问题：
- 谁在这个场景中做事？
- 什么时候进入这个场景？
- 这个场景在做什么？
- 这个场景有没有特殊规则？
- 这个场景结束后会有什么情况？
- 这个场景和别的场景会有什么联系？
考虑这几个问题的话，那我们就可以开始描述我们的用例了，这步工作我们就称为用例描述。
好了，我们针对这几个问题一个个来给出它们的标准定名：
我们称之为参与者
我们称之为前置条件
我们称之为基本操作流程、可选操作流程
我们称之为业务规则
我们称之为后置条件
我们称之为相关用例
读过我之前一篇的朋友一定会记得用例分为业务用例 和系统用例
两种。针对这两种用例，相对来说都会根据这些标准定名来描述用例。
只是，有许多人习惯在业务用例 中不作描述，或者只是简单的描述一下，这点我认为无所谓，因为业务用例是描述企业的组织机构中各部门的业务，它的用例实在是很粗的，它本身的目标只在于可以及时得在谈需求时记录下企业的业务。不过我认为最好的做法是在业务用例的阶段，我们需要将业务用例划分出来，然后根据调研的结果将业务流程清晰的描述出来，表达的方式就不用太过拘泥，最简单的就可以是“我做
1-> 我做 2-> 我做 3… ”。
而在系统用例 部分则不得不清晰得来表明每个用例的场景，演示系统的需求，描述系统的功能。那么这里我们就用一个例子来说明一下这些描述吧。
根据之前曾经给出的一组用例来看：
我们来描述“提取商品信息”这个用例（请注意这是系统用例 ）。
参与者：
商品管理员
参与者的意思是，谁在对这个用例进行使用
前置条件：
1. 商品管理员登陆 XXX 系统后拥有能够操作该用例的权限
2. 商品信息的名称、生产日期可以被商品管理员获取作为条件
前置条件的意思是，在怎样的前提下，该用例才有可能被使用。
基本操作流程：
商品管理员输入商品名称和信息 -> 系统提取对应的商品并显示所有商品信息
可选操作流程：
商品管理员输入商品名称和信息 -> 系统无法根据条件得到对应商品信息，系统提示商品管理员重新输入条件
基本操作流程和可选操作流程的意思是，描述用例中基本的操作步骤和系统的反应结果，以及针对同一操作步骤可能会出现的另一种可能性。
业务规则：
1. 在提取商品信息的时候必须满足不能提取“安全锁”类型的商品
业务规则的意思是，在整个用例的场景中，无法在前置条件或后置条件以及基本操作流程和可选操作流程中描述的一些特殊业务规则。该业务规则是隐含的却是必须的。
后置条件：
1. 被提取的商品其状态全部变成“已查看”状态的商品
后置条件的意思是，在用例结束后会产生怎样的一个结果，而该结果可能会对今后的其他用例产生一定的影响。
相关用例：
扩展的用例：打印商品信息、更新商品信息
被包含的用例：获取商品单价
相关用例的意思是，能够在用例的描述中查看到当前用例与其他用例的关系，一般只有直接与当前用例相关的用例才会被作为相关用例，而且需要使用“扩展的用例”和“被包含的用例”来清晰的定义。
这样，我们的系统用例就完成了，虽然很烦琐，但是能够清晰的告之你的客户 , 你的系统将会做什么，不是一件令人很愉快的事吗？
完成了这一步后，我们接着的工作就需要进入逻辑模型 了。逻辑模型对于我们来说，是为了展示这个系统是怎样做的。因此它牵涉到的内容就比较多了。而一般而言，对于逻辑模型，我们通常分为做三步：
Step-1 ：业务对象模型
业务对象模型描述的是现行的业务活动对象之间的关系，是通过从业务用例视图中调研描述的结果以及角色和客户交付的文档中的对象演化而来，通过对象合作来实现。
Step-2 ：分析模型
分析模型属于推进用例的实现，它是在系统用例模型和业务对象模型基础上更进一步的对一个用例的实现说明。它更多的是告诉了我们，针对某个用例，系统会怎样实现。而在这里我们就会引出一个新名词“用例实现”，也会看到“类”。
Step-3 ：设计模型
设计模型和分析模型一样，其实也是告诉了我们针对某个用例系统会怎样实现，只是设计模型更抽象，它已经要求带入了实现技术的概念。
在下一篇中，我们将继续讨论究竟怎样做逻辑模型中的业务对象模型、分析模型。由于设计模型已经进入了标准的设计阶段，而业务对象模型和分析模型则相对属于过渡，因此对于设计模型我将可能在其他文章中进行补充。
| 
