标签：mode 抽取 目的 箭头 存在 角度 col 打包 方式
此次工程实践课题为软件打包与分发渠道调研与实践。下面将在项目需求的基础上进行用例建模。抽取Abstract use case，画出用例图，并确定每一个用例的范围High level use case，对关键用例进一步进行Expanded use case分析。首先明确以下几个概念。
用例建模：
用例是从外部用户和外围系统的角度，分析和考察待开发系统的行为，并通过参与者（可能是最终用户也可能是外围系统）与系统之间的交互关系描述系统对外提供的功能特性----这种参与者与系统功能特性间的交互关系就是用例。用例分析和用例建模就是通过对软件需求的调研，从具体的功能性需求中抽象出用例模型的工作过程。用例建模主要有两个产物。第一个是用例图，第二个产物就是用例描述。
用例图：
用例图描述的是参与者所理解的系统功能，主要元素是用例和参与者。虽然用例图不能取代文本形式的用例文档，但它简要地概括了用例文档的主要内容，项目的基本需求和需求之间的关系一目了然。在项目初始阶段，用例图可以帮助开发团队以一种可视化的方式理解系统的功能需求，从而快速地进行需求分析。
用例图组成元素：
1、Actor
参与者指与系统交互的人或物。参与者不仅包括产品的用户，还包括维护人员、外设（人、打印机）、相连的系统等等。 在用例图中，参与者用一个小人来表示。
2、Use Case
用例描述了系统应有的功能或服务，在用例图中用椭圆表示。每个椭圆都代表一个用例，即一个功能。
3、关系
关联(Association)：
表示参与者与用例之间的通信，只要参与者使用了某个用例，那么这个参与者和这个用例之间就存在关联关系。关联关系通过一条连接参与者和用例的直线来表示。
泛化(Inheritance)：
泛化关系即为继承关系，这种关系存在于父用例与子用例之间（或父参与者与子参与者之间）。网上许多教程对泛化关系的描述都非常抽象，但其实泛化关系非常好理解。例如，一个订票系统有两种订票方式：电话订票和网上订票。那么“订票”就是父用例，“电话订票”和“网上订票”就是子用例，“订票”和“电话订票”、“网上订票”之间存在泛化关系。从这个例子我们也能看出，父用例一般是一类功能的抽象描述，而子用例是父用例的具体实现形式，这和我们以前在程序设计课中学过的类继承关系是一样的。泛化关系通过空心的箭头来表示，箭头从子用例指向父用例。
包含(Include)：
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。我们以维护数据库为例，“维护数据库”这个功能由三部分组成：“添加数据”、“删除数据”、“修改数据”。那么“维护数据库”就包含了“添加数据”、“删除数据”、“修改数据”这三个用例。包含关系很容易和泛化关系搞混，但其实真正理解之后并不难区分：泛化关系中的父用例和子用例粒度相同，而包含关系是把大粒度用例分成了小粒度用例。包含关系用带有include字样的虚线箭头表示。
4、制作合理的用例图，通常给可以带来以下好处：
明确系统的业务范围、服务对象（角色）、外部系统与设备
帮助识别技术风险，提前实施关键技术原型公关与学习
易于评估项目工作量，合理规划迭代周期，规划人力需要
下面是本次工程实践的用例图
标签：mode 抽取 目的 箭头 存在 角度 col 打包 方式
原文地址：https://www.cnblogs.com/xsymin/p/11785426.html
