需求的实践(3)-客户定向,而不是程序定向

需求的实践(3)—客户定向,而不是程序定向需求的实践(3)—客户定向,而不是程序定向需求的实践(3)—客户定向,而不是程序定向资料仅供参考文件编号：2022年4月需求的实践(3)—客户定向,而不是程序定向版本号：A修改号：1页次：1.0审核：批准:发布日期：需求的实践（3）—客户定向，而不是程序定向CustomerOriented，而不是ProgramOriented林星()

2001年10月软件开发人员总是在困惑为什么软件分明是按照需求做出来的，可是客户为什么仍然不满意。客户总是在困惑为什么软件和自己想要的差距会那么大。这究竟是怎么回事如何才能把开发人员和客户之间的沟壑填平本文作为这个关于需求的软件工程专栏的第三篇，将向您介绍这个把客户和开发人员联系在一起的工具――UML（统一建模语言，UnifiedModelingLanguage）。一个软件系统的开发过程说到底就是由客户提出需求，再由开发人员将之翻译成机器能够理解的语言，构建成系统，交付给客户使用。在客户看到软件的时候，客户通常会说一句话："哦，那正是我所说的，但那不是我想要的。"即使是开发人员异常的尽责，花费大量的时间了解客户需求，依然避免不了出现上述的客户抱怨。更何况开发人员通常都想当然的认为自己已经了解了需求，并喜欢按照自己的想法给软件加入一些新特性（feature）。在这样的情况下，用户的"真正"的需求就更加得不到保障了。出现了什么问题因为大部分的软件开发工作都是ProgramOriented，而不是CustomerOriented。开发人员认为自己已经了解了客户的需求；客户表达不出或是表达不全自己的需求；开发人员抱怨客户经常修改需求；客户不明白软件开发为什么有如此多的限制…。所有这些，都是ProgramOriented的软件开发模式避免不了的弊病。归根结底，这些问题都是由于客户和开发人员的立场不同而导致的。所以呢，在客户和开发人员之间，缺少一种东西来把他们联系在一起。因此，众多的方法学，都把这个问题视为重中之重。1.UML

UML（统一建模语言，UnifiedModelingLanguage）是一种面向对象的建模语言。在软件工业化方面做出了杰出的贡献。被OMG（ObjectManagementGroup）采纳为业界标准。UML就是解决上面这个问题的一个相当有代表性的例子。UML的实质，就是一种沟通方法，就象是英语能够解决把世界各地的人交流的问题一样。2.UML起源

公认的面向对象建模语言出现于70年代中期。1989年到1994年是建模语言的战国时期，其数量从不到十种增加到了五十多种。虽然有利于学术的发展，但是对于最终用户来说，了解众多的建模语言是一件非常没有必要的事。在建模语言的战国时期出现了三个强者：GradyBooch，JamesRumbaugh和IvarJacobson（人称"TheThreeAmigos"），以及他们的方法：Booch1993、OOSE和OMT-2。Booch是面向对象方法最早的倡导者之一，他提出了面向对象软件工程的概念。Booch1993比较适合于系统的设计和构造；Rumbaugh提出了面向对象的建模技术（OMT）方法，采用了面向对象的概念，并引入各种独立于语言的表示符。这种方法用对象模型、动态模型、功能模型和用例模型。OMT-2特别适用于分析和描述以数据为中心的信息系统；Jacobson于1994年提出了OOSE方法，其最大特点是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器，但用例贯穿于整个开发过程，包括对系统的测试和验证。OOSE比较适合支持商业工程和需求分析。天下大势，分久必合。GradyBooch，JamesRumbaugh和IvarJacobson三个人的方法各有所长，而用户有希望能够有一种标准出现，结束混乱的百家争鸣的现状。1994年10月，GradyBooch和JimRumbaugh开始致力于这一工作。他们首先将Booch93和OMT-2统一起来，并于1995年10月发布了第一个公开版本，称之为统一方法UM（UnifiedMethod）。1995年秋，OOSE的创始人IvarJacobson加盟到这一工作。经过Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分别发布了两个新的版本，即UML和UML，并将UM重新命名为UML（UnifiedModelingLanguage）。1996年，一些机构将UML作为其商业策略已日趋明显。UML的开发者得到了来自公众的正面反应，并倡议成立了UML成员协会，以完善、加强和促进UML的定义工作。当时的成员有DEC、HP、I-Logix、Itellicorp、IBM、ICONComputing、MCISystemhouse、Microsoft、Oracle、RationalSoftware、TI以及Unisys。这一机构对UML（1997年1月）及UML（1997年11月17日）的定义和发布起了重要的促进作用。UML是集合了众家之长的建模语言，从诞生的那一天开始，就经过了不断的验证和修改，它着重强调的是一种标准的建模思想，但它并不是一种标准建模过程，对于不同的软件企业来说，建模的过程是不同的。UML并没有特定的平台，与具体的实现无关。它是一种图形化的面向对象建模语言。UML通过不同的图形表示来捕捉系统静态结构和动态行为的信息，建立起对象模型。不同的图形是从不同的角度来看待系统。由于UML的独立性，所以它可以通过专用的工具转化成具体的编程语言，或是从编程语言代码转回UML，这叫做"逆向工程"。3.UML是什么

