UML OOAD and RUP （上）

独孤木专栏:UML OOAD and RUP （上）

(2003.05.29)

独孤木专栏之三＞ 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万，让客户拥有一个比较好用的系统。越好用的东西越难做，出槌的机率也越高，为什么要这样做呢？ 除非今天客户是人力外包，花钱买你的人月，去帮他开发。这个时候，当然是尽量选择可以做得长长久久的方式来开发啰。 所以我觉得应该要以项目的特性来选择项目开发方式。大部分的项目，应该用传统的软件生命周期开发方式来开发。  (待续)