漫谈UML OOAD and RUP

独孤木专栏之三＞ UML, OOAD and RUP （上）

如果你没听过UML，容我在此做个解释。这三个字就是U Must Learn的缩写，指的就是你一定得学(you must learn)，如果有下一句，应该是You Must Pay。这是几个大师级的人物，为了要把学术理论顺利转化成现金，所想出来的好点子。基本的想法是，如果可以弄出一套理论，让全世界想要学软件开发的人都得要来学习，那他们光卖这套理论的教育训练、认证、顾问咨询、以及难用的开发工具，就可以让公司上市，变成亿万富翁。

开玩笑的。

这是三位对象导向软件工程界的大师(Grady Booch, James Rumbaugh, Ivar Jacobson)，为了济世救人所整合出来的一种模型语言，称为Unified Modeling Language。算是把三个人的东西，切成小块以后煮一煮，放在碗里面用汤匙搅一搅，整合成一个大杂烩…嗯，不是，是把三个人的理论去芜存菁，所整理出来的结果。

UML主要的目的，在于让所有进行系统分析设计的工程师，可以有一个共同的图形化语言，来描述他们所想要建立的系统。至于让公司上市，以及让所有学习UML的工程师，可以有比较显赫的履历表，则算是产品附加价值，不算是主要的目的。

因为这个语言，现在正流行，算是当红炸子鸡，所以许多软件公司，莫不努力地往这个方向发展，期望引进UML，可以为软件开发，带来前所未有的助益。很多人的想法，当然还是围绕着可以做出被重复使用(reuse)的软件组件，以加速系统开发为核心。

吉娜：布鲁斯，老板问我什么是UML？他说他到研讨会里听到，超人公司已经在采用这个东西了，听说有非常好的成果。他觉得我们所有的工程师也应该学习这种新的skill，这到底是什么东西？

布鲁斯：这是几个对象导向分析设计界的大师，所共同建立的新的Modeling Language。

吉娜：Modeling language是什么东西？算了，我不需要知道这些detail。既然老板已经说需要引进这种新的趋势，这就是我们今年的目标。你先找一些人去上课，然后回来我们拿几个项目开始试试这种新的方法。

既然这只是一种语言，其实并没有好坏的问题。这就像中文是否比英文优秀一样，每个人会有不同的看法。只要在使用的时候，它可以发挥它的用处，可以让看到文件的每个人，都很清楚了解你想描述的模型，我觉得它就发挥了这个模型的功用。

然而大师或是大师的徒子徒孙们，不会光把UML这三个字从头到尾念一遍就了事，他们除了介绍这个语言，还会讲其它的理论。这些话，就跟着UML的推广，跟着被信众们奉为圭臬，当作是神谕。例如引进UML的团队，通常会采用Use Case Driven的OOAD(对象导向分析设计)，也通常会想要采用大师建议的开发流程：RUP(Rational Unified Process)，来开发项目。

对很多老板来说，这些东西就跟用来杀狼人的纯银子弹一样，可以让专案所面临的所有问题都顺利解决。所以每次听到一个比较新潮的理论，就会想要叫属下用用这么神奇的理论。而这些东西看起来是这么的有连贯性，从OOA开始进行需求分析，到使用OOD进行系统设计，接着再用OOP来开发程序，在开发过程中，都依循RUP的规范，再使用共同的UML语言。只有依照这样完美的方法，才可以确保整个项目的品质，并且开发出可以被重复使用的软件组件。

老板的思考的确比较单纯，然而不少信徒也吃这一套，于是乎根本就不管三七二十一，直接就狠狠地给他用在项目上，丝毫没有考虑中国社会的特色，应该要先想想师夷之长技以制夷，要尽量中学为体，西学为用才对啊。结果当然是撞的满头包。

还好对于信徒来说，通常他们还可以自我安慰：『美国这么先进的国家都采用这么新颖的方法来开发，跟着世界趋势走，一定不会错。现在的问题，一定是因为我们的人资质太过鲁钝，没有完全依照大师的指示来做。下一次，我们一定要按照大师精辟的理论来开发，一定不会遇到什么问题。』

然后这些信众们，就会继续抱着众人皆醉我独醒的悲壮，继续努力下去。一边做的时候，一边为自己又累积一些OOAD的开发经验而自豪。

当然，我个人也觉得，大师一定不会错，一定是我们资质比较鲁钝，又缺乏经验，所以没有正确地体悟大师的讲法以及采取正确的做法，才会导致这样的结果。只是除了我们比较笨以外，总也要找一些理由，把责任推给大师们，不然铁定会被客户砍头。大师既然要济世救人，就只好请你们抱持着我不入地狱，谁入地狱的决心啰。