UML的概念包括了UML语义（Semantics）和UML表示符（Notation）两个部分，UML语义定义了结构（Structural）模型和行为（Behavioral）模型。结构模型（又称为静态模型）强调系统的对象结构，如对象的类（Classes）、接口（Interfaces）、属性（Attributes）和关系（Relations）；行为模型（动态模型）关注的是系统对象的行为动作，如对象的方法（Methods）、交互（Interactions）、协作（Collaborations）和状态（StateHistories）。以此为基础，UML为UML表示符提供了完整的语义定义。UML的表示符包括了下面的几种主要的图：类图（ClassDiagram），用例图（UseCaseDiagram），顺序图（SequenceDiagram），协作图（CollaborationDiagram），状态图（StateDiagram），活动图（ActivityDiagram），部署图（DeploymentDiagram）语义由于我们的讨论重点并不是UML语言，我们只是简单的介绍UML的实际应用，如果大家对UML有兴趣，可以参看《白皮书》。4.用例图和用例

用例图（UseCaseDiagram）是UML中最简单也是最复杂的一种图。说它简单，是因为采用了面向对象的思想，又是基于用户视角的，绘制非常容易，简单的图形表示让人一看就懂。说它复杂是因为用例图往往不容易控制，要么过于复杂，要么过于简单。一个系统的用例图太泛不行，太精不行，太多不行，太少也不行。用例的控制可以算是一门艺术。突然想起当年我刚刚接触UML的时候，对用例不屑一顾，认为是UML中最无用的一种图，现在每每想到不禁感慨自己的愚蠢。Usecasediagramsshowactorsandusecasestogetherwiththeirrelationships.『OMG-UML』用例图表示了角色和用例以及它们之间的关系。Ausecaseisakindofclassifierrepresentingacoherentunitoffunctionalityprovidedbyasystem,asubsystem,oraclassasmanifestedbysequencesofmessagesexchangedamongthesystemandoneormoreoutsideinteractors(calledactors)togetherwithactionsperformedbythesystem.『OMG-UML』用例描述了系统，子系统和类的一致的功能集合，表现为系统和一个或多个外部交互者（角色）的消息交互动作序列。有点复杂是吗，就是角色（用户或外部系统）和系统（要设计的系统）的一个交互，为了实现一个目的（Goal），这个目的的描述通常是一个谓词短语，例如，开立信用证，给客户回单等。用例图则图形化的表示了这种关系。一个具体的用例图可能是这样的：5.用例和需求，用例和过程

