让技术人员看得懂的流程(下)

实现模型

 

经过前面的“用例模型”、“领域模型”、“设计模型”的讲解，面向对象分析设计都完了，面向对象已经基本成型，接下来就是要具体实现了，对应的就是“实现模型”。

“实现模型”是整个技术流程中大家接触最多的阶段，只要是做开发的，基本上都是先参与这个阶段的工作。顾名思义：实现模型就是使用具体的技术来实现设计，也就是通常意义上的编码 。

但要注意的是，编码不等于敲键盘，之所以称为“实现模型”，因为这里还是有设计的，只不过这个设计和具体的实现技术有关。

例如： Interface 在 C++ 中没有，而 Java 中就有，具体编码的时候如果要实现设计图中的 interface ，那么就只能分别如下实现：

1 ） C++ ：声明没有成员变量、所有成员函数都是纯虚函数的 Class ；

2 ） Java ：直接声明为 interface 。

由于具体的实现技术差别很大，因此没有什么通用的方法，“实现模型”阶段需要大家积累具体的技术知识和经验。

处理模型

看完“实现模型”，你是否长吁一声，准备拿起咖啡，惬意的喝上一杯？毕竟我们已经完成了从用例到编码的全过程了，确实是值得庆祝的一件事情，但“革命尚未成功、同志还需努力”，现在还不是享受的时候，接下来我们需要进入“处理模型”阶段。

l         “处理模型”阶段的任务

“处理模型”英文是“ Process Model ”， Process 在 IT 里面又叫“进程”，虽然和进程相关，但直接叫“进程模型”会误导大家，所以我叫它“处理模型”，也就是和处理相关的设计。我们来看看“处理模型”阶段的任务：

1 ）进程、线程设计；

2 ）子系统设计；

为什么需要“处理模型”呢？相信看到上面的任务后，聪明的你应该已经知道了原因：

1 ）随着系统规模增大，处理性能要求增加，必须采用多进程多线程处理方式；

2 ）随着系统规模增大，复杂度增加，加上需要考虑可扩展性、可测试性、可靠性等质量属性，必须采用“分而治之”的方式划分子系统（注意此时还不是架构设计，欲知详情，请关注下一篇博文）；

l         为什么现在才开始进行进程、线程、架构设计？

讲到这里，估计很多朋友都有疑惑了：按照一般的经验，都是最开始就要进行子系统设计、进程线程设计的，怎么你的这个流程到现在才开始进行进程、线程、子系统设计呢？

我们知道：进程、线程、子系统设计都必须有基础，而不是凭空创造或者想象出来的。那种所谓的先画一个圈表示系统、然后再在这个圈下面画几个圈表示子系统、子系统下面再画几个圈表示进程或者线程的自顶向下的设计方式就像“浮沙筑高台”，其实是完全行不通的，为什么呢？

因 为这个时候划分子系统没有任何可靠的依据。架构设计、子系统设计、进程线程设计主要是为了解决性能、可靠性、可扩展性、可测试性、安全性等质量属性，而不 是客户主要关注的功能属性。性能、可靠性、安全性可以从客户获得，但无法像功能属性那样一步一步的映射到代码（客户说要“每秒支持 10000 个交易”，然后你画了三个圈，说“这样就可以达到每秒 10000 个交易”，谁会相信呢？），而可扩展性、可测试性在客户需求阶段根本不会体现。所以我们必须等到“实现模型”完了之后再进行进程、线程、子系统设计、架构设计。

可能大家还有疑问：按照你这个说法，岂不是要等到系统全部编码完成后再来进行进程、线程、架构设计？

回答这个问题的关键词就是“迭代”，第一个迭代（一般都叫做 Demo ）把最主要、最核心、最关键的需求按照“用例模型” -> “领域模型” -> “设计模型” -> “实现模型” -> “处理模型”走一遍流程，这样第一个迭代就可以把架构、子系统、进程、线程初步设计完毕，后续的迭代基本上只要走“用例模型” -> “设计模型” -> “实现模型”就可以了，即使有调整也不会太大，因为第一个迭代式把最主要、最核心、最关键的需求给实现了。

l         具体如何操作？

我们来看如何基于“实现模型”进行进程、线程、架构设计：

1 ）第一步：将已有的对象进行分组；

分组的原则其实就是大家常见的“高内聚、低耦合”，把最相关的、联系最紧密的对象划分到同一组；

2 ）第二步：将多个组划分为进程、线程；

将对象组再分组划分到具体的进程和线程，分组的原则主要看性能要求（响应时间、吞吐量），性能数据可以基于已有的“实现模型”进行评估或者测试。

