1. 前置知识

题目：进行用例建模、业务领域建模、数据建模、最终形成概念原型。

对应要求：画出项目的完整用例图、画出项目的业务类图、给出项目的数据模型、总结出概念原型并举例说明概念原型的工作过程。

1.1 名词扫盲

书面化的东西就不说了，说说我自己的理解。

建模：用某种形式化的一套东西来描述实际问题，这样能方便分析问题（以及让不明就里的人更不明就里）。

用例：简单理解为动名词短语，如 [2] 中所述，用例图包括 Actor 和 Use case：

角色（actor）
An actor is behaviored classifier which specifies a role played by an external entity that interacts with the subject (e.g., by exchanging signals and data), a human user of the designed system, some other system or hardware using services of the subject.
角色代表的是直接或间接使用这个系统的用户或系统、设备。在面向用户的产品中，角色可能是人，比如学生，在面向技术的产品中（比如 broker，mq），则角色可能是客户端，业务系统。

用例（use case）
Use cases allow to capture requirements of systems under design or consideration, describe functionality provided by those systems, and determine the requirements the systems pose on their environment.
用例就是角色能够执行的动作，描述了角色能够怎么使用我们提供的系统。他表达的是一个系统的功能。

概念原型 = 用例 + 数据模型。类比为 程序 = 算法 + 数据结构 就好理解多了。

1.2 项目说明

好了，所以为什么我说我的题目很不适合，一是因为上述这一套是针对 功能性需求 设计的，而我的题目全是关于 非功能性需求 的；二是对于这种模拟类型的题目，并不涉及庞大的系统以及其中的交互，而是关注在系统中某些特定的点。

我的题目简略来说就是：基于 UE4 引擎，表现一个高度真实的带有复杂光源环境的场景，并能在移动端流畅运行。大概包括：

第一部分：移动渲染管线下的延迟渲染的实现
第二部分：海水、风、天空、天气效果的实现

就拿延迟渲染说，它本身就属于 Efficient Shading，本身就是为了提高效率，这显然是非功能性需求……不过如果把概念原型理解成算法与数据结构，倒也还可以分析分析。这里就以第一部分为例进行下去。

2. 用例图

这里的系统是用图形API（渲染应用程序接口）编写的程序了。把 Actor 设定为应用程序和驱动程序的原因是从程序层面提取用例。如果把 Actor 设定为使用最终场景的人，那就无法与最终的 demo 场景产生任何可影响到算法的交互，用例就只剩下 看效果 了。

3. 业务类图

4. 数据模型

渲染数据一般包括着色器的代码、几何数据、纹理数据、渲染状态等，它们会被封装成不同的文件类型，具有不同的操作特性。数据在图形API中以数据流的形式在各种阶段被传递。

5. 概念原型

所以项目的概念原型其实非常直观，就是我们用图形API编写的程序，接受由应用程序传递的渲染数据，向驱动提交渲染命令。所谓延迟渲染与传统渲染的区别，从这个概念原型的层次来看，就是——得到一次渲染结果，要经过多遍渲染过程。

参考

[1] https://gitee.com/mengning997/se/blob/master/ppt/从需求分析到软件设计.pptx
[2] https://zhuanlan.zhihu.com/p/78243709