Ivar Jacobson访谈

                                                                                               Adriano Comai 著， Tang Xiaoming 译

    人物简介：Ivar Jacobson是世界著名的软件开发方法学家之一。他是面向对象软件工程(OOSE)和Use Case的发明人，与Rational公司的Grady Booch、Jim Rambaugh共同创建了一种可视化地说明、建造软件系统的工业标准语言--统一建模语言(UML)，UML在1997年被OMG（这个组织还制定了CORBA标准）正式确定为国际标准。他负责Rational公司的商业和系统工程领域的合作和产品战略。  
    Adriano Comai是一位意大利的方法学家。这次采访发表在http：//www.analisi-disegno.com 和意大利杂志“ZeroUno”1999 年的十月号上。
 
    [Adriano Comai]（以下简称Adriano）：Jacobson先生：你是众所周知的“用例”概念的发明人，这个概念是怎么来的？是什么动力使你对这个想法做进一步的研究呢？  

    [Ivar Jacobson](以下简称Ivar)：它的发展已经有许多年了。首先，在我早期在电信领域工作的时候，有一种“通信案例”，通信案例就象用例，事实上是一次电话呼叫。有各种各样的电话呼叫，有各种各样的通信案例。这是我在那儿学到的某些东西。那时候除了电话呼叫以外没有其他案例。在早期，我的意思是说在1967年，我们有一个和用例相似的术语，代表和用例相同的意思，我们把它叫做“功能”。一个功能贯穿整个系统。一种电话呼叫是一种功能，但是功能更抽象一些。 术语事实上没有一个很好的定义。我们当时用的“功能驱动的开发”，现在被叫做“用例驱动的开发”。我们识别出功能，然后设计这些功能，就象如今我们使用用例一样。因此这些观念是非常古老的。我在1986年意识到用例的概念。当我发现这个概念的时候，我意识到我找到了能够解决许多问题的东西，因为我可以在任何一种系统，系统所作的任何一件事情上使用这个概念。它对我创造一种系统的方法学很有帮助。  

    [Adriano]：用例概念就象一个过滤器，可以区分用户相关的功能和系统内部的功能…。

    [Ivar]：是的，它去掉了许多不是用例的功能。它更加具体。一个功能可以是任何东西，那是问题所在。用例不可以是任何东西。  
  
    [Adriano]：在软件工程文献中，用例概念的祖先是什么？它根源于哪种概念？

[Ivar]：我不知道。事实上，我没有那样的概念。我想最接近的东西是通信案例这个想法。但是我必须指出一点：我因为用例而出名，这的确是事实，但是1967年我们有基于组件的开发方式的时候，用例还没有诞生。因此基于组件的开发是我一生一直在努力的东西。另外一个是体系结构，我的意思是指真的先辨别出一个体系结构---在做任何事以前。我们在1968年讨论了软件的体系结构。当我们跑到客户那里去的时候我们给他们看整个软件的体系结构。我记得他们从来没有听说过诸如此类的东西。他们教授硬件体系结构，但是他们从没听说过软件体系结构。

[Adriana]：用例概念今天看起来几乎是非常明显的，就象是常识一样…。

[Ivar]：我想是的。

[Adriano]：但是如此快速而广泛地被其他方法学家所接受，这的确是一个奇迹。为什么阻力会如此之少呢？

[Ivar]：大部分方法学家都来到了对象世界，竞争非常激烈。但是用例却没有和他们发生竞争，它解决每一个人都有的问题。甚至“场景”（scenario）这个概念也牵涉到系统的内部和内部的相互作用，而且没有被真正地详细说明。我做得太迟的事是发表。如果你去看我1987年关于OOPSLA的论文，这些东西都存在，但是在1990-1991年，我可以把我的《Objectory》卖$25,000一份。所以我为什么要跑到Addison-Wesley或其他出版商那儿，然后卖$3一份，即使能卖得更多？现在我认为我应该做得稍微有些不同，不过这也很难说，你必须在一个恰当的时间（去做）。所以我想其它书籍帮了我们，因为它们都有大问题，那就是如何从需求开始进行面向对象的分析和设计。但是我拒绝这样的观点：事实上他们出版了书，所以他们是第一个有这些思想的。这些并不是一些新思想。

[Adriano]：用例规格主要是文本方式的(虽然也可以用图来补充)。以前的方法(比如结构化分析,信息工程等)建议使用图作为"公共语言"以便在客户和开发者之间达成一致。这种文本角色的复兴背后有什么含义吗?

