基于留学管理与分析系统的需求分析与建模

前言

笔者最近在高级软件工程课堂上学习了需求分析、需求建模的基本概念和方法。本文拟针对所参与的工程实践项目进行需求分析、用例建模、业务领域建模、数据建模并最终形成概念原型，以期总结并熟悉这种敏捷统一过程的基本建模方法。

项目背景介绍

如今出国留学的人数越来越多,而且呈现低龄化。如何选择合适的学校与专业是许多家长与学生在出国前需要面临的问题。
本项目通过抓取国外名校网站与留学中介网的信息，实现留学信息管理与分析系统。
本系统首先要实现的是留学信息的检索。其次通过分析用户的需求、自身的条件、留学地的社会环境和安全问题、留学学校信息、留学专业信息等可以给用户一个合理的选择区间。留学信息管理与分析系统无疑可以以此为基础打造一个这样的平台，针对不同用户，通过多种因素的综合分析，给出科学的建议，给用户合适的择校建议，让用户更好的选择心仪的海外高校，形成一个比较科学的总结信息以及分析信息的过程。

需求分析基本概念

• What
  需求分析是在获取需求的基础上进一步对软件涉及的对象或实体的状态、特征和行为进行准确描述或建模的工作。包括：

  • 功能需求

  • 非功能需求（质量属性）

  • 其他限制

    包括资源的限制、技术的限制、委托方对于平台和接口的要求等

• Why

  导致项目失败的原因很多，前期最主要的原因有：不完整的需求；缺乏用户的参与；需求不明确且不断变换需求……这些原因大多与需求分析相关。

• How

  • 获取需求的渠道

    采访项目负责人；采访潜在用户或其他参与者；参考类似系统或查阅文档……

  • 需求分析的原则

    • Making Requirements Testable

      即定量分析需求，使得对需求的评判具体化、数值化

    • Resolving Conflicts

      各方利益相关人的需求有冲突，需要对需求优先级进行划分：essential/desirable/optional

    • Characteristics of Requirements

      Correct/Consistent/Unambigious/Complete/Relevant/Testable/Traceable

  • 需求分析方法

    • 原型化方法

    • 建模的方法

      本文拟采用的方法，分别从例建模、业务领域建模和业务数据建模来具体了解对需求进行建模的方法

用例建模

基本概念

用例（use case）即指经过逻辑整理所抽象出来的业务过程（business process）。在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。基本要素包括：

• 参与者（Actor）

• 业务任务

• 两者关系

  业务任务终止于参与者，即参与者明确或隐含地获得了任务完成之结果

用例的三个抽象层级包括：

• 抽象用例（Abstract use case）

  通过一个精简的动+名格式表示，如“管理个人信息”

• 高层用例（High level use case）

  为用例划分开始和结束的边界，如上述用例开始状态为用户通过修改信息按钮进入个人信息页面，结束状态为用户点击修改或取消按钮退出个人信息页面。

• 扩展用例（Expanded use case）

  将参与者和待开发系统为了完成用例所规定的业务任务的交互过程一步一步详细地描述出来，用两列的表格来表示，该用例出现在增量实现阶段，本上述用例示例：

  Actor: 网站用户	Sys: 留学网站
  1. TUCBW: 用户点击“修改个人信息”按钮	2. 跳转到个人信息修改页面
  3. 用户点击某一项个人信息	4. 该项信息进入待修改状态
  5. 用户通过键鼠修改信息	6. 该项内容显示新信息
  7. TUCEW: 用户完成所有修改，点击“确认”按钮

用例建模的主要步骤包括：抽象用例->高层用例->用例图（->扩展用例），用例图的基本画法如下：

项目需求分析与用例建模

从需求中提取用例并绘制用例图，其基本方法如下：

1. 寻找业务领域相关动名词或名词短语等

2. 验证上述短语或名词是否为用例，标准如下：

   1. 它是不是一个业务过程？
   2. 它是不是由某个参与者触发开始？
   3. 它是不是显式地或隐式地终止于某个参与者？
   4. 它是不是为某个参与者完成了有用的业务工作？

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

下面针对留学信息管理与分析系统进行需求分析与用例建模。

本系统首先要实现的是留学信息的检索。

对留学信息感兴趣的用户在进入网站后，可以根据需要无状态搜索感兴趣的学校或专业，这是该系统的主要功能，由信息检索子系统实现。为方便用户更快捷的获取感兴趣的资料，用户的登录注册功能是必须的，这样用户能收藏感兴趣的资料并注入到用户的收藏或浏览信息里。总结如下：

• Actor: （对留学信息感兴趣的）用户
• System: 信息检索模块（子系统）
• Use case:
  • 检索信息
    • 检索学校信息
    • 检索专业信息
  • 登录用户
  • 注册用户

其次通过分析用户的需求、自身的条件、留学地的社会环境和安全问题、留学学校信息、留学专业信息等可以给用户一个合理的选择区间。

该段描述可以得出：用户可以获得更优质的服务，即根据自身情况获得个性化信息。因此用户必须能提供更详尽的个人信息才能获得更好的服务。为提供更个性化服务，系统需要有智能推荐系统。总结如下：

• Actor: 用户
• System: 用户信息管理模块和推荐算法模块（子系统）
• Use case:
  • 填写个人信息
  • 获取留学建议