所以我会针对我观察到的几个因为采用OOAD，以及RUP在台湾做案子所发生的几个问题，提出我个人的看法。几个我观察到的主要问题如下：

-没有依据项目的特性来选择项目开发方式。

-使用者或者是客户的信息人员，看不懂相关的文件。

-信息人员本身不了解UML, OOAD以及RUP。

-Relational Database

以下我会针对这些问题，进行我个人的看法。

没有依据项目的特性来选择项目开发方式

台湾的软件项目，通常规模都不是很大，除非你将人力外包给企业使用，否则一般的软件项目，价格则多半是在一开始就定下来了，项目进行的过程里，通常没什么机会可以调整金额。

项目成员人数，多半在二十人以下。所以如果你要采用RUP来开发项目，你的第一个问题会是，你凑不到足够的人头，来担任每一个RUP所介绍的角色。

此外，你通常也没有那样的预算，可以让每个角色，都把他们该做的文件都做出来。所以你会省略一些流程。每次有人跑RUP跑的不顺，他们第一个想法就是：『RUP的体系博大精深，这是多少前人智能的结晶，一定是因为我省略了XX步骤，这次才会走的不顺利，下回一定要…』

RUP的另一个问题是，它是iterative的开发方式，也就是说，因为项目一定会有变更需求发生，所以它预期没有办法一次就开发出使用者所要的东西。因此在开发时，会重复来个好几回。每次都会要求使用者提出评估。

这怎么会是个问题呢？实时取得使用者的响应是一件功德无量的事情啊。问题在于台湾的使用者通常都有正职在身，他们多半是利用农闲时进行专案的开发。所以他们的时间非常宝贵，有机会跟你谈一次需求，他就认为这是非常大的恩惠。

在台湾，进行使用者需求访谈，就像在火车站把一个要赶着去搭车的人拦下来进行问卷调查差不多。一开始，他可能还会基于礼貌，填写问卷。当他需要第四次还是第五次回答同一张问卷的话，他会觉得你是否听不懂人类所说的语言，还是存心找他麻烦。如果你开发一个系统，得要使用者评估个好几回的话，God bless you。

就算使用者对你十分仁慈，没有把你轰出去，采用iterative的做法会有的另外一个问题，其实是在于你的系统是一个iteration，一个iteration慢慢调整，逐渐形成的。所以到底什么算是在系统的范围(scope)里面，其实很难界定。所以如果使用者觉得这个iteration的成品，与他原始需求还有距离，你大概都会被迫再多几个iteration。而这几个iteration，是收不到钱的。这跟以前的所谓螺线型的开发方式，在台湾遇到的困难是一样的。客户不会因为你多做了几个循环(cycle)，而多给你钱。然而，你会因为多做了几个cycle，投入超出预期的人力与时间。

事情多做了，可是赚不到钱，这怎么划算呢？要知道，开发项目跟开发产品是不同的。开发项目，就是要在最少的资源之下，提供给客户一个可以接受的烂货。可以花100万就让客户愿意结案，绝对不要花101万，让客户拥有一个比较好用的系统。越好用的东西越难做，出槌的机率也越高，为什么要这样做呢？

除非今天客户是人力外包，花钱买你的人月，去帮他开发。这个时候，当然是尽量选择可以做得长长久久的方式来开发啰。

所以我觉得应该要以项目的特性来选择项目开发方式。大部分的项目，应该用传统的软件生命周期开发方式来开发。  (待续)
 
**使用者或者是客户的信息人员，看不懂相关的文件**

开发项目到底会遇到什么样的客户？其实就像是跟网友见面差不多，还没有看到真人，你永远不知道哪个每天跟你聊天分享心事的超级美女，其实是一个中年男子。就算你运气好，以前已经跟这个使用者接触过，彼此混的很熟，还是有可能会发生变化。

如果以前的项目做得好，这个人有可能升官，所以他就不会做这个专案了；如果以前的项目做得不好，有可能这个人就被列入下次裁员的黑名单里，所以他也不会做这个项目。更不要提有些时候，你是跟一些从来都没有打过交道的人一起开始做一个新的项目。

既然我们在描述的对象是项目，大部分的项目，都是从需求分析开始。使用者便会提出他们的需求，系统分析师听到使用者的需求以后，就会开始把他所收集到的需求写成文件，接着会去跟使用者确认需求是否便是如此。

