需求的实践—客户定向,而不是程序定向

1、需求的实践(3)客户定向，而不是程序定向Customer Oriented，而不是 Program Oriented林星( )2001年10月软件开发人员总是在困惑为什么软件分明是按照需求做岀来的，可是客户为什么仍然不满意。客户总是在 困惑为什么软件和自己想要的差距会那么大。这究竟是怎么回事？如何才能把开发人员和客户之间的沟壑 填平？本文作为这个关于需求的软件工程专栏的第三篇，将向您介绍这个把客户和开发人员联系在一起的 工具 UML (统一建模语言，Unified Modeling Language )。一个软件系统的开发过程说到底就是由客户提岀需求，再由开发人员

2、将之翻译成机器能够理解的语言，构建成系统，交付给客户使用|。在客户看到软件的时候，客户通常会说一句话:“哦，那正是我所说的，但那不是我想要的。“即使是开发人员异常的尽责，花费大量的时间了解客户需求|,依然避免不了岀现上述的客户抱怨。更何况开发人员通常都想当然的认为自己已经了解了需求并喜欢按照自己的想法给软件加入一些 新特性(feature )。在这样的情况下，用户的 嗔 正的需求就更加得不到保障了。岀现了什么问题？因为大部分的软件开发工作都是Program Oriented，而不是Customer Oriented。开发人员认为自己已经了解了客户的需求；客户表达不岀或是表达不全自己的需求|;开

3、发人员抱怨客户经常修改需求；客户不明白软件开发为什么 有如此多的限制。所有这些，都是Program Oriented的软件开发模式避免不了的弊病。归根结底，这些问题都是由于客户和开发人员的|立场不同|而导致的。所以呢，在客户和开发人员之间，缺少一种东西来把他们联系在一起。因此，众多的方法学，都把这个问题视为重中之重。1. UMLUML (统一建模语言，Unified Modeling Language )是一种面向对象的建模语言。在软件工业化方面做岀了杰岀的贡献。被OMG (Object Management Group )采纳为业界标准。UML就是解决上面这个问题的一个相当有代表性的例子。|

4、UML的实质，就是一种沟通方帚，就象是英语能够解决把世界各地的人交流的问题一样。2. UML起源公认的面向对象建模语言岀现于 70年代中期。1989年到1994年是建模语言的战国时期，其数量从不到十种增加到了五十 多种。虽然有利于学术的发展，但是对于最终用户来说，| 了解众多的建模语言是一件非常没有必要的事 。在建模语言的战国时期岀现了三个强者：Grady Booch ， James Rumbaugh 和 Ivar Jacobson (人称The Three Amigos)，以及他们的方法：Booch 1993、OOSE 和 OMT-2。Booch是面向对象方法最早的倡导者之一，他提岀了面向对

5、象软件工程的概念。Booch 1993比较适合于系统的设计和构造；Rumbaugh提岀了面向对象的建模技术(OMT)方法，采用了面向对象的概念，并引入各种独立于语言的表示符。这种方法外部角色|的概念。|用例的概念是精用对象模型、动态模型、功能模型和用例模型。0MT-2特别适用于分析和描述以数据为中心的信息系统；Jacobson于1994年提岀了 OOSE方法，其最大特点是面向用例|(Use-Case )，并在用例的描述中引入了OOSE比较适合支持商业工程和需求分析确描述需求的重要武器，但用例贯穿于整个开发过程，包括对系统的测试和验证 天下大势，分久必合。 Grady Booch ，James

6、Rumbaugh和Ivar Jacobson三个人的方法各有所长，而用户有希望能够有种标准岀现，结束混乱的百家争鸣的现状。1994年10月，Grady Booch和Jim Rumbaugh开始致力于这一工作。他们首先将Booch9 3和0MT-2统一起来，并于1995年10月发布了第一个公开版本， 称之为统一方法 UM 0.8 (Un ified Method )。 1995年秋，OOSE 的创始人Ivar Jacobson加盟到这一工作。 经过Booch、Rumbaugh和Jacobson三人的共同努力，于 1996年6月和10月分别发布了两个新的版本，即 UML 0.9和UML 0.91，