3 ）第三步：设计进程的同步、通信；

既然是多进程、多线程，就必须设计出进程间同步和通信方式。

4 ）第四步：将进程划分到不同的子系统；

结合根据“高内聚、低耦合”的原则、以及性能、可靠性、可扩展性、可测试性等质量属性要求，将进程划分到不同的子系统；划分子系统也为下一个阶段（卖个关子，先不说 :-P ）打下了基础。

5 ）第五步：设计子系统间的同步、通信

和第三步类似，划分为不同的子系统后，必须设计子系统间的同步和通信方式。

 

看起来步骤比较多，不过每个步骤其实都不难，简单点说就是“排列组合”，将对象排列组合成进程线程，将进程排列组合成子系统。

 

千言万语不如一个用例，我们还是继续前面的 POST 机样例来看看“处理模型”阶段如何操作吧。

经过“实现模型”阶段后，我们的 POST 机可能是这样实现的：“商品”、“交易”、“商品管理”、“商品清单”、“付款方式”、“店铺”、“收银机”、“ VIP 会员”、“供货商”等对象了，接下来我们就要进行“处理模型”设计了：

1 ）第一步：将已有的对象进行分组；

1.1 ）“商品”“商品管理”都是商品相关的对象，因此划为第一组，命名为“商品处理”；

1.2 ）“交易”“商品清单”“付款方式”都是和交易相关的对象，因此划为第二组，命名为“交易处理”；

1.3 ）“店铺”、“收银机”都是系统静态信息，因此划为第三组，命名为“系统信息管理”；

1.4 ）“供货商”、“ VIP 会员”都是第三方的管理信息，因此划为第四组，命名为“第三方管理”

2 ）第二步：将多个组划分为进程、线程；

初步评估，“商品处理”和“交易处理”的性能要求会很高（因为商品很多，交易也在不断进行），而“系统信息”是一个基本静态的信息，性能要求会很低，而“第三方管理”性能要求相对也不高，因此可以设计出 3 个进程：“商品处理”进程、“交易处理”进程、“信息管理”进程，其中“信息管理”进程负责 “系统信息管理”和“第三方管理” 两组对象

3 ）第三步：设计进程的同步、通信；

进程间同步和通信和具体的实现有关，可以参考相关资料，例如 Windows 和 Linux 的可以参考我的博文《多核时代：并行程序设计探讨（ 4 ）—— Windows 和 Linux 对决 ( 进程间通信 ) 》《多核时代：并行程序设计探讨（ 5 ）—— Windows 和 Linux 对决 ( 进程间同步 ) 》 。

4 ）第四步：将不同的进程划分到不同的子系统；

第二步已经设计出三个进程了（实际情况会更多）：“商品处理”进程、“交易处理”进程、“信息管理”进程，因此可以划分为三个子系统：商品管理系统、交易系统、信息系统。其中“信息系统”负责“系统信息管理”和“第三方管理”。

注意：由于此样例比较简单，所以出现了进程和子系统一一对应的情况，实际工作中应该是一个子系统包含 1 至多个进程。

5 ）第五步：设计子系统间的同步、通信

和第三步类似，划分为不同的子系统后，必须设计子系统间的同步和通信方式。

由于子系统可以是进程、线程，也可以是独立运行的程序，因此子系统间通信方式也随着实现方式不同而不同。例如程序间通信可以采用共享文件、共享内存、 Socket 等方式。

部署模型

在上一篇博文“处理模型”中已经提到：在“处理模型”阶段划分为子系统后，为下一阶段打下了基础。当时卖了个关子没说具体是什么，本博就来揭开它的面纱，这就是：“部署模型”。

l         “部署模型”阶段的任务

“部署模型”英文是“ Deployment Model ”，正好对应 UML 中的“ Deployment Diagrams ”，有的文章或者书籍也叫“物理模型”。我之所以没有用“物理模型”，是因为“物理模型”的概念容易误解大家认为这个阶段只需要关注物理设备，而“部署模型”相对更加全面。我们来看部署模型的任务：

1）  确定部署实体，即采用什么样的物理设备，例如 PC 机、服务器、小型机；

2）  确定部署方式，例如局域网部署，企业网部署，因特网部署；

3）  确定部署连接，即组网方案，设计如何将这些物理设备连接起来；

 

l         具体操作步骤

1 ）确定部署实体

在“处理模型”阶段我们已经将子系统划分出来了，但如果你的系统性能、可靠性等质量属性要求很高，那么就需要进一步考虑将子系统再“排列组合”，分布到不同的机器上去。