[Ivar]：现实中,今天的软件客户不想再看图表了。用例图表是如此的直观以致于任何人都能读懂。文本使人们不再需要学习一种特殊语言。

我们可以用活动图来表示用例,它很好,但是有两个问题。首先,它们很快变得过于详细,当细节展开时你不能确信它们是否更容易理解--即使毫无疑问在某些点上你需要更多的细节。但是我们想最好的方法是用分析模型的术语来做,其中你可以用对象之间的合作来描述每一个用例,而不是在细化用例的时候丝毫不涉及对象。你可以使用活动图,但是活动图可以是非常抽象的,因而难于理解。

你确实需要了解应该做什么,需要去了解那些活动。因此我在用例中引入形式（formalism）时是非常谨慎的。我想在你分析时你会得到好得多的形式，好得多的语言来表达细节。因为你(这时)谈到了对象。

[Adriano]：也许活动图不象文本一样能传达那么多的信息…

[Ivar]：是的,这很现实,并没有什么可奇怪的。在某些情况下使用活动图是好的。但是我想给一个警告：当你有合适的语言来表达细节时你最好将其细节化。我想在分析时我们讨论对象,对象之间的合作,即使这些对象是概念上的,而不是实在的,可以实现的对象。它们也比活动更具体,也更容易理解。

[Adriano]：那么自然语言的歧义性呢?

[Ivar]：是的,的确有歧义性。但是我想这有一个权衡…语言容易理解，只要用英语就可以了。另一方面,当我们碰到有许多交互的、困难的用例时,你也许需要走得更远。但是把分析模型看作是需求的一部分会更好。在新的《统一过程》书中,我朝那个方向走了一小步,我把分析看作是需求的一部分。我们在分析中得到的东西之一就是我们希望在设计和实现中看到的结构。所以通过分析我们创造了一些对体系结构的需求。

[Adriano]：在你的方法中,用例扮演了双重角色。第一,它们被用于发现和确认来自用户和使用者的需求。第二,它们驱动整个系统的开发。是不是某个角色比另外一个更重要呢?

[Ivar]：不,当然不是。但许多方法学家和软件开发者在技术上是非常内向的，如果用例概念在描述交互作用,帮助定义合作方面不是那么好的话,他们不会采纳它。因此对软件开发者来说它就象一条很好的营销论题：如果它们对设计没有影响,如果它们没有驱动开发的话,它们不会象现在一样被广泛地接受。对于我,不管怎么说,两个方面是一样重要的。这是一个发现需求,在某些图表中捕捉需求的很好的方法,不用深入系统内部。它们被用于捕捉和识别场景,描述相互之间的关系。

[Adriano]：在你的书中,你谈到了把需求的特性列表作为导出用例的起点。

[Ivar]：特性列表是将被转换成用例的一些东西，而文档则描述用例。所以当你把要求的特性转换到用例时，特性列表会增长，会变短。

[Adriano]：几年以前,你把用例概念和其他对象思想应用到业务流程再工程领域。你的建议被非IT界的人接受的程度如何?用例在业务工程领域是否象在IT领域一样被频繁使用呢?

[Ivar]：不,没有。这有好几个原因。Rational公司选择了软件作为工作重点。即使我们完全意识到业务工程的重要性。然而,我们知道人们在业务工程中使用的工具可以很容易用软件工程中的工具术语来描述。如果你用ROSE来进行可视化建模，你可以扩展它来用作业务工程，而不是反过来。我们仍然需要软件可视化建模的好工具。我们已经在业务工程上工作了一段时间。但是是局部地做，在斯堪的纳维亚。我们在瑞典有一个Rational的服务包，叫做Rational业务工程，有一个ROSE的特殊化版本和详细的流程描述。软件工程的客户基础更广泛。想要进行业务建模的人通常理解软件，知道他们需要得更多。来自业务领域的人，比如Hammer，则不会对建模想得那么多，这真让人非常沮丧。所以从业务建模来的人非常少，大部分的人来自软件领域。这方面的业务量非常少，但有些客户有几百张Ｒｏｓｅ 业务工程版的许可证，比如电信公司和瑞典的养老金系统。

［Anriano］：你有没有就你的业务建模建议联系过其他人，比如Hammer和Champy?

