滴！学生卡（憋缩话，不服来战！）老司机们快上车啦，咱们今天聊聊流程开发的事儿。当然，此流程非彼流程，睁大双眼咱们一起去发现流程开发之美......本文严格面向技术开发人员，力争为大家带来飞一般的感受。come on，一起来指点江山挥斥方遒，武装大脑，淬炼躯壳，洗涤灵魂，朝着升职加薪、迎娶白富美、荣升ceo、走上人生巅峰之路上大步迈进吧。
ps：据说有人按耐不住蠢蠢欲动的心灵，公然求放妹纸靓照！像我这么正直无畏、三观严谨的人......当然无底线满足你啦，不多说，上照。
好了好了，言归正传，咱们可是正经人。
<b>让技术人员看得懂的流程（1）——面向对象设计全流程概述</b>
谈到流程，大家都会想到熟悉的瀑布模型、螺旋模型、迭代开发、敏捷、rup等一堆软件工程相关的软件开发流程，但是请不要误会，本文的流程和这些管理流程完全不同，为了以示区分，我把瀑布模型、敏捷、rup等流程成为项目流程，也就是说这是给项目管理用的；而本文的流程是技术流程，是给技术人员（主要是设计人员）看的流程。
下面将通过几篇短的博文和一个实例来简明概要的讲述这个流程，概要来说主流程如下：用例模型>领域模型>设计模型>实现模型>进程模型>部署模型。实例就用一个简单的pos机系统来讲解。
欲知详情如何，且听下回分解！
<b>让技术人员看得懂的流程（2）——用例模型</b>
一般的管理流程都将软件项目划分为“需求>分析>设计>实现>维护”，对应的技术流程中首先也肯定是要将需求明确，而“用例模型”就是用于获得和分析需求的。简单来说，用例模型就是要将客户的需求写下来。“需求”不是很好理解，更加通俗的讲法是“故事(story)”。
下面我把用例模型阶段容易犯的错误重点说明一下：
1.“需求”和“功能”混淆：需求是对客户有价值的东西，功能是为了实现需求而作的东西；
2.在用例模型阶段进行系统分解：用例模型关注的是用户需求，不需要进行系统分解，把系统当做一个黑盒看待就可以了。
字不如表，表不如图，因为图可以一目了然的看出交互过程。用一句话总结就是：交互用图形，说明用文字。
<b>让技术人员看得懂的流程（3）——领域模型</b>
按照一般的项目管理过程，“需求”之后是“分析”，那么在分析阶段对应的技术流程又是哪个？如何将需求阶段和分析阶段联系起来呢？答案就是“领域模型”。
让我们来看看“领域模型”阶段我们要做什么、该怎么做。简单概括就是“找名词”，分为四个步骤：
1.找出用例模型中的名词；
2.然后识别这些名词本身的相关信息；
3.以及名词之间的相互关联关系；
4.用uml画出领域模型。
经过“领域模型”分析后，可以完成自然语言到面向对象语言的初步转化，领域对象已经识别出来，面向对象已经初具雏形。
ps一点：领域模型过程中识别出来的对象和具体的语言无关。换句话说，public、private、函数这些面向对象的属性在领域模型阶段不需要分析出来。
<b>让技术人员看得懂的流程（4）——设计模型</b>
完成了“领域模型”阶段后，面向对象已经初具雏形，我们已经看到了那熟悉的“对象”了，例如“商品”、“交易”、“商品清单”等，看起来已经进入了面向对象的世界了，你是否已经摩拳擦掌，跃跃欲试，准备开始编码了呢？
且慢，“领域模型”只是万里长征的第一步，通过领域模型分析得到的类还不能指导编码，还需要经过“设计模型”这个阶段的处理，才能基本上指导编码。那莫，设计模型阶段的任务都有哪些呢？
第一个任务就是“为对象添加方法”；
第二个任务是“围绕领域对象设计出非领域对象”；
第三个任务就是“应用设计模式、设计原则”。
重要的一点是，以上的步骤不是瀑布式的，而是迭代式的，need action。
<b>让技术人员看得懂的流程（5）——实现模型</b>
经过前面的“用例模型”、“领域模型”、“设计模型”的讲解，面向对象分析设计都完了，面向对象已经基本成型，接下来就是要具体实现了，对应的就是“实现模型”。
“实现模型”是整个技术流程中大家接触最多的阶段，只要是做开发的，基本上都是先参与这个阶段的工作。顾名思义：实现模型就是使用具体的技术来实现设计，也就是通常意义上的编码。但要注意的是，编码不等于敲键盘，之所以称为“实现模型”，因为这里还是有设计的，只不过这个设计和具体的实现技术有关。
由于具体的实现技术差别很大，因此没有什么通用的方法，“实现模型”阶段需要大家积累具体的技术知识和经验。
<b>让技术人员看得懂的流程（6）——处理模型</b>
看完“实现模型”，你是否长吁一声，准备拿起咖啡，惬意的喝上一杯？毕竟咱们已经完成了从用例到编码的全过程了，确实是值得庆祝的一件事情，但“革命尚未成功、同志还需努力”啊，现在还不是享受的时候，接下来我们需要进入“处理模型”阶段。“处理模型”英文是“process model”，process在it里面又叫“进程”，虽然和进程相关，但直接叫“进程模型”会误导大家，所以我叫它“处理模型”，也就是和处理相关的设计。我们来看看“处理模型”阶段的任务：
1.进程、线程设计；
2.子系统设计。
我们来看如何基于“实现模型”进行进程、线程、架构设计：
第一步：将已有的对象进行分组：分组的原则其实就是大家常见的“高内聚、低耦合”；
第二步：将多个组划分为进程、线程；
第三步：设计进程的同步、通信；
第四步：将进程划分到不同的子系统；
第五步：设计子系统间的同步、通信。
<b>让技术人员看得懂的流程（7）——部署模型（完结篇）</b>
在上一篇博文“处理模型”中已经提到：在“处理模型”阶段划分为子系统后，为下一阶段打下了基础。当时卖了个关子没说具体是什么，本篇就来揭开它的面纱：“部署模型”。“部署模型”英文是“deployment model”，正好对应uml中的“deployment diagrams”，有的文章或者书籍也叫“物理模型”。我之所以没有用“物理模型”，是因为“物理模型”的概念容易误解大家认为这个阶段只需要关注物理设备，而“部署模型”相对更加全面。我们来看部署模型的任务：
1.确定部署实体，即采用什么样的物理设备，例如pc机、服务器、小型机；
2.确定部署方式，例如局域网部署，企业网部署，因特网部署；
3.确定部署连接，即组网方案，设计如何将这些物理设备连接起来。
看不够？还不快戳详情链接！我戳戳戳......