可以说，之前说的所有的东西都是为了能够导出用例在需求中的作用。用例是从用户的角度看待系统，而不是基于程序员的角度。这样的话，用例驱动的系统能够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整的体现。用户和程序员间通过用例沟通，避免了牛头马嘴的尴尬局面。从前，系统开发者总是通过情节来获取需求，是问用户希望系统为他做什么。在可爱的Jacobson发明了用例的概念之后，需求获取就变成问用户要利用系统做什么。这是立场不同导致的结果。用户通常并不关心系统是如何实现的（也有少数可爱的技术狂是例外）。对他们来说，更重要的是要达到他的目的。相反的，大部分的程序员的工作习惯就是考虑计算机应该如何实现用户的要求。所幸的是，用例方法能够调和双方的矛盾，因为虽然用例是来源于用户，服务于用户，但是它同样可以用于开发的流程。当系统的开发过程都是基于用例的，用用例获取需求，用用例设计，用用例编码，用用例测试的时候。这个开发过程就是用例驱动的。在具体的需求过程中，有大的用例（业务用例），也有小的用例。主要是由于用例的范围决定的。用例像是一个黑盒，它没有包括任何和实现有关或是内部的一些信息。它很容易就被用户（也包括开发者）所理解（简单的谓词短语）。如果用例不足以表达足够的信息来支持系统的开发，就有必要把用例黑盒打开，审视其内部的结构，找出黑盒内部的Actor和UseCase。就这样通过不断的打开黑盒，分析黑盒，再打开新的黑盒。直到整个系统可以被清晰的了解为止。用例是重要的，用例图只是用例的表达方式，其实用例的表达不仅仅是用例图，还有很多方式，我们在下面会具体讲到。6.使用用例的误区

上面曾经花了一些篇幅来说明用例的简单和复杂的关系。在很多介绍UML的书中都会首先介绍用例图，并会用一些近乎完美的例子来说明用例图。可是在实际的使用过程中，都会有很多实际的问题。我咨询过很多使用UML的朋友，发现或多或少都存在问题。用例的发明者IvarJacobson曾经说过，Ericsson花掉了上千万元去研究建立UseCase模式的过程(process)﹐现在他任职的Rational公司也花掉不少钱研究开发过程的问题。大师花了数十年心血建立起来的理论体系并不是那么容易的。用例决不仅仅是定义Actor、UseCase、Association那么简单。用例需要在很多的细节方面都做足功夫。我曾经看过一个软件企业推行UseCase图，但是在花费心血画出了几十张项目的用例图后，设计编码阶段却回到了从前的开发流程。用例的使用绝不仅仅是画用例图，用例也不是软件团体一步登天的捷径。用例贵在思想，在软件团体中引入用例并能够和团体很好的融合，是一个渐进的过程。因为在软件工程领域应用用例思想涉及到的内容方方面面。即使是用例图的编号也是大有讲究。对于一个没有OO实践经验的软件团体，从事这样的作业，需要大量的工作，可以说是"百业待举"。如果没有长期的积累和探索，何来用例和软件团体的融合呢7.用例的观点

为什么说用例是有效的呢在软件开发的过程中，大部分问题的产生都是由于沟通的不畅。设计者和用户沟通不畅，设计者和实现者的沟通不畅。软件开发就是踢足球。教练、前锋、中场、后卫各顾各的，相互之间形成断层，怎么能赢球呢上面提到的一些应用OO用例思想失败的例子也表明，如果开发团队有人排斥用例思想的话，项目是不会成功的。用过Rose的人都知道，在Rose的界面中，有四种视图（View）：用例视图（UseCaseView），逻辑视图（LogicalView），组件视图（ComponentView），部署视图（DeploymentView）。这个思路源于Kruchten大师提出来的4＋1的观点模式。其描述了系统开发工作的参与者﹕使用者(endusers)、程序员(programmers)、系统整合师(systemintegrators)、以及系统工程师(systemengineers)等5种人员心中所关切的焦点与看法。为了能够把4种人不同的观点统一起来，Kruchten大师提出了一个情节（Scenarios）观点（这个词翻译的不好，如果有谁有更好的翻译，请更正）。这个观点其实就是用例观点（UseCaseView）。在用例观点的统一下，保证这四种观点能够相互协作，共同营造一种良好的开发氛围，实现软件项目的成功。那么，应该如何营造一种和谐的气氛呢还记得在介绍UML语言的时候我们谈过UML中的几种图吗。这几种图都不是孤立的。在画出一份用例图后，通常都会用顺序图和状态图来规定用例图的规格，这些都是Rose中的用例视图。在用例图中，我们可以分析出基本的类，并将类组织成包，并将其分配到系统的三层结构中，这是Rose中的逻辑视图。在写出基本类之后，我们还可以将类组织成组件（针对特定的架构，如J2EE或COM），这是Rose中的组件视图。把组件部署实现，就是Rose中的部署视图所关心的。（需要指出的是，Rose中的视图与Kruchten大师的4+1观点有些许出入，Rose中的组件视图相当于Kruchten大师的Development观点和Process观点。）（注：这里的View对应的有两种说法：视图和观点。视图是比较正式的说法，但是我觉得在通常得用语中，大多采用观点的说法。所以这里的观点和视图表述的是同一个意思。）这里谈到用例的观点主要是要让大家了解为什么会有用例的产生，以及在软件开发中不同的人看待问题有不同的角度。8.用例的不足

