需求分析和概念原型-校园二手论坛

1. 项目综述

在近期的高级软件工程课程上学习了软件工程建模方法，因此对本学年的工程实践题目-校园二手论坛小程序进行建模与分析。主要是需求分析、业务领域建模以及数据建模，最终形成一个完整的概念原型。分析工程如下。

2. 用例建模

2.1 用例

用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。

下面是用例的几个基本要素：

• A use case is initiated by (or begins with) an actor. 一个用例应该由业务领域内的某个参与者（Actor）所触发。
• A use case must accomplish a business task (for the actor).用例必须能为特定的参与者完成一个特定的业务任务。
• A use case must end with an actor. 一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。

从待开发软件外部到待开发软件内部，然后又到待开发软件外部，这从最高层级抽象地为我们提供一个信息流特征的视角，用来从整体上把握待开发软件的内外关系。

2.2 用例建模的基本步骤

1. 从需求表述中找出用例，往往是动名词短语表示的抽象用例；

2. 描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；

3. 对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；

4. 进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。

其中第一步到第三步是计划阶段，第四步是增量实现阶段。

2.3 提取用例的方法

1. 从需求中寻找业务领域相关的动名词和动名词短语，比如做什么事、什么事情必须被完成，或者执行某任务等；

2. 验证这些业务领域相关的动名词和动名词短语到底是不是用例。验证业务领域相关的动名词或动名词短语是不是用例的标准是满足四个必要条件：

• 必要条件一：它是不是一个业务过程？
• 必要条件二：它是不是由某个参与者触发开始？
• 必要条件三：它是不是显式地或隐式地终止于某个参与者？
• 必要条件四：它是不是为某个参与者完成了有用的业务工作？
  如果以上四个必要条件都满足的话，那么该业务领域相关的动名词或动名词短语就是一个用例。

3. 在需求中识别出参与者、系统或子系统。

• 参与者会触发某个用例开始，用例也会显式地或隐式地终止于某个参与者；
• 用例会属于系统或子系统。

2.4 对当前项目建模

本项目重心放在用户的交易上，用户有发布商品，浏览商品主题帖和评论收藏等功能需求，我们找出其中的动名词，并结合用例的四个必要条件看是否满足来提取用例，并画出用例图如下：

3. 业务类图

3.1 业务领域建模简介

业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。

开发团队获取业务领域知识的过程一般包括收集业务领域相关信息、执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类图将业务领域知识图形化展示。

3.2 基本步骤

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

第一步更多地在获取需求的阶段已经完成，这里不做赘述；第四步 UML 类图的画法前面已经给出，接下来我们重点将头脑风暴的做法和业务领域概念分类的方法具体探讨一下。

3.3 对当前项目建模

在收集业务领域信息后，画出当前项目的UML类图：

4. 数据模型

4.1 MongoDB介绍

• MongoDB是一个通用的、基于文档的、分布式的数据库，为云计算时代的现代应用程序开发者而生，没有数据库比MongoDB在应用开发效率上更加高效。
• MongoDB是一种文档数据库，也就是说MongoDB用类似JSON格式的文档来存储数据。目前普遍认为JSON格式是理解和存储数据最自然的方式，JSON格式比传统的关系数据模型有更强大的数据表达能力。

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

• Modeling One-to-Few
  针对个人需要保存多个地址进行建模的场景下使用内嵌文档是很合适，可以在person文档中嵌入addresses数组文档
• One-to-Many
  以产品零件订货系统为例。每个商品有数百个可替换的零件，但是不会超过数千个。这个用例很适合使用间接引用---将零件的objectid作为数组存放在商品文档中(在这个例子中的ObjectID我使用更加易读的2字节，正常是由12个字节组成的)。
• One-to-Squillions
  我们用一个收集各种机器日志的例子来讨论一对非常多的问题。由于每个mongodb的文档有16M的大小限制，所以即使你是存储ObjectID也是不够的。我们可以使用很经典的处理方法“父级引用”---用一个文档存储主机，在每个日志文档中保存这个主机的ObjectID。

4.3 对当前项目建模

根据当前项目的的数据模型以及关联关系，设计关系型表如下：

• User
  
• Goods
  
• Transaction
  
• Comment
  

5. 概念原型

概念原型 = 用例 + 数据模型，我们从之前的项目用例和数据模型中可得出项目的概念原型工作过程：

用户登录小程序后，可以从首页推荐浏览商品，或者从分类中查看感兴趣的商品贴。同时也可以搜索自己要寻找的商品或感兴趣的话题。点击进入商品详情后，查看该商品的回复列表，可以按时间排序或仅发布者模式查看所有评论，同时可以对回答进行点赞，评论等。发布者可以删除某个楼层的评论，也可自己回复。同时提供私聊功能。用户可以在个人中心对个人信息管理，包括修改昵称，地址等，也可对钱包进行充值，查看发布记录和购买记录等。

6. 总结

这次的博客根据课上内容，从需求分析出发，对工程实践的小程序项目进行建模，对其概念原型进行细致分析。在撰写博客过程中，不仅复习了课程中的内容，更对当前项目结构有了进一步的认识，对以后的开发工作也有很大的帮助。