《商户对接小程序》的需求分析和概念模型

参考： https://gitee.com/mengning997/se/tree/master/ppt，从需求分析到软件设计

0、序言

通过对本章《从需求分析到软件设计》的学习，使我懂得了在拿到用户需求或者问题之后，我们要按照先后顺序依次进行用例建模、业务领域建模、数据建模最后形成相应的概念原型，然后便可以在此基础之上快速的完成项目了。我的工程实践项目是《商户对接小程序》，他的主要目的是让商家和用户可以直接在微信小程序里就可以相互交互，发布产品和购买产品，他的规则和主要功能如下，同时这里我要声明本来这是前端制作的页面，这里只是我为了学习三大建模而强行对这个前端页面使用后端建模的方法对他建模。

1、用例建模

<1>首先我们要了解用例的一些相关概念：

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

<2>用例的基本要素：

• 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>用例的层级：

• 抽象用例（Abstract use case）。只要用一个干什么、做什么或完成什么业务任务的动名词短语，就可以非常精简地指明一个用例；

• 高层用例（High level use case）。需要给用例的范围划定一个边界，也就是用例在什么时候什么地方开始，以及在什么时候什么地方结束；

• 扩展用例（Expanded use case）。需要将参与者和待开发软件系统为了完成用例所规定的业务任务的交互过程一步一步详细地描述出来，一般我们使用一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来。

<4>用例建模的基本步骤：

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

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

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

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

<5>提取用例：

System1: Backstage function manage system

Actor: Shop owner、Personal user、Administrator

Use Cases: UC1: introduce shop、 UC2:release shop information、UC3：release external information、

UC4：obtain customer service、UC5：set avatar 、UC6：set username、

UC7：get information、UC8：audit application for shop、UC9：categorize shops、

UC10：audit shop's information、UC11：release administrator's information、UC12：manage the home page、

UC13：design inquiry

其分类如下

得到的案例图如下：

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

提取用例：System2:Page operating system

Actor: Shop owner、Personal user、Administrator

Use Cases: UC1：enter the home page、UC2：apply for a shop 、UC3：enter personal page、

UC4：enter the shop page、UC5：find shops、UC6：find products、

UC7：find examples

其分类如下：

得到的案例图如下：

2、业务领域建模

<1>业务领域建模的常用概念：

对象（Object）和属性（Attribute）：一个对象作为某个类的实例，在业务领域内是能够独立存在的，属性往往不能独立存在。

继承关系（Inheritance Relationship）：继承关系表达着两个概念之间具有概括化/具体化（generalization/specialization）的关系。

聚合关系（Aggregation Relationship）：聚合关系表示一个对象是另一个对象的一部分的情况。

关联关系（Association Relationship）：关联关系表示继承和聚合以外的一般关系，是业务领域内特定的两个概念之间的关系。

<2>业务领域建模的一般过程

①第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；

②第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；

③第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系；

④最后用UML类图将业务领域知识图形化展示。

<3>根据上一步的用例图得到uml类图

3、数据建模

<1>数据库常用软件以及一些基本概念

软件：MongoDB是一种文档数据库，也就是说MongoDB用类似JSON格式的文档来存储数据。目前普遍认为JSON格式是理解和存储数据最自然的方式，JSON格式比传统的关系数据模型有更强大的数据表达能力。

概念：一个支持事务（Transaction）的数据库，必须要具有这四种特性，原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。

<2>一对多关系建模的三种基础方案

三种基本的设计方案：内嵌，子引用，父引用

<3>反范氏化

①本质就是双向关联，使用双向引用来优化你的数据库架构，可以在引用关系中冗余数据到one端或者N端，前提是你能接受无法原子更新的代价。

② 在决定是否采用反范式化时需要考虑下面的因素：你将无法对冗余的数据进行原子更新，只有读写比比较高的情况下才应该采取反范式化的设计。

<4>具体建模

①店铺的名字、头像、网址等采用内嵌

②个人用户的名字和头像采用内嵌

③每个用户发布的信息采用子引用

④店铺的产品和案例采用父引用

shop owner: