UML，OOAD，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的倍数。（待续）

原文转自：http://www.ltesting.net