此外，通过参考其他类似平台的设计，可以对该系统做一些扩展，如论坛系统，以方便为用户提供更好的留学生态圈，论坛系统前期主要实现发帖、回帖、帖子的评论收藏等。

• Actor: 用户
• System: 论坛模块（子系统）
• Use case:
  • 使用论坛
    • 发帖
    • 回帖
    • 评论帖子
    • 收藏帖子

为保障这些功能，显然还有另一参与者即管理员，管理员主要针对平台资源进行管理，包括：用户信息（如对违规用户进行权限限制）、平台的数据、论坛资源等：

• Actor: 管理员
• System: 后台管理模块（子系统）
• Use case:
  • 管理学校、专业信息
  • 管理论坛信息
  • 管理用户信息

最终小组讨论生成的用例图如下：

业务领域建模

基本概念

业务领域建模是开发团队用于获取业务领域知识的过程。帮助系统分析人员、用户认识现实业务的工具，描述的是业务中涉及到的实体及其相互之间的关系，它是需求分析的产物，与问题域相关。

总之一句话：领域模型是“需求到面向对象的桥梁”。领域建模的一个简单方法就是从需求模型（即用例图）中去识别出概念类，逐步开展，具体步骤为：

• 收集应用业务领域的信息。

  主要指收集功能需求层面的资料，前面工作已经基本完成

• 头脑风暴

  列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系

• 给这些应用业务领域概念分类

  即具体化上一步，识别出哪些是类，哪些是属性，具体的关系（关联、继承、依赖等）是什么

• 将结果用UML类图表示出来

项目领域建模

参考博客：领域模型详解

针对留学信息管理与分析系统的问题域和用例描述，进行头脑风暴。可以通过找名词、加属性、连关系的顺序完成领域建模。

找名词

对于用例描述中的名词进行筛选，找出可以作为类的概念、可以作为属性的概念。如果属性过于复杂，应考虑将该属性单独提出为类，利用设计模式中的命令模式、策略模式等进行设计。不满足条件的概念名词应剔除。筛选如下：

用户、管理员、学校、专业、论坛、文章（帖子）、留言、留学建议、账号密码、个人信息、用户权限...

进一步分析可得：

• 类

  • 普通类

    用户、管理员、学校、专业、文章、留言

  • 关联类（被提出为类的属性）

    • 页面

      用于分页处理和存放检索结果，包括学校、专业、论坛，包括筛选前、筛选后、推荐的结果

    • 算法

      用策略模式将推荐策略单独提出，方便算法的扩展和修改

• 属性

  账号密码、个人信息、用户权限...

加属性

每个类都有一个id属性，增添其他必要属性如下：

类	属性
用户	账号、密码、权限、个人信息（包括雅思托福成绩、所在院校、意向等）、登录注册记录等
管理员	账号、密码、登录记录等
学校	校名、专业、所在地、排名、学校介绍等
专业	名称、学校排名、其他详细信息等
文章	作者、发布时间、热度、tag、文章内容、留言列表等
留言	作者、发布时间、留言内容等
页面	当前页、上下页、首末页、页面内容（学校、专业、id等）、页面请求地址等
算法	N/A

连关系

最后的结果用UML类图表示：

数据建模

数据建模简而言之就是逻辑数据模型的建立，即关系数据表的建立。有前面的UML图可得如下数据关系：

school-major	article-message
m-n	1-n

针对前面的分析，得出七张表，表中列举了主要的信息，其中P_K代表主键，F_K代表外键：

user table：

ID	账号	密码	权限	登录注册记录	收藏	其他必要信息...
(P_K)						(扩展)

admin table:

ID	账号	密码	登录信息	其他必要信息...
(P_K)			(IP、时间等)	(扩展)

school table：

ID	校名	所在地	排名	学校介绍	其他必要信息...
(P_K)					(扩展)

major table:

ID	名称	专业介绍	其他必要信息...
(P_K)			(扩展)

school_major table:

id	school_id	major_id
(P_K)	(F_K)	(F_K)

article table:

ID	作者	发布时间	热度	tag	文章内容	其他必要信息...
(P_K)	(F_K)					(扩展)

message table:

ID	作者	发布时间	留言内容	文章ID	其他必要信息...
(P_K)	(F_K)			(F_K)	(扩展)

概念原型

什么是业务概念原型

• 概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。
• 概念原型是一种虚拟的、理想化的软件产品形式。
• 概念原型=用例+数据模型。因此基于已得出的用例和数据模型，就可以得出概念原型的工作过程。

概念原型工作过程示例

以用户查看、收藏、撰写文章（帖子）为例：

用户输入检索条件，系统根据检索条件从article Table中获得文章信息；

对于每篇文章，系统可以从message table中获得对应的留言信息；

用户如果点击收藏文章，则user table会更新收藏信息，同时文章热度等信息会更新到article table中；

用户撰写文章，则user table中会更新文章相关的数据项，同时article Table中会增添一条记录。

总结

1. 需求分析和建模，两者应该是相辅相成的：需求的分析提供了模型建立的原材料；模型的建立提供了需求分析的表达工具，同时有助于从需求分析到面向对象设计的过渡。
2. 需求的建模包括用例建模、业务领域建模、数据建模等，三者有一定的递进关系。
3. 基于已得出的用例和数据模型，就可以得出概念原型的工作过程。
4. 需求分析和软件产品的设计一样，都是可以程序化的，这有助于提高需求分析的效率和质量，同时有助于开发人员形成统一的业务认知。