独孤木专栏独孤木专栏:漫谈漫谈UMLOOADandRUP（下）（下）
**使用者或者是客户的信息人员，看不懂相关的文件使用者或者是客户的信息人员，看不懂相关的文件**
开发项目到底会遇到什么样的客户？其实就像是跟网友见面差不多，还没有看到真人，你永远不知道哪个每天跟你聊天分享心事的
超级美女，其实是一个中年男子。就算你运气好，以前已经跟这个使用者接触过，彼此混的很熟，还是有可能会发生变化。
如果以前的项目做得好，这个人有可能升官，所以他就不会做这个专案了；如果以前的项目做得不好，有可能这个人就被列入下次
裁员的黑名单里，所以他也不会做这个项目。更不要提有些时候，你是跟一些从来都没有打过交道的人一起开始做一个新的项目。
既然我们在描述的对象是项目，大部分的项目，都是从需求分析开始。使用者便会提出他们的需求，系统分析师听到使用者的需求
以后，就会开始把他所收集到的需求写成文件，接着会去跟使用者确认需求是否便是如此。
采用use case driven的OOA(object oriented analysis)，你会请使用者确认的文件，当然就是use case。
接着你会依据use case，开始进行OOD(object oriented design)。当你画好sequence diagram, class diagram，你可能会希望客户
的信息人员，可以帮忙确认，这些文件所描述的系统，是否正确。
问题是，大部分的使用者，以及客户的信息人员，其实并没有足够的能力，来确认这些文件的正确性与完整性。因为你所提供的文
件，他们看不懂。通常需要你的带领，才看得懂。当他们需要靠你解释才看得懂时，这时候通常会有一些问题随之产生。他们通常
可以挑出专业领域上的错误，可是他们通常会忽略掉整个系统的完整性。因为他们会觉得，你所没有描述的东西，可能写在另外的
文件中。所以如果你提供的文件有错，通常是你所提供的文件可能不完整，其实要到蛮后期的时候才会发现。这时候修改的成本就
会变得非常高了。
为什么采用use case来描述一个系统，通常会发生遗漏呢？或许我们应该先看看use case是什么。
根据我的一知半解呢，use case就是尝试着用文字来描述系统与外界之间的交互作用。对于没有看过use case的人来说，我在此举
一个例子来说明。书上最常看到的例子呢，就是一个人用提款机在领钱。虽然我没有写过类似的程序，我可以想象一下，这个use
case应该包含的内容。
1.Brief Description
这个use case说明，怎么样透过提款机来领钱。
2.Flow of Events
这个use case，开始于客户把卡片插入提款机后，完成身分认证，并且已经选择要提款。
2.1 Basic Flow
1. 客户输入要领取的金额。
2. 系统检查客户的金额与次数，是否超过系统中所定义每次提领金额与提领次数的上限。
3. 系统从客户的存款余额文件中扣去存款金额的资料。并产生一笔提领纪录在客户的交易文件中。
4. 如果是跨行客户，系统应该产生一笔扣除手续费的资料到信息交换中心。并且更新本行对于清算中心的应收帐款--手续费资料。
5. 进入吐钞use case。
2.2 Alternative Flows
2.2.1 超过每次允许的提领金额
1. 如果超过每次允许的金额，系统应显示错误讯息：『你不识字吗？ 一次只能领两万！』。
2. 系统应该回到功能选择画面。
3. 回到功能选择use case。
2.2.2 超过提领次数
1. 如果超过提领次数，系统应显示错误讯息：『你这张卡片已经刷爆了！ 赶快去补刷存折吧！』。
2. 系统应该回到功能选择画面。
3. 回到功能选择use case。
2.2.3 客户选择取消
1. 如果客户在输入金额时，没有按下确定，却是按下取消，系统应显示 错误讯息：『不要玩我！快滚吧！』。
2. 系统应该把卡片吐出来。
3. 回到吐卡片use case。
3. Special Requirements
无
资源评论
weixin_38607026
- 粉丝: 9
- 资源: 914
