仿知乎专栏的需求分析和概念原型
1. 前言
知乎专栏看起来实现地非常简洁，用起来很舒适。主要包括了编写和查看两大模块。编写模块中，用户可以新增文章，更新文章。查看模块包含查看列表，添加评论，赞同以及分享功能，下面以软件工程的思维来深度剖析知乎专栏的实现。参考《从需求分析到软件设计》
2. 需求分析
仿知乎专栏除了固定的用户注册，登录功能外，主要包含编辑和查看两大功能
2.1 编辑功能
- 保存草稿：用户在编辑一部分文章之后，可以先保存为草稿。当用户想再次编辑文章时，可以将文章恢复到上一次保存的状态
- 发布文章：用户编辑好文章后，可以发布文章，这样所有用户便能看到发布后的文章，没有发布的文章处在草稿状态
- 更新文章：用户发布文章后，如果需要对文章进行修改，包括修改标题和正文，则可继续进入编辑页面进行修改，并点击更新按钮对文章进行更新
- 预览文章：用户可以在编辑之后，点击预览按钮，查看发布后的效果
2.2 查看功能
- 查看专栏作者列表：用户可以看到已经发布过文章的专栏作者列表，可以从中选中感兴趣的作者
- 查看文章列表：用户可以在选中某位作者后，查看该作者已发布的文章列表
- 查看文章：用户可以在文章列表中点击某一篇文章，进入该文章的展示页面，进行浏览
- 评论文章：用户可以在查看文章页面的下方添加评论，同时也可以回复别的用户的评论
- 分享文章：用户可以点击分享按钮，生成分享链接。
3. 用例
3.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. 一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。
3.2 用例建模的基本步骤
- 第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例；
- 第二步，描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
- 第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
- 第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
其中第一步到第三步是计划阶段，第四步是增量实现阶段。
3.3 知乎专栏作者用例图
用户可以注册，登录，以及编辑文章，浏览文章。编辑模块的用户是作者，作者可以保存草稿，发布文章，更新文章以及预览文章。浏览文章模块可以查看作者列表，文章列表，文章以及添加评论和分享文章。
4. 业务领域建模
业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。
4.1 业务领域建模的基本步骤
- 第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
- 第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
- 第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
- 第四步，将结果用 UML 类图画出来。
4.2 UML类图
5. 数据模型
5.1 概念模型
我们可以使用E-R图来描述涉及到的概念模型
5.2 物理数据模型
根据上面的E-R图可以给出物理数据模型
5.2.1 User表
| 列名 | 类型 | 长度 | 非空 | 唯一 | 注释 |
|---|---|---|---|---|---|
| id | bigint | 20 | 是 | 是 | 用户ID |
| name | varchar | 20 | 是 | 否 | 用户名 |
| passwd | varchar | 40 | 是 | 否 | 用户密码 |
| varchar | 50 | 是 | 是 | 电子邮件地址 | |
| create_time | date | 是 | 否 | 创建时间 | |
| update_time | date | 是 | 否 | 修改时间 |
5.2.2 Article表
| 列名 | 类型 | 长度 | 非空 | 唯一 | 注释 |
|---|---|---|---|---|---|
| id | bigint | 20 | 是 | 是 | 文章ID |
| title | varchar | 40 | 是 | 否 | 文章标题 |
| body | text | 是 | 否 | 文章正文 | |
| create_time | date | 是 | 否 | 创建时间 |
5.2.3 OperateArticle表
| 列名 | 类型 | 长度 | 非空 | 唯一 | 注释 |
|---|---|---|---|---|---|
| id | bigint | 20 | 是 | 是 | 关联表中记录的标识 |
| userId | bigint | 20 | 是 | 否 | 用户Id |
| articleId | bigint | 20 | 是 | 是 | 文章ID |
| is_pub | int | 2 | 是 | 否 | 文章是否已经发布，0:未发布，1:已发布 |
| is_delete | int | 2 | 是 | 否 | 文章是否被删除 |
| create_time | date | 是 | 否 | 创建时间 | |
| update_time | date | 是 | 否 | 修改时间 |
5.2.4 Comment 表
| 列名 | 类型 | 长度 | 非空 | 唯一 | 注释 |
|---|---|---|---|---|---|
| id | bigint | 20 | 是 | 是 | 评论Id |
| content | text | 是 | 否 | 评论内容 | |
| create_time | date | 是 | 否 | 创建时间 |
5.2.5 OperateComment表
| 列名 | 类型 | 长度 | 非空 | 唯一 | 注释 |
|---|---|---|---|---|---|
| id | bigint | 20 | 是 | 是 | 用户与评论的关联Id |
| comment_id | bigint | 20 | 是 | 是 | 评论id |
| last_comment_id | bigint | 20 | 是 | 是 | 该条评论关联的上一条评论 |
| article_id | bigint | 20 | 是 | 否 | 该评论对应的文章id |
| user_id | bigint | 20 | 是 | 否 | 该评论对应的用户 |
| create_time | date | 是 | 否 | 创建时间 | |
| update_time | date | 是 | 否 | 修改时间 |
6. 业务概念原型
- 概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论
- 概念原型是一种虚拟的、理想化的软件产品形式
根据以上用例，数据模型分析，我们可以得出仿知乎专栏的业务概念原型:
- 用例图只有一个用户用例图
- 数据模型分为用户，文章，评论以及他们之间的关联数据模型
- 概念模型的工作过程：
用户登录系统后，在编写文章阶段，用户可以进入编辑页面，给文章添加标题，正文，并可临时保存文章为草稿，以待后续编辑。同时可以对编辑后的文章进行预览，以及发布更新。用户也可以直接翻看专栏作者列表，查看某位作者的文章列表，并查看文章细节，对文章进行评论以及分享。
7. 总结
通过对仿知乎专栏的一系列分析过程，我学习并实操了软件工程中的一些很有用的建模方法。这些方法能够让我在实际的工作中更好地理解需求，更好地设计出一个稳定，可用，好维护的系统，这将对我的工程实践产生巨大帮助。我始终认为做程序员不能只是安分于做一个开发小模块的螺丝钉，而是要纵览全局，从整体对系统进行把握。这是从基层码农到架构师的进阶之路，因此学好软件工程非常重要，以后我也会把很多软件工程思想融入到实际项目中，为以后的成长打好基础。