“排列组合”的原则还是和划分子系统的第四步一样：根据“高内聚、低耦合”的原则、以及性能、可靠性、可扩展性、可测试性等质量属性要求，将子系统划分到不同的机器上去。

简单的说就是“一台不够用两台，两台不够用三台； PC 不够用工作站，工作站不够用小型机 ”。那么是不是机器数量越多越好，质量越高越好呢？也不尽然，因为还需要考虑成本的因素，这就需要架构师、设计师进行权衡了（可以参阅我的博文：《软件设计漫谈之一：什么是软件设计？》 ）。

2 ）确定部署方式

确定好“部署实体”后，就需要考虑部署方式，因为不同的部署方式决定了需要采用不同的网络设备和组网方式。

常见的部署方式有：局域网部署、企业网部署、因特网部署，下面简单的介绍一下：

（ 1 ） 局域网部署 ：俗称 LAN ，即机器都在一个局域网内部，通过 Hub 、 Lanswitch 、网桥等连接，这是范围最小的一种部署方式；

（ 2 ）企业网部署 ：金融、电信、物流等稍微大的公司都会有企业内部网，企业网内部还会划分 VPN 等，通过路由器、交换机等进行连接，这是中等范围的部署方式；

（ 3 ）因特网部署 ：相信大家对这个都很熟悉，最常见的就是网站，如 Sina 、 CSDN 等，需要向宽带服务商如电信等申请因特网 IP 地址，这是范围最广的一种部署方式；

具体采用哪种方式呢？其实很简单：客户会告诉你的：）

当然客户不会直接告诉你说“我们要采用企业网部署”，客户会在需求中隐含描述出来，比如说“分公司将数据发给总公司”，这句话就隐含了要采用“企业网部署”或者“因特网部署”这种方式。

3 ）确定部署连接

确定好部署实体和部署方式后，就需要考虑如何将这些机器连接起来了，即常说的组网，这时就是 TCP/IP 大显身手的时候，我们看看具体如何应用 TCP/IP ：

（ 1 ）确定 IP 地址：包括网段、子网掩码、每台机器的 IP 地址；

（ 2 ）确定连接方式：单连接、双连接、四连接，至于八连接，好像还没有见过：）

（ 3 ）确定连接设备：连接设备和部署方式有关，同时也和性能、可靠性有关。例如：局域网要求不高的可以用 hub ，要求再高点就要低端的 Lanswitch 了；企业网和因特网就需要路由器了。

 

千言万语不如一个样例，让我们来看看 POS 系统在“部署阶段”如何操作。在“处理模型”阶段我们已经划分出 3 个子系统了：商品管理系统、交易系统、信息系统，我们基于这 3 个系统进行简要分析：

1 ）确定部署实体

假设要买 POS 系统的超市的物流和库存是集中管理，而交易是由各个分店分散管理，那么“商品管理系统”和“信息系统”可以部署在同一台小型机上面（根据性能和可靠性等要求的不同，可能是两台、三台甚至更多，样例中我们假设一台就够了）。

“交易系统”由于是分散的，服务器配置应该就够了，每个分店一台。

2 ）确定部署方式

从需求可以很容易看出： POS 系统最好采用企业网部署的方式，因为有分店、有总店，这些分店和总店是分散的。

3 ）确定部署连接

IP 地址的分配根据具体情况分配即可。根据部署方式可以推断出需要采用路由器类型的设备进行连接，而为了保证交易系统的可靠性（总不能网线一断，超市就关门不做生意了吧），需要双连接甚至是四连接。

 

========================= 连载完毕 ==================================

到这里这一系列就结束了，各位看官是否有所收获呢？

如果以下问题能够正确答复，恭喜你，说明你已经基本上掌握了面向对象设计全流程的处理：

1 、客户的需求是描述性的，例如“我们需要一个 POS 机”，而代码是一个一个具体的类和函数，那么如何从描述性的语言最后转化到具体的类和函数呢？

2 、具体语言的特性，例如 Java 和 C++ 的 private 、 protected 、 public 这些属性是从哪里来的？什么时候设计的？

3 、不管什么代码，最后都要运行在具体的平台上，如 Windows 、 Linux 、 UNIX 等，那么这些平台相关的进程、线程什么时候设计、如何设计？（不要说你所有的产品都是单线程或者单进程哈： -P ）

4 、如果是稍微大一点的产品，需要运行在多台机器上，那么如何确定需要多少机器？如何分工？

http://blog.csdn.net/yah99_wolf/archive/2010/01.aspx