构建App范式，用例驱动开发

    这篇文章是在2014年写得，现在来看有诸多漏洞，但是本着发展的眼光，决定一字不改。

前段时间，确切说是整个11月全程参与了公司在北京的封闭开发，期间有点收获在这里贴出来，相互努力。

做Android两年多了，对java的认识也是与日俱增，这次封闭开发，技术上没有什么难度，重点是对软件工程的一个系统学习过程。这次去北京，我们团队一分为二，一半留下来维护手上的项目，另一半由我带领配合北京产品经理重头来做一个新的项目。

总体来说，用例图如下，这里只是简单举例

        

这次项目希望采用用例驱动来开发，对于用例驱动开发，之前接触过但是没有付诸实践。所谓用例驱动开发，细节大家可以去看“java编程思想第三版”，就是面向对象编程的一种方法论。自从java推广以来，如何去构建一个项目，据此产生了许多方法论，用例驱动开发正是其中一种。其实我们在日常项目开发中都有自己的一套方法而已，有些简单有些复杂，但目的只有一个那就是完成项目。而用例驱动开发简单来说分为以下几个步骤：

1 找用例
2 用例分析
3 程序实现

4 迭代维护

计划入口？

面对一个新的项目，我想任何一个参与者都会有一个初步的计划，如何开展这个项目，这个计划有些可能颇为复杂，有些人认为自己根本不需要什么计划直接实现代码就可以了，其实直接实现代码也是一种计划，这个计划就是这个项目的切入口。

用例分析

有了计划以后，就要对即将开展的项目有个认识，比如这个项目的核心任务是什么，之前做项目，都是拿到产品原型后，部门开会根据产品原型讨论需求，之后就开始写代码了。这样做不是不好，事实上大多数产品就是这么做出来的。但是这样做可能存在几个问题，开发对项目缺少整体的认知，后期不便于版本迭代。用例驱动开发可以有效弥补这些问题，用例开发的第一步找用例，就是针对项目核心任务的思考提问，可以通过UML中的用例图来展开，主要角色有参与者，系统，以及影响者。通过这个过程，大家可以对项目的核心任务有个全局的认识，并且这个过程大家都可以参与其中。找用例不需要前期就找到所有的，事实上这也很难做到，这需要我们把握一个度，找到合适的用例而后就可以进入到下个阶段了。

程序依赖用例

这个阶段我们就可以对每个用例进行分析了，这个分析“java编程思想”作者主张通过CRC(类名-类作用-外围类)卡片使得整个团队参与其中，明确那个类做什么，与其他类如何通信，最终完成用例分析。水到渠成的结果是程序员已经有其详细的类信息了，剩下的只是去实现它。我们这次在北京封闭的方式与其类似，但是没有用到CRC卡，用的还是UML工具，团队分析展开这个实例，通过分析就会产生好几个场景。总的来说用例就是场景的集合而已。这个过程走完以后，我对项目的脉络有了大概的了解，虽然没有去讨论类信息，但是骨架已经定下来了。

类设计，这个阶段实现是在编写代码前实现的，没有用CRC技术，也许这个还不是很系统化，用的方式还是之前的方式，这个需要在后面的学习中补足。实现代码，这个其实没有什么讲的。在这里主要说下这个实现代码，完全是按照用例图去做，条理性很强，而且每个用例是解耦的，便于后期的版本迭代。总之好处是不言自明的。

全程的迭代？

后面的白盒测试以及黑盒测试，基本上都是围绕用例图展开的。从分析设计到开发实现以及后期维护，用例图都贯穿其中。比之前我们所有的构建项目的方法，用例驱动开发有着特有的优势，它可以让参与者深刻的理解项目核心，并在整个过程中指导他们，全程测试不为过！

这次封闭开发，我们的新项目不是很大，也许还没有真正的应用到用例驱动开发的精髓，也许没有发现用例驱动开发的边界所在。但不管怎样，认识它，学习它，我想对我们的日常工作还是非常有帮助的。