[Ivar]：没有，当然我读过他们的书。我们已经做了多年的业务建模，但是当我读他们的书时我说：“哦，这儿有个家伙提出了一个问题，然后给出了解决方案的骨架和轮廓，但是没有对它建模，不建模你就没有理解它们。”不管怎么说，我感到Hammer的工作和我们的工作的联系是非常紧密的。另一个重要的想法是一对一的市场营销。一个在Objectory中为我工作的人现在正在这个方面做工作。她认为我们的方法是完美的。这是我将来想要做进一步工作的领域。我经常是为长远的目标比如五年后会发生的事情而工作，最近我将在两个领域工作。其中一个是业务工程，关于它是如何被新世界，互联网世界所影响。另外一件是WEB环境下的软件开发，WEB应用。即使WEB改变了一切，从根本上改变了商业上的每一件事，我们为WEB开发软件的方式并没有变得太多。在本质上是相同的，不同的只有一件事，那就是用户界面。用户界面的设计是非常重要的。

[Adriano]：我在你最近的一本书中看到你引用了Larry Constantine的一些话，你喜欢他的方法吗？

[Ivar]：非常喜欢，他的最近的一本书非常好。唯一的问题是他没有用UML而是用他自己的标记，那种标记比较薄弱，而且没有很好的定义。对什么是模型他有不同的看法。但那本书中有不少好东西。我非常喜欢，那是3年来在软件领域我看到过的最好的书。

[Adriano]：劝说IT非IT界的人士把业务建模作为新项目或改进现有系统的起点是不是更难呢？

[Ivar]：问题是我们没有时间，推向市场的时间是今天…。。你尽快搞出点东西来，这比说这是一个好东西要重要得多。那意味着这些方法必须紧密集成在一起。IT界的人知道做业务建模需要6个月，12个月，而当他们开始建造系统的时候，业务已经发生了变化。我们的方法的独特之处在于业务建模是流程的一部分，所以如果你有6个月的时间来开发软件，你就有6个月的时间来业务建模。我能理解人们为什么对业务建模犹豫不决：如果我们不认为质量是非常重要而要千方百计去做到，那么无论用何种结构化的方法来开发软件都会存在问题。但是通过迭代式开发方法我们依据计划得到了一些东西，我想那会帮助人们理解持续不断，从头至尾进行业务建模的重要性。

[Adriano]：UML是集体性的创造，统一过程也是。但在后者中，你的贡献更清晰，更明显，统一化流程更根源于Objectory / OOSE而不是BOOCH方法或OMT方法。这是不是反映了朋友之间的某种“分工”？

[Ivar]：我不认为我们在目标上进行了分工。某些人是百事通，但很难有哪个领域我们三个中的任何一个认为一点经验都没有。公正地说，我认为没有分工。我们开发RUP的时候是以Objectory方法为基础的，这是事实，我们是从那儿开始的。当然，你没法仅仅从对象模型开始。并没有一条简单的途径能从OMT或BOOCH方法过渡到我们在OBJECTORY方法中所做的东西。而反过来则要容易得多。想一想用例，然后你可以设计对象，类，子系统。

[Adriano]：Booch 和Rumbaugh来从软件出发,而你是从客户和使用者那方面出发…

[Ivar]：是的,但是事情还有另外一个方面。组件是我们不得不开始着手的东西。我实际上是从组件开始着手的。1967年我在Ericsson引进这个方法的时候,开发人员的主要反对意见是我们开发的这些组件不容易和"功能",或者"用例"相关联。如果从用例角度看,用例使用了许多组件：这就是反对意见,他们想的是"一种功能,一个模块"。

而我却说,好吧,那的确不太妙。大部分功能或用例应该用一个组件来实现;但是其他组件也会在其中扮演一个角色。那就是反对意见之一。我说,正是这个反对意见我要把它转化成积极的东西：这真正是你们想要的东西,你们需要复杂性,因为事情本来就是这样的。虽然在外部讨论用例,但在内部用例贯穿了这些组件。

拥有对象和组件的子系统,并不关心是谁使用了它们,这只是个小问题。麻烦的是实现用例,管理子系统之间的相互依赖,这要困难得多。对象的事是一个小得多的问题,是一个亚问题。

不,我不认为在分工上有任何刻意的决定。我们认为UML是一个大任务。我们必须一起工作来完成它。现在我们做不同的事,我们不认为在任何事情上都需要一起工作。

[Adriano]：你希望统一过程成功吗?你希望它对IT工业的影响能和UML类似吗?

