基于抽奖系统的需求分析和概念原型

用例建模

用例建模的基本步骤

第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例；
第二步，描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。

用例建模分析

项目名称：设计一个抽奖系统
基本需求描述：1.管理员创建抽奖项目；2.用户通过微信扫码进行抽奖。

我们可以很容易找出三个动名词：“创建抽奖项目”，“微信扫码”和“抽奖”，以“创建抽奖项目”为例进行接下来的分析。

首先是描述用例开始和结束的状态，即高层用例，用TUCBW和TUCEW表示如下：
TUCBW 管理员在浏览器输入抽奖系统后台管理的url并回车
TUCEW 管理员看到生成的抽奖项目二维码

接着是画出用例图(见之后的完整用例图)，最后用表格列出详细的交互过程，即扩展用例：

管理员用例图

用户用例图

业务领域建模

业务领域建模的基本步骤

第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
第四步，将结果用 UML 类图画出来。

业务领域建模分析

对于该抽奖系统，最核心的就是抽奖项目，抽奖项目又包含了奖品，抽奖项目和奖品有各自的属性。从管理员的角度，要实现对抽奖项目以及奖品的增删改查；从用户的角度，要实现可以通过微信扫码进行抽奖，并记录相关的信息，如剩余抽奖次数和中奖信息。基于以上分析，我们可以确定管理员，用户，抽奖项目和奖品4个类，并画出UML类图。

业务类图

数据建模

数据建模分析

本项目使用MongoDB来存储数据, 使用Mongoose ODM来访问数据库数据，这里主要分析对于一对多关系建模的三种基础方案的选择，其它模型设计与业务领域建模有相似之处，不多做赘述。

一对多关系建模的三种基础方案：

• One-to-Few

• One-to-Many

• One-to-Squillions

一个抽奖项目有多种奖品，对应于One-to-Few，但我们需要将奖品作为单独的实体进行管理，所以不采取内嵌的方案，而是在抽奖项目中引用奖品的ObjectID；
对于抽奖项目和用户来说，它们是多对多的关系，一个抽奖项目可以有多个用户，一个用户也可以参与多个抽奖项目，具体是Few，Many还是Squillions要依实际情况而定，我们暂时选择在用户字段中引用抽奖项目的ObjectID。

Mongoose模型设计

MongoDB文档

概念原型

• 概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。
• 概念原型是一种虚拟的、理想化的软件产品形式。
  

基于以上式子，我们可以这样理解：抽奖系统所要实现的，就是在管理员操作下，由奖品再加上一些属性就可以生成一个抽奖项目，项目有它的功能，并具有二维码这个接口，使得用户可以通过该接口来参与这个抽奖项目。

参考文献

• 从需求分析到软件设计