猿设计2——电商后台全逻辑需求挖掘

看过上一章节相信你从感官上对电商的前台系统有了一个感性的认知，也学些了UML用例图的基本画法。开始试图画用例图去分析归纳系统的功能点。也许你会觉得这些东西有一点简单可笑，设计的事情你觉得不屑于去做，但这些东西确实能够帮助你清晰的认识系统，去挖掘系统的功能，最后落地到系统设计。

昨天我们通过UML用例图的方式，初步完成了电商前台系统的需求挖掘。有的同学可能会问，为什么页面那么多，你这边却只是找寻了一部分功能？这个是没有办法的事情，本着学习的目的，我们尽量做一套完整的电商，针对电商的黄金流程下手就可以了。只是我们像模像样的去做最核心的需求和逻辑，同时帮助大家学习和提高一点系统分析设计的功夫。我们初步定义为搞一个B2C模式的，同时预留商家设计，这样如果要搞一套商家的东西，我们可以快速的折腾出来。

虽然我们都是外贸协会的，但是如果讲到开店这种事情，还是马老板那边成本低些。为了本次设计，工厂君特地找到了从小一起长大的好友——哦 塔塔。友情赞助了一把商家后台截图，大家如果有母婴用品需要可以找他（淘宝上按店铺搜索直达）。

废话不多说，我们一起来看下马老板的千牛卖家工作平台，工厂君感慨万千，和工厂君10多年前码过的基本上是两回事情了。不过我们还是可以借鉴一些东西的。

鉴于我们关注的是黄金流程的东西，我们着重看下商家、商品、订单、营销（促销）、售后、物流相关的东西，我们用UML的用例图简单画一下先。

经过昨天的UML用例图的实际操作，相信大家发现了一个问题吧——如果一个用例是一个非常大的功能点，那么在画用例图的时候，会比较复制噢。刚入门的同学可以尝试，将系统的用例拆得小一些，然后针对每一个小点进行性需求分析和挖掘，这样相对容易。

由于我们要做一个B2C的站点，预留商家部分的设计，马老板提供给商家看的不是很适合我们，所以暂时先放那儿。我们先看看如何发布一个商品。

发布商品是一个非常复杂的操作，我们一步一步的来看，这样用例画起来相对简单一些。

接下来我们看看这个复杂的商品信息填写页面，总的来讲商品信息分为以下由以下几个部分组成——基础信息、销售信息、图文描述、物流信息、支付信息、售后服务组成。我们可以先画出总的用例图再逐步分析。

多进入几次发布页面，你会发现，不同的类目，在类目动态这块儿的需要填写的内容，其实是动态的，品牌也是可以选择的。于是我们的用例开始变了噢。

我们再看看销售属性的填写，在销售属性的填写中，你同样会发现，每增加一个销售属性，比如颜色分类，就会增加一个销售规格，这一点很重要噢，至于为什么这样设计，以后我们再说。我们的用例图又发生变化了。

图文描述信息我们可以清楚的看见，主要分为图片上传（视频本期暂时不做支持）和富文本信息的填写。用例图将再次发生变化了。

支付信息这块儿我们暂时先不做预售，所以暂时不考虑。我们看看物流信息这块，物流信息主要涉及运费的计算，这个早就抽象为运费模板了，这里要做的其实是选择运费模板和填写模板需要的参数。于是用例再度发生了变化。

售后服务更多的是一个承诺性质的勾选，并无其他功能。我们接下来看看物流管理的一些功能。

物流管理主要提供了服务商（承运商）设置（物流公司），运费模板设置、物流信息跟踪（需要三方承运商的商务接口，本期做不了），地址库(四级地址做不了)，运单模板（需要针对具体的承运商做定制开发，暂时略过）。我们的物流管理变成了。

接下来我们看看订单管理这个核心的页面，由于我们的系统才刚刚开始开发，暂时不涉及很多的数据量，也就不存在很多需要管理的订单，所以近三个月的订单和三个月前的订单暂时就不需要了。

我们在整理需求的时候，有些展示性的叫法，我们可以做一些调整，让功能点的名字更加具体，我们先画一个主用例。

我们看一下等待发货的界面，仔细分析一下有哪些功能。

我们可以看到，虽然等待发货的界面就一个操作，但是依然展示了订单详情和商品列表，点击发货触发发货功能。发货这一块儿，由于我们是B2C的模式，收货货品不会和买家讨价还价，地址这块儿也不在此处修改，所以我们的用例如下。

我们再看看其他的功能点。物流跟踪信息需要三方快递公司的支持，暂时不做考虑，退款的话，暂时支持整单退款即可。

所以最终我们发现也就是已完成订单，我们需要具体关注，最终我们订单的用例图如下。