采用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

无

4.  Preconditions

客户要正确插入卡片，输入正确的密码，通过身分认证，提款机还有足够的钞票在里面。

5.  Postconditions

进入吐钞use case。

6.  Extension Points

无

通常会被找到的遗漏：

1.为什么没有检查金额是否正确？台湾的提款机，只能够输入100的倍数。
  你要领512元是不行的。

2.怎么没有显示要不要换百元钞？

3.怎么没有检查，机器里面的钞票是否足够？有可能没有小面额的钞票啊。

通常不会被找到的遗漏：

1. 跟金资中心如何达成联机的问题。因为这可能被include到另一个use case里面去了。

2. 没有扣除机器的钞票余额档。

3. 吐钞口要开开关关测试是否可以正常吐钱。

4. 如果吐钞成功的话，要扣机器本身的余额档。

5. 如果成功的话，要把客户未登折次数加1。

…因为我没有写过ATM程序，只能随随便便想象可能会有的问题。

我想，用use case开发比较大的问题在于你其实有可能会遗漏掉一些系统该做的事情。在单一use case中，有可能你会有非常多的alternative flow。每个假设，都有可能不成立。所以你得要定义如果这个假设不成立的时候，系统要响应什么。问题在于一般的使用者，他们提出规则的时候，会把预期系统的反应写在旁边。例如，如果系统没钱，就显示没钱错误讯息。

问题是用了use case以后，很多这样的规则，因为你把系统的整个行为模式全部都展开出来，篇幅就会拉的非常长；如果你把共享的部分抽出来，放在include的use case中，user又要交叉比对才可以看到对的东西。当你看到长篇大论的时候，眼睛看的久了，很容易就漏掉该写的东西。除非我先把所有的规则都写下来，整个if then else的决策树也画出来，不然哪记得你应该写25个alternative flow而不是24个？而这里就会变成是user还要花时间去一个一个比对，他们的requirement是否都被use case cover到了。通常使用者会把这个工作交给SA来做，他们再来看结果。因为user通常都很忙，所以SA整理出来的结果他们通常也没有时间详细地walk through。所以该遗漏的东西还是会遗漏。

另外一个问题，则在于有些东西，是刚好介于use case与use case之间。因此他会预期在use case A中发现的东西，他没看到，他就会觉得可能是写在use case B之中吧。当他去看use case B的时候，他还是没看到，这时候他不见得会记得，他还想看到什么。因为我们在review文件时，通常都只会看到这份文件描述的scenario对不对，比较少去想到底缺了什么。

所以有时候一少，就是少掉一整组use case。例如关于一些系统在运转时会用到的参数档，应该要有如何去维护这些参数的use case。这就常常被user忽略掉。这在采用传统结构化分析画DFD(数据流程图)的世界里，是不太可能发生的，因为每个data，都要描述它是怎么样去maintain，或是怎么样进入系统中。资料不是来自其它系统，就是来自使用者的输入，或是系统本身运算出来的结果。透过DFD，资料的流向与加工会非常清楚。然而使用use case就没有这个好处。我觉得遗漏是OOA的天性，难怪得要配合iterative的process。

特别强调要用这样的方法，另外还会衍生出来的问题是，有些客户因为看不懂这些文件，所以会坚持以他们所提供的文件当作是系统的范围。这通常就会产生非常多的事端。

客户使用者甲：布鲁斯，你们写的这个use case我们研究了很久，我们看不懂。这样我们不敢在这份文件上签名。

布鲁斯：你们看不懂，我可以随时来解释啊。你们一定要在这份需求文件上签名啦。我们一定要有一个基准，不然以后发生问题怎么办？

客户信息部门人员乙(帮忙打圆场)：布鲁斯，我知道use case这个东西是最新的方法论。可是我们的user就是水准还没有到这边。

客户使用者甲：其实系统的范围，我们一直都写得很清楚啊。我上次寄给你的power point文件就把系统的功能都写的很清楚了。

布鲁斯心想，狗屎，这么不详细的东西也可以拿来算数的喔？：我是觉得那份power point文件是已经把系统的功能大方向都点出来了啦，可是还是有很多细微的地方没有提到。(这应该算是一次成功的防御。)

客户信息部门人员乙(帮忙打圆场)：不然，我们请user把他们的想法写的更明确好了，我想可能要把他们的作业流程跟需求写的更清楚一点。

