OOA/D的统一构建(UP)过程之一：需求分析阶段USE CASE
在OOA/D的开发过程中有很多种，比如：up，xp,scrum,dsdm等，不管是那一种都要将项目分解成为一系列的子项目，每次的子项目就是一次迭代，在每次的迭代中对前一次的迭代进行refactory。以前曾经看过Craig Larman的一篇关于OOA/D的文章，里面对开发过程的描述令我获益匪浅，尤其是在实践中的体会更能让人有所启发。作者在对很多应用xp项目的了解中发现，当前没有任何一个成功案例，只是见到很多人宣称正在应用xp。作者的建议是采用更加轻量敏捷的UP方法。
UP的特点是：迭代开发，TDD（test driven develop），pair programing等等。但是在实践中应该如何操作呢？这就是这篇文章所要讲述的一个UP构建过程。在整个构建过程中会始终贯穿Refactory和Iteration，这也是Up的精华。这是本人在实践中的应用过程，当然也不是十全十美，希望能在讨论中更加完善。
图A:UP的不同阶段
ASPectratio="t">
S:表示开始(START)
R表示优化(REFINE)
备注：每次的Iteration周期应该保持在10~15天之内，必须要保证deadline<clk></clk>。如果发现无法按时完成计划，可以删简一些<nobr oncontextmenu="return false;" id="key3" onmousemove="kwM(5);" onmouseover="kwE(event,5, this);" onclick="return kwC(event,5);" target="_blank" onmouseout="kwL(event, this);" style="COLOR: #6600ff; BORDER-BOTTOM: #6600ff 1px dotted; BACKGROUND-COLOR: transparent; TEXT-DECORATION: underline">需求</nobr>，以保证能按时获得一个比较稳定的版本。两次迭代的间隙中要保留充分的讨论review时间，以确定当前阶段大约还需要几次迭代，安排即将开始迭代的plan（包括refactory）。
一、
需求分析阶段
需求分析阶段当然离不开USE CASE。在UML中有一个USE CASE DIAGRAM，这在整个UP中的地位不是很高（这要看USE CASE和SUB USE CASE<clk></clk>的数量和<nobr oncontextmenu="return false;" id="key2" onmousemove="kwM(3);" onmouseover="kwE(event,3, this);" onclick="return kwC(event,3);" target="_blank" onmouseout="kwL(event, this);" style="COLOR: #6600ff; BORDER-BOTTOM: #6600ff 1px dotted; BACKGROUND-COLOR: transparent; TEXT-DECORATION: underline">系统</nobr>的复杂度），至少在当前阶段是不重要的。USE CASE DIAGRAM的用处在于可以很清晰的描述： USE CASE之间的关联；系统的整体架构，后面会有详细的描述。更重要的是 USE CASE，它是文字的描述，是对整个系统的需求分析。
1
．1
、抽象USE CASE
指导原则：(FURPS+)
：
1.
Functional（功能性）: 特征, 能力, 安全
2.
Usability（可用性）: 人为因素, 帮助, 文档
3.
Reliability（可靠性）: 失败频率, 可恢复的能力, 可预见的能力
4.
Performance（执行性能）: 响应时间, 吞吐能力, 准确性, 实用性, 资源的使用
5.
Supportability（支持方面）: 适应能力, 可维护的能力, 配置能力;
+ 实现方面,接口方面,运行方面,打包方面
书写USE CASE要在以上的原则下考虑，当然面面俱到是不可能的，不要忘了我们还有REFACTORY和Iteration这两个利器。
1
．2
、
基本业务处理过程(EBP
： Elementary Business Process)
：
A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.
很简单吧，USE CASE就是像上面的描述那样开始书写的。
1
．3
、USE CASE
的使用者：
不同的USE CASE是针对不同的使用者的，在实际的应用中经常会犯过粗和过细的毛病。USE CASE不是万能的，不要指望通过USE CASE可以将所有的事情都说清楚。
比方说在CRM<clk></clk>应用中，某企业的客户经理关心的是如何提高响应度和客户满意度，提高销售额等方面；而对于财务经理关心的是财务电算化提高的<nobr oncontextmenu="return false;" id="key1" onmousemove="kwM(0);" onmouseover="kwE(event,0, this);" onclick="return kwC(event,0);" target="_blank" onmouseout="kwL(event, this);" style="COLOR: #6600ff; BORDER-BOTTOM: #6600ff 1px dotted; BACKGROUND-COLOR: transparent; TEXT-DECORATION: underline">工作</nobr>效率，关心财务数据的安全性等；对于IT经理关心的是如何实施，软
硬件的性能；对于总经理可能关心的只是投入产出比。
因此对以上人员的需求描述是要分层次的，从高往低是：
河蚌过于详细，不属于USE CASE的内容，如果在USE CASE中出现了thread,socket等词汇时，就是写的过于详细了，因为这应该在Domain model以后才应该出现。因此USE CASE仅仅包括sea level 和fish level。而总经理最多只会看到Cloud level 和kite level。甲方CRM实施小组人员、需求分析人员（SA<clk></clk>）、系统<nobr oncontextmenu="return false;" id="key4" onmousemove="kwM(7);" onmouseover="kwE(event,7, this);" onclick="return kwC(event,7);" target="_blank" onmouseout="kwL(event, this);" style="COLOR: #6600ff; BORDER-BOTTOM: #6600ff 1px dotted; BACKGROUND-COLOR: transparent; TEXT-DECORATION: underline">设计</nobr>人员(SD)、PROGRAMER才是USE CASE的真正使用者。
千万要注意项目是在多次的Refactory和Iteration中完成的，不可能在一次的构建过程中将项目完成，否则那就不是UP而是Waterfall<clk></clk>了，项目组的成员将会在客户需求的不断变化、技术风险、时间风险中饱受折磨，最终的<nobr oncontextmenu="return false;" id="key0" onmousemove="kwM(8);" onmouseover="kwE(event,8, this);" onclick="return kwC(event,8);" target="_blank" onmouseout="kwL(event, this);" style="COLOR: #6600ff; BORDER-BOTTOM: #6600ff 1px dotted; BACKGROUND-COLOR: transparent; TEXT-DECORATION: underline">产品</nobr>必然面目全非，系统架构混乱不堪。
相信谁也无法忘记曾经那牵一发而动全局的感受！