用例建模Use Case Modeling

　　此次工程实践课题为软件打包与分发渠道调研与实践。下面将在项目需求的基础上进行用例建模。抽取Abstract use case，画出用例图，并确定每一个用例的范围High level use case，对关键用例进一步进行Expanded use case分析。首先明确以下几个概念。

　　用例建模：

　　用例是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与者（可能是最终用户也可能是外围系统）与系统之间的交互关系描述系统对外提供的功能特性----这种参与者与系统功能特性间的交互关系就是用例。用例分析和用例建模就是通过对软件需求的调研，从具体的功能性需求中抽象出用例模型的工作过程。用例建模主要有两个产物。第一个是用例图，第二个产物就是用例描述。

　　用例图：

　　用例图描述的是参与者所理解的系统功能，主要元素是用例和参与者。虽然用例图不能取代文本形式的用例文档，但它简要地概括了用例文档的主要内容，项目的基本需求和需求之间的关系一目了然。在项目初始阶段，用例图可以帮助开发团队以一种可视化的方式理解系统的功能需求，从而快速地进行需求分析。

　　用例图组成元素：

1、Actor

　　参与者指与系统交互的人或物。参与者不仅包括产品的用户，还包括维护人员、外设（人、打印机）、相连的系统等等。  在用例图中，参与者用一个小人来表示。

 

2、Use Case

　　用例描述了系统应有的功能或服务，在用例图中用椭圆表示。每个椭圆都代表一个用例，即一个功能。

3、关系

关联(Association)：
　　表示参与者与用例之间的通信，只要参与者使用了某个用例，那么这个参与者和这个用例之间就存在关联关系。关联关系通过一条连接参与者和用例的直线来表示。

泛化(Inheritance)：

　　泛化关系即为继承关系，这种关系存在于父用例与子用例之间（或父参与者与子参与者之间）。网上许多教程对泛化关系的描述都非常抽象，但其实泛化关系非常好理解。例如，一个订票系统有两种订票方式：电话订票和网上订票。那么“订票”就是父用例，“电话订票”和“网上订票”就是子用例，“订票”和“电话订票”、“网上订票”之间存在泛化关系。从这个例子我们也能看出，父用例一般是一类功能的抽象描述，而子用例是父用例的具体实现形式，这和我们以前在程序设计课中学过的类继承关系是一样的。泛化关系通过空心的箭头来表示，箭头从子用例指向父用例。

包含(Include)：

　　包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。我们以维护数据库为例，“维护数据库”这个功能由三部分组成：“添加数据”、“删除数据”、“修改数据”。那么“维护数据库”就包含了“添加数据”、“删除数据”、“修改数据”这三个用例。包含关系很容易和泛化关系搞混，但其实真正理解之后并不难区分：泛化关系中的父用例和子用例粒度相同，而包含关系是把大粒度用例分成了小粒度用例。包含关系用带有include字样的虚线箭头表示。

4、制作合理的用例图，通常给可以带来以下好处：

　　明确系统的业务范围、服务对象（角色）、外部系统与设备

　　帮助识别技术风险，提前实施关键技术原型公关与学习

　　易于评估项目工作量，合理规划迭代周期，规划人力需要

下面是本次工程实践的用例图