客户使用者甲：好吧，我把以前提供给你们的规则写的更清楚一点，再加上我们以前的会议记录，就是我们系统应该达成的范围。

布鲁斯  ：这样不行啦。我们的人都是base on我们这份use case来开发呢？

客户使用者甲：好啦，我辛苦一点，我尽量把你的use case看一看，挑挑看有没有问题。可是你在今天的会议记录上要写清楚喔，系统的功能应该以我以前提供给你们的规则为基准，再加上我们以前的会议记录，就是我们系统应该达成的范围。至于你们的use case，我是不会签名的。

布鲁斯想，看来要他们确认是很难的啦：好吧，那就只好辛苦你了。你需要多久的时间？…

过了几个月，使用者看到头一个版本后，双方再度开会。

客户使用者甲：我们在文件里面提到的功能，你们都没有做到。

布鲁斯      ：那是因为你在review use case时，也没有提出这一点啊。 这样啦，我们在下一个iteration把它纳进来。我会回头改过use case，再让你double check一次。

客户使用者甲：好吧。希望下一个版本就可以看得到。

过了几个月，已经把原有预计要走的几个iteration全部都走完了，功能还是不如预期，所以双方再度开会。

客户使用者甲：我们已经看过多少个版本了，你们一直到这版，都还是问题百出。你们到底有没有认真去看过我们所提供的文件啊？

布鲁斯：我记得上次我们已经应你们的要求，把requirement跟use case的对应都做成excel，一条规则一条规则让你们确认了，你们还是没有确认出来，还提出这么多change request。我不管，这些我们得要收费。

客户使用者甲：收钱？你翻翻我们7/5的会议记录。虽然在我们原始文件提出的规则里面没有描述到这条规则，可是我们在会议记录里面有提到这个功能需要检查员工到职不满一年，不适用这个状况啊。这是我们在去年6月底检讨作业办法时修订的啊。

布鲁斯：这应该算是change request。况且你们review use case已经review那么多次了。我记得我们在12/14的会议里面有提到，凡是没有列在use case里面的需求，都应该算是change request。

客户使用者甲：那是你单方面的想法，谁同意啊？况且你们改过那么多次版本，我们哪有能力去看你每个版本，记得你每个版本里面到底写什么？我都跟你说我们看不懂use case了，是你说你们的人一定要看，其他的文件看不懂，才帮你检查的。现在问题就都在我身上？

布鲁斯：话不是这样讲…

过了不晓得又多少个iteration…

客户使用者甲：我下个礼拜要调到BOS部门去了。

布鲁斯：那我们怎么办？

客户使用者甲：我还在我们公司啊。新的承办人不错啦，我会有空多帮他的忙。

过了一个礼拜…

客户使用者丙：这个use case是什么东西啊？

布鲁斯：……

信息人员本身不了解UML, OOAD以及RUP

其实客户不了解UML, OOAD以及RUP是很正常的事情。我除了在看新人的履历表，可以找到精通UML，熟悉OOAD，以及专精RUP的人以外，在现实生活中，大概只有在Rational这家公司出来的顾问中，才找得到自认为他非常熟悉这些东西的人。

大部分听过这些term自认了解的人其实都一知半解。(这不包括我，我是根本不了解。)可是最怕的就是不懂装懂。如果你遇到客户的信息人员不了解这些东西，却在上完短期的课程后，想要给你来些良心的建议，还是卓越的指导，你就完了。

客户IT人员甲：我觉得你这个图这里画错了。这个关系，应该用实心的菱形？

布鲁斯：你误会我们想要描述的关系，其实我们在图上并没有刻意去…

过了半小时…

客户IT人员甲：我觉得你这个use case这里用『当使用者输入email后，系统应检查email正确性。』这样写不够清楚，你应该还要描述email格式有错时的alternative flow。不然programmer怎么会知道，系统要怎么响应？

布鲁斯：我们针对这些问题…

过了一小时…

客户IT人员甲：你的文件我们看得差不多了，现在我们来看RUP的artifact…

布鲁斯心想，杀了我吧，这种无聊的会还要开多久啊…

我遇过最狠的，是在use case的叙述里面挑语句是否通顺。原则上呢，就是在改作文。如果你用英文写，就是抓你第三人称是否记得加s之类的问题；如果你用中文写，就是嫌你作文写得太差。