用例的出现虽然能够解决很大一部分问题，但是它并不是万能的。ThefirstisthematterofhowdifficultitistogetaUML-likedesignintoastatethatitcanbehandedovertoprogrammers.TheproblemwithaUML-likedesignisthatitcanlookverygoodonpaper,yetbeseriouslyflawedwhenyouactuallyhavetoprogramthething。（Fowler2001）首先是把像UML那样的设计图交给程序员来实现是一件极为困难的事情。问题的关键在于那种设计看上去不错，可你打算编程来实现它的时候就出现了问题。不但是分析员和程序员之间的沟通存在问题，客户和分析员之间的隔阂更大。客户对于用例的观点仍然不能够接受，这仍然需要开发人员作出不懈的努力来调和这一矛盾。由于软件工程最早提出是根据建筑方面的理论，所以很自然的就会把软件工程和土木工程做一个比较。在土木工程中，设计图和模型制定出来来需要严格的执行。可是：Themodelsthatcivilengineersusearebasedonmanyyearsofpracticethatareenshrinedinengineeringcodes.Furthermorethekeyissues,suchasthewayforcesplayinthedesign,areamenabletomathematicalanalysis.TheonlycheckingwecandoofUML-likediagramsispeerreview.（Fowler2001）土木工程师使用的模型建立在多年实践的基础上，它们用土木工程的专用语言来描述。而且主要的问题在于，通常这种设计需要符合数学原理。而我们对UML之类的图表唯一能做的就是同级检查。看到问题所在了吧。单纯的凭借没有完善理论支撑的设计图就轻率的决定这个软件的设计是及其危险的。不止一次的经验告诉我，一开始写出的用例在项目结束时一看往往会吓一大跳：设计和实现已经完全脱节了。其中主要的代沟有两个：客户和开发人员之间，分析员和程序员之间。我们这里的重点在于客户和开发人员之间的需求部分。需求的问题单单由UML语言来解决是不现实的，且不说国外的软件环境那么好的情况下，客户对于UML仍然不理解。国内的情况要糟糕的多，大多数的客户并没有计算机方面的基础知识，对于他们来说，只有一点："花钱买东西，天经地义。"在这样的观点下，软件的开发过程就很难得到客户的支持。所以这也是国内ERP项目鲜有成功范例的一个重要原因。这时候，讨论的问题已经不是局限在技术层面了，主要的焦点已经转移到了管理、营销、谈判技巧等方面了。UML的成功也是需要这个大前提在的。McConnell建议在一个大的项目中，编码和单元测试的开销占整个项目开销的15%。而其中有很大一部分的时间都会花在BPA（企业流程分析）和BPR（企业流程再造）上面。因为有很多企业在实施电子化之前管理都不规范，以人治为主。对于软件而言，不论其中的设计多么的成功，如果没有各个环节输入的准确来保证，那结果是可想而知的。我的一个朋友开发过一套连锁店管理的软件，可是系统运行以来，会计帐从未平过。其中主要的问题就是各个结点的输入不规范。这种问题已经不是计算机能够解决的了。说到这里，有一个笑话，有一个特定行业的企业要开发一个管理软件，于是我就给企业的负责人分析他的流程，突然他很惊讶的看着我："你是我们这个行业的吗