猿设计3——电商设计之挖掘实体的办法

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

昨天我们通过UML用例图的方式，初步完成了电商前台系统的需求挖掘。有的同学可能会问，我们画了很多小人还有那些圈圈（用例），到底有什么用处？靠这些小人和圈圈就能设计出一个系统？这些图又不是代码，画着十分无趣，远没有代码来得实在，学来有什么用？

猿人工厂君，这就回答一波。我们是通过UML的方式来设计系统，当然有很多图需要画，画图是你设计能力的体现，以后的工作中也会用到。UML的用例图，最大的作用，是可以帮你梳理清楚系统有哪些功能点需要去完成，明确系统的功能界限。靠用例图当然不能完成系统的设计，不过我们会在设计的工程中引入更多的图，不同的图可以干不同的事情，慢慢的就会知道了。有些同学可能对画图这种事情不感兴趣，但是工厂君要告诉你，将代码讲技术的一大堆，讲设计的可不多噢，设计和实现是一套完整的知识体系，也是猿人安生立命的功夫之一，好好看看吧。

今天，我们通过，过去两天的用例来分析分析，我们的系统需要用到哪些实体。我们先把系统需要用到的实体提炼出来，在今后的设计中继续深入分析，自顶向下，逐步迭代，采用RUP的思路进行。

RUP是什么？哈哈，这个必须给你讲讲了。RUP（Rational Unified Process），统一软件开发过程，统一软件过程是一个面向对象且基于网络的程序开发方法论。在这个理论下，它有三个重要的特点：

1）软件开发是一个迭代过程。

2）软件开发是由Use Case驱动的。

3）软件开发是以架构设计（Architectural Design）为中心的。

看到了吧，迭代和用例驱动来进行软件的开发。你说用例重要不重要？我们今天就分析用例，找出主要实体和实体间的关系就好了。在今后的文章中再针对实体进行深入分析。一件复杂的事情拆成多件简单的事情来做，一个看似简单的东西再深入分析，就会得到复杂的结果。

要表示一个实体，自然是UML的类图比较合适了。什么是类图？类图主要用在面向对象软件开发的分析和设计阶段，描述系统的静态结构。类图图示了所构建系统的所有实体、实体的内部结构以及实体之间的关系。通过画类图能够帮助你快速找出系统内部所用到的实体，简化你对系统的理解，也会找到之后编码和测试的依据噢。废话不多说，我们一起来看看之前的UC吧。

我们先从游客层面的功能点入手，一个网站的游客，可以注册/登录网站。可以访问网站首页，可以看到活动信息列表。可以看到网站的类目信息，可以搜索自己感兴趣的商品，用户还可以根据品牌、商品属性，选择自己喜欢的商品。这么开看，我们可以很容易的看出有以下几个实体——用户、活动信息、类目、类目属性、品牌、商品。我们用UML类图简单的表示下。

我们继续从游客层面入手，看看游客其他的功能点，抓取我们需要的实体。

游客在商品详情页面可以看到商品相关的促销信息、优惠券信息、还可以根据商品的一些属性，挑选自己中意的商品，加入到购物车。在购物车里，游客依然可以看到商品信息、以及商品是哪个商家的、还可以对需要购买的商品发起结算。我们能够轻易的找到以下几个实体：促销信息、优惠券、商品属性、购物车、商家。

我们接下来从登录用户的角度看之前画的UC。找出新的实体。

用户在登录之后，可以完善自己的个人信息，可以维护自己的收货地址。可以真正的发起商品结算，可以提出开具发票的要求。订单结算之后，可以发起支付，同时如果对订单的商品不满意，还可以发起售后服务，比如返修/退换货，退款等等要求。从这些需求来看，我们可以轻易的分析出以下实体：用户收货地址、订单、订单支付信息、订单售后服务信息。

接下来，我们从系统用户的UC出发，分析下功能点。挖掘

从系统用户的角度来看，系统用户主要的功能是，发布和维护商品，管理订单，处理售后三个大层面。系统用户在发布和维护商品时，需要维护商品的运费模板，而运费模板本质上是承运商提出来的计算规则的一个抽象，那么系统用户同样可以设置承运商。至于售后和订单的管理，除了订单评价之外，这些实体我们已经提取出来了。那么我们又发现了新的实体：系统用户、承运商、运费模板、订单评价。于是我们的类图表示一下就是。