UML，OOAD，RUP在实际使用存在的问题（转录）

<script language="JavaScript" src="../../js/adjs/adtxt1.js" type="text/javascript"> </script> 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的倍数。