让技术人员看得懂的流程.pdfVIP

技术人员看得懂的流程 面向对象设计全流程概述 谈到流程，大家都会想到熟悉的瀑布模型、螺旋模型、迭代开发、敏捷、RUP 等一堆软件 工程相关的软件开发流程，但是请不要误会，本文的流程和这些管理流程完全不同，为了以 示区分，我把瀑布模型、敏捷、RUP 等流程成为项目流程，也就是说这是给项目管理用的； 而本文的流程是技术流程，是给技术人员（主要是设计人员）看的流程。 在开始讲解之前，看看如下问题你是否能够回答？ 1、客户的需求是描述性的，例如 “我们需要一个 POS 机”，而代码是一个一个具体的类和 函数，那么如何从描述性的语言最后转化到具体的类和函数呢？ 2 、具体语言的特性，例如Java 和C++ 的private、protected、public 这些属性是从哪里来的？ 什么时候设计的？ 3、不管什么代码，最后都要运行在具体的平台上，如Windows 、Linux 、UNIX 等，那么这 些平台相关的进程、线程什么时候设计、如何设计？（不要说你所有的产品都是单线程或者 单进程哈：-P ） 4 、如果是稍微大一点的产品，需要运行在多台机器上，那么如何确定需要多少机器？如何 分工？ 。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。 怎么样？以上这些问题是否似曾相识，或者自己是否考虑过？ 如果你的第一反应是去翻开 《软件工程》、RUP 、敏捷开发等相关著作，那么我可以很肯定 的告诉你你会失望的，就像前面提到的，这些东 不是管理流程的事情，而是技术流程的事 情。 如果你心有疑问，或者不敢肯定自己的答案，那么“不懂的人有福了”，因为我将通过几篇 短的博文和一个实例来简明概要的讲述这个流程，概要的讲，主流程如下： 用例模型-领域模型-设计模型-实现模型-进程模型-部署模型 实例就用一个简单的POS 机系统来讲解，欲知详情如何，且听下 分解！ 用例模型 一般的管理流程都将软件项目划分为 “需求-分析-设计-实现-维护”，对应的技术流程 中首先也肯定是要将需求明确，而 “用例模型”就是用于获得和分析需求的。 简单来说，用例模型就是要将客户的需求写下来。“需求”不是很好理解，更加通俗的讲法 是 “故事(story) ”。我觉得 “故事”这个词非常好，非常形象，非常容易理解！我们看看为 什么“故事”更加容易适合说明客户要求： （1）故事中有很多角色，而需求中也有很多角色； （2 ）故事有具体的经过，有开始、进行、结束；而需求也是一个完整的流程，有输入、处 理、输出。 （3 ）故事必须有意义，而需求对客户来说，也是必须有意义的； 具体的用例格式等这里就不详细描述了，大家上网搜索一下就知道了，如何更好的把握需求 可以参考我的博文 《需求分析的故事——如何练就需求分析的火眼金晴？》，下面我把用例 模型阶段容易犯的错误重点说明一下。 1）“需求”和 “功能”混 很多朋友在分析需求的时候，将 “功能”和 “需求”混淆起来，导致了需求的粒度不合理， 或者把握不住重点的需求，我总结出一个很简单的区分办法：“需求是对客户有价值的东 ， 功能是为了实现需求而作的东 ”。 以POS 机为例：对于客户来说，“买单”是一个有价值的东 ，因为客户买完单就可以把商 品拿走了；而买单过程中的“读商品条形码”、“计算商品总额”、“打印购物清单”等都是功 能，因为它们当中任何一个独立的功能对客户没有价值 （你不会跑到超市 “读商品条形码” 玩吧:-P ），只是为了实现 “买单”而做的。 2 ）在用例模型阶段进行系统分解 除了容易将 “功能”和“需求”混淆外，用例模型阶段还有一个常见的错误就是在用例模型 阶段对系统进行分解。 以POS 机为例，有的人将需求描写为：扫描机扫描商品条形码信息，然后将信息发给库存 系统，库存系统返 详细的商品信息给交易系统……在用例模型阶段这样做是不对的，因为 这样转移了我们的注意力：从关注用户需求转到了系统分析了。 记住：用例模型关注的是用户需求，不需要进行系统分解，把系统当做一个黑盒看待就可以 了。 下面我们给出POS 机一个简单的用例片段，有兴趣的可以自己写一个完整的 （这个完整的 可不简单哦，至少可以写3 页）： 1）顾客携带商品到收银台； 2 ）收银员扫描商品条形码； 3 ）系统根据条形码获取并显示商品信息； 4 ）收银员重复2~3 步，直到所有商品扫描完毕； 5 ）系统计算商品总额； 。。。。。。。。。。。。。。。。。。。。 n ）