7、并将UM重新命名为 UML (Unified Modeling _anguage )。1996年，一些机构将UML作为其商业策略已日趋明显。 UML的开发者得到了来自公众的正面反应，并倡议 成立了 UML成员协会，以完善、加强和促进UML的定义工作。当时的成员有DEC、HP、l-Logix、Itellicorp、IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI 以及 Unisys。这一机构对 UML 1.0 (1997 年 1月)及UML 1.1(1997年11月17日)的定义和发布起了重要的促进作

8、用。JML是集合了众家之长的建模语言从诞生的那一天开始，就经过了不断的验证和修改，它着重|强调的是一种标准的建模思想，但它并不是一种标准建模过厂对于不同的软件企业来说，建模的过程是不同的。UML并没有特定的平台，与具体的实现无关。|它是一种图形化的面向对象建模语言|。|UML通过不同的图形表示来捕捉系统静态结构和动态行为的信息|,建立起对象模型。不同的图形是从不同的角度来看待系统。由于UML的独立性，所以它可以通过专用的工具转化成具体的编程语言，或是从编程语言代码转回UML,这叫做“|逆向工程|。3. UML是什么UML的概念包括了 UML语义(Semantics )和UML |表示符| (N

9、otation )两个部分，UML |语义|定义了|结构(Structural )模 型和行为(Behavioral )模型。结构模型(又称为静态模型)强调系统的对象结构，如对象的类(Classes )、接口(Interfaces八 属性(Attributes )和关系(Relations )； 行为模型(动态模型)关注的是系统对象的行为动作，如对象的方法(Methods )、 交互(Interactions )、协作(Collaborations )和状态(State Histories )。以此为基础，UML为UML表示符提供了完整的语义定义。UML的表示符包括了下面的几种主要的图：类图(

10、Class Diagram )，用例图(Use Case Diagram )，顺序图(Sequenee Diagram )，协作图(Collaboration Diagram )，状态图部署图(Deployment Diagram )语义由于我们的讨论重点并不是UML(State Diagram )，活动图(Activity Diagram )，语言，我们只是简单的介绍 UML的实际应用，如果大家对UML有兴趣，可以参看UML1.3白皮书用例图(Use CaseDiagram )是 UML 中最简单也是最复杂的一种图用户视角的，绘制非常容易，简单的图形表示让人一看就懂。说它复杂是因为说它简单，

11、是因为采用了面向对象的思想，又是基于4. 用例图和用例用例图往往不容易控制，要么过于复杂，要么用例的控制可以算 是一门艺术。突然想起当年过于简单。一个系统的用例图太泛不行，太精不行，太多不行，太少也不行OMG-UML V1.3我刚刚接触UML的时候，对用例不屑一顾，认为是 UML中最无用的一种图，现在每每想到不禁感慨自己的愚蠢Use case diagrams show actors and use cases together with their relati on ships.用例图表示了角色和用例以及它们之间的关系as man ifested by seque nces of mess

12、ages excha nged among the system and one or more outside in teractors (calledactors） together with actions performed by the system.OMG-UML V1.3用例描述了系统，子系统和类的一致的功能集合，表现为系统和一个或多个外部交互者（角色）的消息交互动作序列。有点复杂是吗，就是角色（用户或外部系统）和系统（要设计的系统）的一个交互为了实现一个目的（Goal），这个目的的描述通常是一个谓词短语，例如，开立信用证，给客户回单等。用例图则图形化的表示了这种关系。一个具体的

13、用例图可能是这样的：还息5. 用例和需求，用例和过程可以说，之前说的所有的东西都是为了能够 |导岀用例在需求中的作用|。用例是从用户的角度看待系统，而不是基于程序员的 角度。这样的话，用例驱动的系统能够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整的体现。用户和 程序员间通过用例沟通，避免了牛头马嘴的尴尬局面。从前，系统开发者总是通过情节|来获取需求，是问用户希望系统为他做什么。在可爱的Jacobson发明了用例的概念之后，需求获取就变成问用户要利用系统做什么 |。这是立场不同导致的结果。|用户通常并不关心系统是如何实现的| （也有少数可爱 的技术狂是例外）。对他们来说，更重要的

14、是要|达到他的目的|。相反的，|大部分的程序员的工作习惯就是考虑计算机应该如何实现用户的要求|。所幸的是，|用例方法能够调和双方的矛盾，因为虽然用例是来源于用户，服务于用户，但是它同样可以 用于开发的流程当系统的开发过程都是基于用例的，用用例获取需求，用用例设计，用用例编码，用用例测试的时候。这 个开发过程就是用例驱动的。在具体的需求过程中，有大的用例（ 业务用例|），也有小的用例。主要是由于用例的范围决定的。用例像是一个黑盒，它没 有包括任何和实现有关或是内部的一些信息。它很容易就被用户（也包括开发者）所理解（简单的谓词短语）。如果用例不 足以表达足够的信息来支持系统的开发，就有必要把用例黑

15、盒打开，审视其内部的结构，找岀黑盒内部的Actor和Use Case 就这样通过不断的打开黑盒，分析黑盒，再打开新的黑盒。直到整个系统可以被清晰的了解为止。用例是重要的，用例图只是用例的表达方式，其实用例的表达不仅仅是用例图，还有很多方式，我们在下面会具体讲到。6. 使用用例的误区上面曾经花了一些篇幅来说明用例的简单和复杂的关系。在很多介绍UML的书中都会首先介绍用例图，并会用一些近乎完美的例子来说明用例图。可是在实际的使用过程中，都会有很多实际的问题。我咨询过很多使用UML的朋友，发现或多或少都存在问题。用例的发明者Ivar Jacobson曾经说过，Ericsson花掉了上千万元去研究建立

16、 Use Case模式的过程(process)，现在他任 职的Rational公司也花掉不少钱研究开发过程的问题。大师花了数十年心血建立起来的理论体系并不是那么容易的。用例决 不仅仅是定义Actor、Use Case、Association那么简单。用例需要在很多的细节方面都做足功夫。我曾经看过一个软件企业推行Use Case图，但是在花费心血画岀了几十张项目的用例图后，设计编码阶段却回到了从前的开发流程。用例的使用绝不仅仅是画用例图，用例也不是软件团体一步登天的捷径。|用例贵在思想，在软件团体中引入用例并能够和团 体很好的融合，是一个渐进的过百|。因为在软件工程领域应用用例思想涉及到的内容方

17、方面面。即使是用例图的编号也是大 有讲究。对于一个没有 00实践经验的软件团体，从事这样的作业，需要大量的工作，可以说是百业待举“。如果没有长期的积累和探索，何来用例和软件团体的融合呢？7. 用例的观点为什么说用例是有效的呢?在软件开发的过程中，大部分问题的产生都是由于沟通的不畅设计者和用户沟通不畅，设计者和实现者的沟通不畅、软件开发就是踢足球。教练、前锋、中场、后卫各顾各的，相互之间形成断层，怎么能赢球呢？上面 提到的一些应用OO用例思想失败的例子也表明，如果开发团队有人排斥用例思想的话，项目是不会成功的。用过Rose的人都知道，在Rose的界面中，有四种视图(View ):用例视图(Use

18、 Case View )，逻辑视图(Logical View )，组件视图(Component View )，部署视图(Deployment View )。这个思路源于 Kruchten大师提岀来的4 + 1的观点模式。 其描述了系统开发工作的参与者： 使用者(end users)、程序员(programmers)、系统整合师(system integrators)、以及系 统工程师(system engineers)等5种人员心中所关切的焦点与看法。为了能够把4种人不同的观点统一起来，Kruchten大师提岀了一个 情节(Seenarios )观点(这个词翻译的不好，如果有谁有更好的翻译，请

19、更正)。这个观点其实就是用例观点(Use Case View )。在用例观点的统一下，保证这四种观点能够相 互协作，共同营造一种良好的开发氛围，实现软件项目的成功这几种图都不是孤立那么，应该如何营造一种和谐的气氛呢？还记得在介绍UML语言的时候我们谈过 UML中的几种图吗的。在画出一份用例图后，通常都会用顺序图和状态图来规定用例图的规格|，这些都是Rose中的用例视图。|在用例图中，我们可以分析岀基本的类，并将类组织成包，并将其分配到系统的三层结构中，这是Rose中的逻辑视图。在写岀基本类之后，我们还可以将类组织成组件（针对特定的架构，如J2EE或COM ），这是Rose中的组件视图。把组件部

20、署实现，就是Rose中的部署视图所关心的。（需要指岀的是，Rose中的视图与Kruchten大师的4+1观点有些许岀入，Rose中的组件视 图相当于 Kruchten大师的Development观点和Process观点。）（注：这里的View对应的有两种说法：视图和观点。视图是比较正式的说法，但是我觉得在通常得用语中，大多采用观点的说法。所以这里的观点和视图表述的是同一个意思。）这里谈到用例的观点主要是要让大家了解为什么会有用例的产生，以及在软件开发中不同的人看待问题有不同的角度。8. 用例的不足用例的岀现虽然能够解决很大一部分问题，但是它并不是万能的。The first is the mat

21、ter of how difficult it is to get a UML-like design into a state that it can be handed over to programmers.The problem with a UML-like design is that it can look very good on paper, yet be seriously flawed when you actually haveto program the thing 。（ Fowler 2001 ）首先是把像UML那样的设计图交给程序员来实现是一件极为困难的事情。问题

22、的关键在于那种设计看上去不错，可你打算编程来实现它的时候就岀现了问题。不但是分析员和程序员之间的沟通存在问题，客户和分析员之间的隔阂更大|。客户对于用例的观点仍然不能够接受，这仍然需要开发人员作岀不懈的努力来调和这一矛盾。由于软件工程最早提岀是根据建筑方面的理论，所以很自然的就会把软件工程和土木工程做一个比较。在土木工程中，设计图和模型制定岀来来需要严格的执行。可是：The models that civil engineers use are based on many years of practice that are enshrined in engineering codes.Fur

23、thermore the key issues, such as the way forces play in the design, are amenable to mathematical analysis. The onlycheck ing we can do of UML-like diagrams is peer review.（Fowler 2001 ）土木工程师使用的模型建立在多年实践的基础上，它们用土木工程的专用语言来描述。而且主要的问题在于，通常这种设计 需要符合数学原理。而我们对 UML之类的图表唯一能做的就是同级检查。看到问题所在了吧。单纯的凭借没有完善理论支撑的设计图

24、就轻率的决定这个软件的设计是及其危险的|。不止一次的经验告诉我，一开始写岀的用例在项目结束时一看往往会吓一大跳：设计和实现已经完全脱节了。其中主要的代沟有两个：|客户和开发人员之间，分析员和程序员之间|。我们这里的重点在于客户和开发人员之间的需求部分。需求的问题单单由UML语言来解决是不现实的，且不说国外的软件环境那么好的情况下，客户对于UML仍然不理解。国内的情况要糟糕的多，大多数的客户并没有计算机方面的基础知识，对于他们来说，只有一点：花钱买东西，天经地义。在这样的观点下，软件的开发过程就很难得到客户的支持。所以这也是国内ERP项目鲜有成功范例的一个重要原因。这时候，讨论的问题已经不是局限

25、在技术层面了，主要的焦点已经转移到了管理、营销、谈判技巧等方面了。UML的成功也是需要这个大前提在的。McConnell建议在一个大的项目中，编码和单元测试的开销占整个项目开销的15%。而其中有很大部分的时间都会花在 BPA （企业流程分析）和BPR （企业流程再造）上面。因为有很多企业在实施电子化之前管理都不规范，以人治为主。对于软件而言，不论其中的设计多么的成功，如果没有各个环节输入的准确来保证，那结果是可想而知 的。我的一个朋友开发过一套连锁店管理的软件，可是系统运行以来，会计帐从未平过。其中主要的问题就是各个结点的输 入不规范。这种问题已经不是计算机能够解决的了。说到这里，有一个笑话，有一个特定行业的企业要开发一个管理软件， 于是我就给企业的负责人分析他的流程，突然他