随笔提到另一个更狠的客户，这位小姐的挑错就跟use case没啥关系。她只是强调我们用html做成的prototyping上面所有error message的标点符号，要统一变成全角中文。这样error message才不会有的比较宽，有的比较窄。尽管我们再三解释prototyping的用途不在于此，她还是坚持要我们把所有的标点符号换成全角，她才愿意继续review下去。我们换了好几次，每次只要一有漏掉，就会被她抱怨，我们低下的作业品质，似乎为她想要找人出气的生活，带来不少乐趣与练功的靶子。

我年少蒙懂时，遇过另一个活生生的例子。

客户IT人员甲：为什么你们在use case里面没有描述，可以在class diagram里面设计出这个class？这分明是你们分析与设计不连贯。

我：use case与class diagram没有一对一的关系啊。

客户IT人员甲心想，你分明是在狡辩：你们没有遵照RUP来开发程序…

后来经过我引经据典，舌战群儒，终于赢得了这场辩论。比较年少无知的我，以为在辩论上获得胜利，应该获得英雄式的肯定，客户应该要跪拜在真理面前向我膜拜。

后来才发现，我自己需要接受卡内基训练。因为从我在辩论中获胜开始，就种下了一个超级不好的因，让我在后来做这个案子的时候，吃尽了苦头。对于大多数讲求思辩方法的人来说，科学是冰冷的事实；可是对于凡人，通常也就是客户来说，你把我惹毛了，我会让你的日子很难过。所以从我开始说明真理的那一天开始，这些被我惹毛的信徒们，就继续用不符合逻辑的言论，不断地折磨我们。

对信徒来说，要先做OO的analysis才能进行OO的design，有了OO的design
，才可以找出design pattern，才可以建立可以被reuse的component。这几乎是跟先有鸡，才会有蛋一样真实；只是对我来说，我们现在所谓的OOA跟OOD之间的关系，比较像是狗跟蛋之间的关系。明明就是两个不相同的物种，怎么会有什么关系呢？我记得我小时候学习OOP时，class都是从天上掉下来的礼物，跟use case driven的OOA中间有什么直接的关系呢？在我的那个年代，只要你有眼睛，学过data structure与algorithm，观察现象，就可以想出class出来。只是这种好日子已经过去了。

做苦工做久了，就会想要偷懒，就把共享的东西拉出来。偷懒是所有程式设计师设计出超强component的原动力之一。又懒惰又聪明的人，才会想出一些把戏，让他可以出一张嘴，就叫计算机自己把程序写好。这就是reuse的由来啊。

我认识不少超强的程序设计师，开发共享组件的驱动力在于让他有时间，可以用上班的时间去逛色情网站，还可以在规定的时间内，把该做的事情做完。通常逛色情网站只对男性有诱因，女性总有比较重要的事情要做，例如减肥。所以这些我所认识的超人，清一色都是好色的男性。
这些好色的高手，最喜欢做的事情，当然就是写程序去把所有色情网站的内容抓回家，然后与同好共赏。我个人觉得软件工业有蛮多进步，就在于设立色情网站的人，与好色的超强程序设计师之间相互斗法，所激荡出来的。

认识这些好色的强人以后，我就觉得OOA、OOD跟可以被reuse的component
之间，根本一点因果关系都没有。难道他们是在逛色情网站的时候，在脑袋里面同时多任务去写use case吗？还是同时多任务去画sequence diagram吗？有谁在看着小泽圆、饭岛爱跟白石瞳时，可以同时想这些东西呢？

除了客户不了解UML，OOAD跟RUP以外，另外一个更糟糕的现象就是Project  team里面的人也不懂。我预期这种情况，会随着学校教育洗脑的成功而改善。有些小朋友从来都没听过也没画过DFD，就跟我们拿建构式数学去荼毒下一代是一样的道理。教导比较年轻的一代采用比较笨的方法，可以确保老人的竞争力。

在我刚开始接触UML的这几年，遇到的现象是project team自己都看不懂这些东西是什么。于是彼此之间都在摸索。有经验的老鸟，对于UML，OOAD一点概念也没有。可是被逼上梁山，一定得要用，所以就用自己的经验胡乱使用。没经验的菜鸟，虽然懂得UML，可是缺乏process的实践经验，也不懂任何domain knowledge，所以只能任人宰割。

问题是当菜鸟发现老鸟画出来的图，还是写出来的文件不怎么样的时候，除了要面对年轻人因为梦想幻灭而心生怨怼以外，还得要面对老鸟漫长的学习曲线。通常在这种情况之下呢，会面临成员间永不停止的争辩，大多数都是引经据典关于正统的辩论，无形之中，耗费了相当多开发的时间。

