在理解项目需求的基础上进行用例建模，抽取Abstract use case，画出用例图，并确定每一个用例的范围High level use case，对关键用例进一步进行Expanded use case分析。
1.用例建模简介
用例建模是UML建模的一部分，它也是UML里最基础的部分。用例建模的最主要功能就是用来表达系统的功能性需求或行为。用例图重点描述用户需求。 它描述需求、用户和主要组件之间的关系。 它不会详细描述用户需求；在可链接到每个用例的其他关系图或文档中可详细描述这些需求。用例图是UML的九个图中较为重要和常用的一种图。常常用于软件开发的需求分析阶段，也能用于软件的系统测试阶段。简单的来说，用例图是描述系统的外部视图，为了搞清某个项目的大概需求，我们往往要问两个问题，
这个系统有什么用？有哪些人参与?
这些人通过这个系统能做些什么事？
通过这两个问题，一般就能比较清楚地表达系统的需求了，用例图就是用来回答这两个问题的，它能从比较清晰的角度来表达系统的需求，而且不涉及到技术用语。
用例建模可分为用例图和用例描述。
用例图由参与者（Actor）、用例（Use Case）、系统边界、箭头组成，用画图的方法来完成。
用例描述用来详细描述用例图中每个用例，用文本文档来完成。
(1)参与者(Actor)
在一个系统开发前，我们必定首先要确定系统的用户，系统的用户就是系统的参与者。除此以外，我们还会想想我们开发的系统与其他的系统有什么关联？因此，系统的参与者可分为两类，一类是人，包括系统的使用者、维护者等，另外一类是其他系统。
(2)用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。我们可以这样去理解，用例是参与者想要系统做的事情。对于对用例的命名，我们可以给用例取一个简单、描述性的名称，一般为带有动作性的词。用例在画图中用椭圆来表示，椭圆下面附上用例的名称。
(3)系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中方框来表示，同时附上系统的名称，参与者画在边界的外面，用例画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。
(4)箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。
2.结合工程实践创建用例图
2.1抽取Abstract use case
我的工程实践为基于大数据训练的中文语义理解系统设计，实现中文文本摘要的生成。
对于开发者，主要的High level use case为数据获取，摘要机的实现，以及文本摘要的生成界面应用三个方面。
(1)数据获取：包括获取公开数据集，并对数据进行预处理，将中文数据转为计算机能处理的向量。
(2)摘要机：实现输入一段话，输出其摘要。采用seq2seq模型，包括文本向量的编码器，解码器，采用循环神经网络实现。还有其他一些模块帮助生成更流畅简洁的摘要，包括注意力机制和copy net。将采用大量的数据训练这个模型，并不断优化改进。
(3)生成摘要：将摘要机封装成用户使用的界面，提供摘要生成服务。
用户则主要使用摘要生成界面。
2.2用例图
