1、概述
谈到流程，大家都会想到熟悉的瀑布模型、螺旋模型、迭代开发、敏捷、RUP等一堆软件工程相关的软件开发流程，但是请不要误会，本文的流程和这些管理流程完全不同，为了以示区分，我把瀑布模型、敏捷、RUP等流程成为项目流程，也就是说这是给项目管理用的；而本文的流程是技术流程，是给技术人员（主要是设计人员）看的流程。
在开始讲解之前，看看如下问题你是否能够回答？
1、客户的需求是描述性的，例如“我们需要一个POS机”，而代码是一个一个具体的类和函数，那么如何从描述性的语言最后转化到具体的类和函数呢？
2、具体语言的特性，例如Java和C++的private、protected、public这些属性是从哪里来的？什么时候设计的？
3、不管什么代码，最后都要运行在具体的平台上，如Windows、Linux、UNIX等，那么这些平台相关的进程、线程什么时候设计、如何设计？（不要说你所有的产品都是单线程或者单进程哈：-P）
4、如果是稍微大一点的产品，需要运行在多台机器上，那么如何确定需要多少机器？如何分工？
怎么样？以上这些问题是否似曾相识，或者自己是否考虑过？
如果你的第一反应是去翻开《软件工程》、RUP、敏捷开发等相关著作，那么我可以很肯定的告诉你你会失望的，就像前面提到的，这些东西不是管理流程的事情，而是技术流程的事情。
如果你心有疑问，或者不敢肯定自己的答案，那么“不懂的人有福了”，因为我将通过几篇短的博文和一个实例来简明概要的讲述这个流程，概要的讲，主流程如下：
用例模型->领域模型->设计模型->实现模型->进程模型->部署模型
实例就用一个简单的POS机系统来讲解！
2、用例模型
一般的管理流程都将软件项目划分为“需求->分析->设计->实现->维护”，对应的技术流程中首先也肯定是要将需求明确，而“用例模型”就是用于获得和分析需求的。
简单来说，用例模型就是要将客户的需求写下来。“需求”不是很好理解，更加通俗的讲法是“故事(story)”。我觉得“故事”这个词非常好，非常形象，非常容易理解！我们看看为什么“故事”更加容易适合说明客户要求：
（1）故事中有很多角色，而需求中也有很多角色；
（2）故事有具体的经过，有开始、进行、结束；而需求也是一个完整的流程，有输入、处理、输出。
（3）故事必须有意义，而需求对客户来说，也是必须有意义的；
具体的用例格式等这里就不详细描述了，大家上网搜索一下就知道了，如何更好的把握需求可以参考我的博文《需求分析的故事——如何练就需求分析的火眼金晴？》，下面我把用例模型阶段容易犯的错误重点说明一下。
1）“需求”和“功能”混淆
很多朋友在分析需求的时候，将“功能”和“需求”混淆起来，导致了需求的粒度不合理，或者把握不住重点的需求，我总结出一个很简单的区分办法：“需求是对客户有价值的东西，功能是为了实现需求而作的东西”。
以POS机为例：对于客户来说，“买单”是一个有价值的东西，因为客户买完单就可以把商品拿走了；而买单过程中的“读商品条形码”、“计算商品总额”、“打印购物清单”等都是功能，因为它们当中任何一个独立的功能对客户没有价值（你不会跑到超市“读商品条形码”玩吧:-P），只是为了实现“买单”而做的。
2）在用例模型阶段进行系统分解
除了容易将“功能”和“需求”混淆外，用例模型阶段还有一个常见的错误就是在用例模型阶段对系统进行分解。
以POS机为例，有的人将需求描写为：扫描机扫描商品条形码信息，然后将信息发给库存系统，库存系统返回详细的商品信息给交易系统……在用例模型阶段这样做是不对的，因为这样转移了我们的注意力：从关注用户需求转到了系统分析了。
记住：用例模型关注的是用户需求，不需要进行系统分解，把系统当做一个黑盒看待就可以了。
下面我们给出POS机一个简单的用例片段，有兴趣的可以自己写一个完整的（这个完整的可不简单哦，至少可以写3页）：
1）顾客携带商品到收银台；
2）收银员扫描商品条形码；
3）系统根据条形码获取并显示商品信息；
4）收银员重复2~3步，直到所有商品扫描完毕；
5）系统计算商品总额；
... ...
n）系统打出商品清单，完成交易。
SSD即系统顺序图，目的就是站在系统的角度，以UML的顺序图来描述系统与“外部实体”（包括人、其它系统、输入输出设备）的交互过程，简单来说就是“图形化的用例”。
那为什么有了文字化的用例文档，还要图形化的SSD呢？其实很简单：字不如表，表不如图，因为图可以一目了然的看出交互过程。
可能有的朋友又要问了：既然图那么好，还要文字描述的用例做什么呢？有两个原因：第一个是客户不会用UML给你描述需求，客户只会用自然语言描述需求；第二个就是图形的优点是简洁、一目了然，但图形的缺点就是不能承载太多信息，详细和丰富的信息还是要文字来承载。
用一句话总结就是：交互用图形，说明用文字！
那么，是否一个用例就要写一个SSD呢？基本上不需要，因为SSD重点在描述系统的交互过程，如果用例本身没有什么交互、或者交互很少或者很简单，就不需要SSD。只有主要的、复杂的用例才需要SSD。
3、领域模型
按照一般的项目管理过程，“需求”之后是“分析”，那么在分析阶段对应的技术流程又是哪个？如何将需求阶段和分析阶段联系起来呢？答案就是“领域模型”。什么是“领域模型”呢？只要抓住“领域（Domain）”二字就可以理解，也就是说领域模型是帮助我们理解相关领域知识的模型。
进一步来问：为什么需要领域模型？前面不是有“用例模型”吗，看起来用例模型好像就是描述相关领域知识的，是否完成用例模型就可以进行设计了？如果你曾经写过用例文档，或者仔细看过用例文档，那么你肯定知道“用例”本身和“面向对象”、“类”这些都没有关系，用例就是纯自然的语言（比如英语、汉语）写的，因为用例实际上由客户口述给我们、然后由我们形成文档化的用例文档，客户才不管我们是什么面向对象还是面向过程还是阿猫阿狗的。
因此，单纯从用例来看，是没有类的概念的，无法完成从自然语言到面向对象语言的转换。但是，既然我们已经完成了用例模型，那么就必须基于用例模型进行分析(否则用例模型岂不是白做了)，而“领域模型”就是自然语言向面向对象语言的一座桥梁。
让我们来看看“领域模型”阶段我们要做什么、该怎么做。其实很简单，简单概括就是“找名词”，分为四个步骤：（1）找出用例模型中的名词，（2）然后识别这些名词本身的相关信息，（3）以及名词之间的相互关联关系，（4）用UML画出领域模型。
我们来看在“用例模型”章节中的POST用例如何得出领域模型。
第一步：找出用例模型中的名词
原有用例如下，用蓝色加黑标出名词（重复的就不标了）：
1）顾客携带商品到收银台；
2）收银员扫描商品条形码；
3）系统根据条形码获取并显示商品信息；
4）收银员重复2~3步，直到所有商品扫描完毕；
5）系统计算商品总额；
... ...
n）系统打出商品清单，完成交易。
这个用例中的名词有“顾客”、“商品”、“收银台”、“收银员”、“商品条形码”、“系统”、“商品信息”、“商品总额”、“商品清单”、“交易”。稍加整理：
1）“顾客”、“收银员”是系统的外部对象，不需要我们进行设计，但这些对象要和系统进行交互；
2）“商品”、“商品条形码”、“商品信息”、“商品总额”、“商品清单”、“交易”是领域对象，但“商品条形码”、“商品信息”可以算作“商品”的属性、“商品总额”可以算作“交易”的属性，最后从这个用例总结出来的领域对象有“商品”、“商品清单”、“交易”三个。
第二步：识别这些名词本身的相关信息
一个对象的属性可能分布在多个用例中，因此可以通过迭代不断的完善一个对象的属性，大家可以看到，我们在第一步中的样例就已经分析了一部分了：“商品条形码”、“商品信息”可以算作“商品”的属性。对象除了属性外，还有一些约束或者限制，这些在用例中可能有，也可能没有，这就需要分析人员来发现了。比如说交易金额必须大于0.1元小于99999元这种约束，用例中不一定会体现，可能需要分析人员向客户咨询。
第三步：识别对象间的关系
面向对象设计就是依靠对象间的互相协作来配合完成相应的功能，因此识别出对象和对象本身的属性外，还要识别对象间的关系，例如1对多、1对1、依赖等，详细的各种关系可以参考UML的标准定义。
我们以第一步识别的三个对象为例：“商品清单”包含多个“商品”、一次“交易”对应一个“商品清单”、一个“商品”只能属于一个“交易”等。
第四步：画出领域模型UML图
UML这里就不啰嗦了，我们结合前三步的分析，画出这个样例的UML领域模型图
可以看到，经过“领域模型”的分析后，已经完成了自然语言到面向对象语言的初步转化了，领域对象已经识别出来，面向对象已经初具雏形。
需要提醒的是：领域模型过程中识别出来的对象和具体的语言无关，也没有方法。换句话说，public、private、函数这些面向对象的属性在领域模型阶段不需要分析出来。
4、设计模型
完成了“领域模型”阶段后，面向对象已经初具雏形，我们已经看到了那熟悉的“对象”了，例如“商品”、“交易”、“商品清单”等，看起来已经进入了面向对象的世界了，你是否已经摩拳擦掌，跃跃欲试，准备开始编码了呢？
且慢，“领域模型”只是万里长征的第一步，通过领域模型分析得到的类还不能指导编码，还需要经过“设计模型”这个阶段的处理，才能基本上指导编码。前面我们提过，领域模型的对象是没有方法的，但最终的实现肯定是有方法的，因此设计模型的第一个任务就是“为对象添加方法”。那么是否给领域模型中的对象添加完方法就算是完成了设计模型呢？没有这么简单，给领域模型中的对象添加方法只是设计模型中最简单的一部分工作，设计模型阶段第二个任务是“围绕领域对象设计出非领域对象”。
这句话看起来比较难拗口，为什么要设计出非领域对象呢？道理很简单：领域模型中的对象是静态的，要让这些静态的对象动起来，才能最终完成客户需求。因此必须添加非领域对象，让这些非领域对象来完成让领域对象动起来的事情。
例如：“商品”本身是一个领域对象，但是这个对象是谁创建、谁使用、谁管理呢？领域模型中并没有相关的对象来完成这些职责，因此需要我们设计额外的对象来完成这些职责。
经过前两步之后，看起来设计模型的对象都已经出来了，但是我们如何知道设计得好还是不好，以什么标准来判断我们的设计是否正确呢？相信基础扎实的朋友们已经想到了，这就是万人期待、万众瞩目的，大家都耳熟能详的一个东东：设计模式。设计模型第三个任务就是“应用设计模式、设计原则”。
通过应用设计模式、设计原则，又会添加一批新的对象，接口、父子类、继承、依赖等面向对象的相关概念也逐步清晰，这样就为最终的编码打下了坚实的基础。
到这里为止，“设计模型”阶段的任务基本讲述完了，下面我们看一个简单的样例，还是以POST机为例：在“领域模型”阶段我们已经分析出了“商品”、“商品清单”、“交易”三个领域对象，我们按照前面所讲的三个步骤一步一步来看“设计模型”阶段如何做（都以“商品”对象为例）。
第一步：“为对象添加方法”
商品对象的方法有：“获取名称”、“获取条形码”、“获取价格”等（有兴趣的朋友可以自己完善），这样对象的几个方法就出来了：getName（）、getBarCode（）、getPrice（）。
第二步：“围绕领域对象设计出非领域对象”
“商品”对象的生命周期包括：创建、修改、使用、销毁，这些任务对象本身是无法完成的，必须添加新的对象来完成，这里我们添加一个新的对象“商品管理”来完成这些任务。这样“商品管理”对象就出来了，而这个对象在用例模型和领域模型中都是没有的。
第三步：“应用设计模式、设计原则”
我们简单的应用DIP原则（可以参考我的Blog《软件设计漫谈之三：30分钟掌握面向对象类的设计原则》）就可以发现，“商品”本身应该作为一个接口，因为不同的商品之间是有很大差异，“商品”又可以分为“食品类商品”、“饮料类商品”、“服装类商品”等等。这样应用了设计原则后，在领域模型中作为对象的“商品”，在设计模型中不再是具体对象，而是接口，然后这个接口派生出“食品类商品”、“饮料类商品”、“服装类商品”等具体对象。
以上的步骤不是瀑布式的，而是迭代式的，例如：第三步识别出“饮料类商品”这个对象后，也需要为它添加方法、设计出相关的类。