接着就看到原先预设的schedule，像是自由落体一样坠落。每次遇到这种场景，就让我不禁怀念起那个使用结构化分析的年代。一切都是那么简单、直觉与美好。没办法，每个时代都有属于它自己的流行。就像是关系型数据库一样。

Relational Database

尽管OO的声音喊的震天响，Relational database(关系型数据库)还是在IT产业中扮演一个非常重要的角色。很多人一直在想，要用支持OO的database。问题是在这个业界里，有太多人熟悉SQL以及relational database。有太多钱花在买Oracle, Sybase, db2, Informix, MS SQL Server上。这让人relational database退休的机会变得非常小。而relational database的基本精神，跟OO就不太有关了。这让我们想要用Object的方式来思考，遇到RDBMS，就O不下去了。你可以想象一个从悬崖边大声喊着O，然后跳下去的人，当你听到声音越来越小，着地之前那个低沉的o(已经变成小写了喔)，这跟你用OO的观念遇到Relational Database差不多。这个无聊的比喻虽然没什么用，可是又让我多赚几个字的稿费。

有些人是用object的观念，把table包起来。然而，在performance不好时，SQL statement还是会直接写在程序里，真要没办法，还要写stored procedure
。如果已经到了要写stored procedure这样子的阶段，还有什么OOD可以对应呢？还有什么object可以用呢？

这个业界有太多熟悉SQL的programmer。对于这些人来说，SQL的威力这么强大，要去抗拒直接使用SQL statement的诱惑，改用纯粹以Object的观点来解问题，手会变得很痒。遇到有些很容易透过SQL解决的问题时，心会变得更痒。根据研究男性心里的医学报告指出(在此再次感谢灵犬莱西的显灵)，忍耐太久是会生病的。所以只要他们一忍不住出手，通常performance就会有钜幅的改善。只是这就跟OO没啥关系了。不过，这对于所有audit这个项目的人来说，这算是瑕不掩瑜。睁一只眼，闭一只眼也就过去了。Project可以结案最重要，谁还管OOAD啊？这多少也算是OOAD面临的问题之一吧。

**结语**

念过大学，准备过考试的人都知道，文不如表，表不如图。要描述你的观念，用一张适当的图形来表示是最强而有力，也是最容易让人理解的途径。然而为什么在系统分析的这个领域里，我们会希望透过use case来描述这个系统，而不是透过其它的方法呢？

如果你采用结构化分析(Structure Analysis)的方法，而你做的项目规模也比较小，其实使用者会有能力画出他们的作业流程图。有了流程图，其实拿给development team看，大概也知道要做什么了。认真一点的使用者还可以帮你确认你的DFD(data flow diagram数据流程图)。

画出DFD以后，就可以让系统的范围用一个图形化的方法加以确认。也可以认清Data与process之间的关系与流向，接着只要依据资料的流向，写出function spec，再定义出data dictionary，大部分的SA工作就已经完成了。只剩下如何跟客户确认需求了。

如果你又采用了RAD(快速应用程序开发rapid application development)的工具，你就可以迅速地建立起系统的雏形(prototype)。透过雏形的展示，以及function spec，在大部分的项目中，你可以跟使用者建立起一个共识的基础。系统的范围就可以随之确定下来。

一旦SA有了共识，要求使用者确认相关的文件，接着采用传统的瀑布式开发方式(SDLC, System Development Life Cycle)来开发系统。当你遇到需求变更的时候，透过SA文件的确认，双方也就可以在一套沟通与讨论的基础上继续下去。

接着你再去采用OOD的方法来设计系统，用OOP(Object Oriented Programming)
的方式来开发系统，这不是很好吗？

还有人喜欢写use case吗？或许在超大型的项目，例如要一百万个人做个数百年，有个几万个iteration的项目里，写use case就会是一件很有意义的事情。我想当年盖大金字塔的建筑师，一定写过use case。

至于RUP，我个人觉得如果仔细研究RUP，会对于大型项目开发的流程有很清楚的了解。至于对于中小型项目来说，在你进行项目管理的时候，你可以从RUP里面找到许多可以参考的模板。

只是iterative的开发方式，不怎么适用在台湾社会中。尤其是与大多数的项目互斥。如果你是开发自有产品，或许可以考虑采用这样的方式。不过我可不是开发产品的专家。出了问题，除了『你资质比较鲁钝，又缺乏经验，所以没有正确地体悟大师的讲法以及采取正确的做法，才会导致这样的结果…』之外，我可是没有其它比较好的理由喔。  (完)