UML,OOAD,RUP在实际使用中存在的问题

发表于:2007-04-28来源:作者:点击数: 标签:uml实际ooad中存在的
如果你没听过UML,容我在此做个解释。这三个字就是U Must Learn的缩写,指的就是你一定得学(you must learn),如果有下一句,应该是You Must Pay。这是几个大师级的人物,为了要把学术理论顺利转化成现金,所想出来的好点子。基本的想法是:如果可以弄出一套

如果你没听过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