让技术人员看得懂的流程(6)——处理模型

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

                                ——处理模型

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

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等方式。

 

 

====================未完待续,后面更精彩==========================

 

时间: 2024-12-30 09:35:34

让技术人员看得懂的流程(6)——处理模型的相关文章

让技术人员看得懂的流程(2)——用例模型

                    让技术人员看得懂的流程(2)                          --用例模型 一般的管理流程都将软件项目划分为"需求->分析->设计->实现->维护",对应的技术流程中首先也肯定是要将需求明确,而"用例模型"就是用于获得和分析需求的. 简单来说,用例模型就是要将客户的需求写下来."需求"不是很好理解,更加通俗的讲法是"故事(story)".我觉得&

让技术人员看得懂的流程(4)——设计模型

                       让技术人员看得懂的流程(4)                                     --设计模型 完成了"领域模型"阶段后,面向对象已经初具雏形,我们已经看到了那熟悉的"对象"了,例如"商品"."交易"."商品清单"等,看起来已经进入了面向对象的世界了,你是否已经摩拳擦掌,跃跃欲试,准备开始编码了呢? 且慢,"领域模型"只是

让技术人员看得懂的流程(3)——领域模型

               让技术人员看得懂的流程(3)                             --领域模型 按照一般的项目管理过程,"需求"之后是"分析",那么在分析阶段对应的技术流程又是哪个?如何将需求阶段和分析阶段联系起来呢?答案就是"领域模型" 什么是"领域模型"呢?只要抓住"领域(Domain)"二字就可以理解,也就是说领域模型是帮助我们理解相关领域知识的模型. 进一步来问:为

让技术人员看得懂的流程(5)——实现模型

                    让技术人员看得懂的流程(5)                                   --实现模型 经过前面的"用例模型"."领域模型"."设计模型"的讲解,面向对象分析设计都完了,面向对象已经基本成型,接下来就是要具体实现了,对应的就是"实现模型". "实现模型"是整个技术流程中大家接触最多的阶段,只要是做开发的,基本上都是先参与这个阶段的工作.顾名思义

技术人员如何跟传统行业打交道?

前几天,读了一本书叫<高难度谈话>,这本书主要讲的就是「沟通」问题,而本书的主题就是「人」--我们这些并不完美却真实的人.人是一种复杂的个体,我们每个人都有自己的观点.思想和感情.技术人员如此,传统行业的「老板」也是如此! 而在很多技术人员眼中,跟他们打交道要比敲代码要复杂「1000」倍.本期移动开发精英俱乐部讨论的主题就是「技术人员如何跟传统行业打交道?」,让我们来听一些技术同学的吐槽,还有哪些解决办法吧!本文系 OneAPM 市场部整理. 程序员眼中的传统行业 晓书生:我觉得跟传统行业打交

如何管理飞扬跋扈的技术人员

在互联网项目当中,相信每一个项目经理或者制作人,最头疼的就是技术部的管理.因为技术工作看起来是那么的棘手,一般人难以理解,而且技术人员大多数都似乎情商不高.管理人员既不能轻易了解技术工作的内涵,技术人员也觉得很难和管理人员沟通.特别是技术工作,难以在不同人之间交接,很多技术人员都声称无法继续别人做过的项目.这让管理者觉得技术人员特别喜欢耍大牌,而且他们要偷懒也非常容易.但正如军事中的定理,对付坦克最好的武器就是坦克,对付航母最好的武器也是航母,这条理论是通用的.要管理好技术人员,就一定要懂技术.

数据科学家和大数据技术人员工具包

数据科学家的常用工具与基本思路,数据分析师和数据科学家使用的工具综合概述,包括开源的技术平台相关工具.挖掘分析处理工具.其它常见工具等几百种,几十个大类,部分网址.为数据科学教育和知识分享,提高数据科学人员素质. 数据科学融合了多门学科并且建立在这些学科的理论和技术之上,包括数学.概率模型.统计学.机器学习.数据仓库.可视化等.在实际应用中,数据科学包括数据的收集.清洗.分析.可视化以及数据应用整个迭代过程,最终帮助组织制定正确的发展决策数据科学的从业者称为数据科学家.数据科学家有其独特的基本思

《进化——我们在互联网上奋斗的故事》一一1.4 从精兵到强将 ——技术人员的职场发展之路

1.4 从精兵到强将 --技术人员的职场发展之路 进化--我们在互联网上奋斗的故事 因兴趣而进入互联网行业 2000年,踏着世纪交替的步伐,我走进入了西北工业大学,学习航空飞行器动力专业而不是计算机专业.在入学之前,我就对计算机有不小的兴趣,进入大学后经常去学校图书馆或实验室上网,对计算机的兴趣越来越浓厚,就去图书馆找一些网页设计.网页特效等书籍学习并动手做一些练习.之后我就很喜欢用263的邮箱,因为它的邮箱支持自定义网页格式,我可以给同学和朋友发送自己设计的个性化的网页格式E-mail.那时很

谈谈技术人员转管理岗的问题

现代通信网络中,交换机发挥的作用越来越大:海量的数据到达这个信息节点,然后按照既定的规则,快速有效地传送到目的地.网络里的交换机就象一个组织里的管理者,把任务拆解分配给不同的人或者单元,并确保任务的完成. 交换机的工作原理并不复杂,硬件基础就是普通的服务器,只不过上层加载的是专用软件,能够快速高效地完成数据和信息交换的任务.如果数据量不大,IT系统中不必引入专用的交换机,通过自行开发的软件也能实现信息交互的目标.就象在一个小规模的组织里,或者完成一项不太复杂的任务,就不一定需要专用的管理人员,技