[Ivar]：是的,绝对是的。我们有非常好的理由相信这一点。如今我们正朝着公司进军,我们的目标是到达那里。我们不认为很容易使统一过程成为一个标准,这会是一件非常困难的工作,会有许多反对意见。所以我们宁愿小步前进。与其强迫别人通过一个标准,不如让人们自己去说服自己。我想每一个看过RUP的人都会被说服,相信这就是他们想要的方法--只要他们开始去看。甚至没有任何东西能接近它。许多人说有,可是他们有的是什么?他们有可以和我的书相比的东西,但是他们没有任何能和我们的流程相比的东西。如果你从实例,深度,经验等各方面,如果你拿…方法A,或方法B有多久历史?我们知道它可以用于大型项目吗?我们知道我们的可以。这的确是非常不同的。

[Adriano]：有多少Objectory方法中的东西留在了统一过程中?

[Ivar]：如果你从基本概念上看,在Objectory方法中我们基本上只涵盖了需求分析,系统分析和设计。如果你从这些方面看,早先Objectory中的东西仍然有。但已经有许多新东西加了进去。我们很少是有关于实现,有关于测试的,没有配置管理,没有版本控制,没有项目管理。迭代式开发是我们首要建议的东西,但它通过流程得到了加强。我们并没有真的说出各次迭代的不同之处。所以我认为核心思想还在,但已经加进了很多其他东西。RUP是一个团队工作,有许多人参加进来。而Objectory 过程实现的首要是我的想法,和我的工作。但基于我们的资源那么少,也应该说是很多(的工作了)。

[Adriano]：你提出的每一次迭代就象一个小的瀑布方法…

[Ivar]：是的。我们把它看作是一个小瀑布方法,但其中我们还有许多并行。在瀑布方法中开发子系统的人是在并行地开发子系统。相对独立地使用用例的开发人员互相交流来重用组件以避免重复发明。在一次迭代中它们并行开发子系统。但那仍然是瀑布模型。因为你始终是从需求分析开始,然后是系统分析,然后是设计活动。

[Adriano]：你来自瑞典,你是否感到在系统和软件工程中有欧洲的特异性?相对美国来说是否更关心,更关注于组织方面的事?

[Ivar]：我没能找到任何系统性的差别,因为美国人在开发软件时非常喜欢从业务,从理解业务开始着手。欧洲也一样。没有什么系统性的差别。更有趣的是…在欧洲,许多研发是在抽象比较多,实在的,物理的比较少的领域里。但是我必须说,无论是美国还是欧洲,许多研发已经完成,取得了有用的成果,同时也有许多工作没有任何结果。

[Adriano]：现在"统一化"努力中的最伟大部分已经完成。你是打算去休息，还是利用它,或者你是否正转向其他感兴趣的领域?下一个是什么?

[Ivar]：我身上的一部分说：我想要前进,找找看有什么要做的,要去创造一个更好的世界,我们有许多事要做。某种程度上,uml是一个标准,那很好。但这并不意味着这是些新想法。我们只不过是把它们固化下来而已。在过去几年中,我想我没有真的做了一些新东西。我推进了采纳过程而不是创造过程,现在我身上的一部分想要迈出下一步。统一过程之后是什么?uml之后是什么?我想仍然会有一次进展,但不是一次革命。但在软件领域中仍需要采取一些重要的步骤,以便赶上我们在2020年开发系统时所需要的特别高质量的水平,或其他类似的东西。这些要比我们今天能想到的系统要大得多,要复杂得多。我们需要有能力去开发这些系统。就操作系统,编程语言,和编程语言集成的UML等方面,我们需要一个更好的基础架构。也许uml的一部分会变成带有动作语言语义的一种编程语言。这是我经常会想到的。

另外一个是利用业务工程。有一些的确有趣的工作可以做。RUP已经非常适合web的开发。如今许多开发WEB站点的公司已经在使用RUP。稍微做一点特殊化,它就可以满足他们的特殊目的,但还是同一个流程。我希望看到我们在RUP所做的扩展和正确决定能够获得所需的模型改进。这些改变非常清楚地、毫无疑问地使它变成适合WEB站点应用设计的流程。

我也打算在年底以前写一本我的"The Object Advantage"（《对象的优点》）的修订版。互联网,一些其他想法,比如一对一的营销，将会对这个修订版有巨大的影响。我们需要让这本书更针对商务人士,而不只是针对软件人员。我们将会展示在业务场景下如何使用它,而不只是在软件场景中。基本思想早就存在了,而且工作得非常好,客户很满意。但现在我们需要带它跨越过IT界的栅栏,解决人们接受技术符号时存在的问题。活动图对业务建模非常有用。