需求分析阶段的工作（一）：业务用例和系统用例-技术开发it知识库-Ubuntu系统_Ubuntu服务器

　　在这里要申明的是逻辑模型并不能完全算需求分析阶段的工作，因为它包含了设计模型的概念，但是我又把它归纳了一块到需求分析阶段，原因在于逻辑模型中存在了业务对象模型和分析模型的概念。

言归正传，先来看用例模型。

用例模型

　　用例模型包含了两部分：业务用例模型和系统用例模型。从字面的意义来看，确实很难分清两者究竟在做些什么工作。因此我们要重点解释一下。

业务用例模型的目的在于：

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 ）的关系。

　　这样的图示说明了什么？请记住，扩展关系是指对于被扩展方（在这里指“维护商品信息”），扩展方（在这里指“查询商品信息”）是非必要实现的，也即没有“查询商品信息”，一样可以叫做“维护商品信息”。但是相对包含关系就不一样，“更新商品信息”对于“维护商品信息”来说是必须实现的一个用例，如果没有“更新商品信息”就没有“维护商品信息”了。此外，对于扩展关系，还有一个条件，就是扩展方应该在被扩展方用例实现的基础上进行的扩展。因此对于上图，若要表达的更清晰，则可以这样画：