Ivar聊天实录：软工技术发展趋势

潘加宇：谢谢大家的光临。今天第一个话题是软件工程最新趋势，从我的理解来看，和Ivar 来谈有四个方面，第一个是用例；第二是UP；第三，Ivar离开Rational做自己的新事业，在北京也成立了Ivar雅各布森中国有限公司，到底是做什么呢？这是他的新事业。大家可以关心一下；第四个主题是想听听Ivar对MDA新进展的形象。

第一个话题就是用例，大家使用用例的时候会有很多困惑，用例力度是多少？业务用例跟系统分道有什么问题关系呀。上课的时候大家也问过我，我也回答了，但觉得不权威。今天用例发言人来到这里，机会比较难得，看大家在用例有什么问题可以问Ivar。

提问：所谓现在提出MDA，Ivar提出Usecase，我现在带学生，到底是怎样从Usecase开发一个项目，现在要做的就是做设计，是怎样的流程？设计比较粗略，用序列图去解释，实现功能性的需求怎样去合作？怎样完成这个定义。从设计来讲，哪几个是最关键的？我们建立类图、序列图或者协作图，目的是要建模，建模就是要建类，把属性和方法填满。从用户需求怎么得到一个类，得到这个类里头的属性方法，所有类建全了，模就建全了。序列图是消息，是到类的一个消息，活动图也是描述消息，我这种理解对吗？也就是哪些图是最重要的？

Ivar  Jacobson：回答第一个问题，从业务建模开始到编写代码，哪一个步骤或者方法是最重要的？序列图是最重要的一个图，活动图是帮助你解决了在你的对象上怎么分配，怎么分配每一个职责，这里起到一个非常重要的作用，序列图在很大程度上帮助你回答Usecase是怎样实现的，所以序列图是最重要的。但是有一个非常重要的一点，协作图可能会比较细节，就是说取决于你现在到底做什么？如果已经到了非常低的细节层次的时候，序列图会帮助你很多。序列图关键一点就是你要有泳道，你的泳道一定要清晰，否则就会有一个混沌的泳道，整个思维就乱掉了。

我们在电信当中曾经在SDL的方式曾经用过状态图和活动图在一起用，来表达正在运行的进程的状态，这是一个很好的方式。在其他的环境下，我们非常强调活动图一定要有泳道。

我们在业务流程当中，长期在业务活动图当中描述流程，这个方式已经很多。但是我们看到的是，在业务流程描述当中要有泳道来给你一个明确的标记，如果没有一个明确标记的话，业务流程画出来以后，只有业务流程作者才能理解业务流程，因为别人没有任何一个方式作为参照来理解到底这个业务流程在说什么，所以这是一个非常重要的。

提问：就是分不清到底谁来做。

Ivar  Jacobson：最有用的是对象。

刘新生：我想问一问，您最近在研究AOP，您对AOP和用例结合这方面有什么最新的研究进展？

Ivar  Jacobson：在1969年的时候就已经在思考类似关于Use  Case的问题，有一天突然领悟到新的想法帮助他来解决如何描述用户需求，如何来把整个开发的链路打通，在这中间就想到Use  Case的概念，当时发现有一个非常大的缺点在什么呢？Use  Case非常好的概念就是可以用Use  Case来做设计，你可以用它来做测试，把它转化为测试用例，但是一旦到了实施阶段，真正编码的时候，发现Use  Case有哪些类、协作图参与到Use  Case，具体到每一个模块参与到Use  Case当中，这是长期困扰的一个问题。

我在1978年的时候，在爱立信内部发表了一篇技术报告，就是来讨论横跨很多个组件的关注，实际上为什么做这样的事情呢？解决了我们经常面向对象里经常遇到哪个词，一个叫“散布”，一个叫“缠绕”，Use  Case  遇到这个模块就会有一个现象，就是散步和缠绕，为了解决这个问题，当时提出了一个方案，但爱立信内部不喜欢这个解决方案，在1986年的时候，我写了一篇论文在面向对象年会上，当时把主体思路做了一个阐述。

在这中间解决了什么问题呢？也就是我们现在看到在Use  Case从需求开始一直贯穿到测试中间一个缺失的链条，也就是在实现这一块。之前论文上就提出如何把这些关注点真正的从头到尾的割离开。

在面向方面编程方式的帮助下，我们能够做一件以前做不道的事情，在项目当中可以根据Use  Case来分队开发团队的职责，有人根据一两个Use  Case做需求，有一两个人对Use  Case做设计，有人专门对几个Use  Case编写代码，这是在以前做不到的。以前编写代码的时候一定是分配组件了。

透明：刚才讲到方面用在Use  Case的实现提供帮助，怎样保证方面取得组合作用。在实现的时候，怎样能保证方面用在Use  Case上，有没有契约的保证？

Ivar  Jacobson：实际上是一对一的对应关系，每一个Use  Case的扩展会对应到方面，它们之间是同级的关系或同辈的关系，这实际上是用类来体现Use  Case。在扩展上有一个方面的对应关系。

潘加宇：我有一个问题，您有没有自己用过方面的工具，例如自己尝试过用AspectJ来做一些东西？

Ivar  Jacobson：我本人用AspectJ写过一些小的程序，我知道有一些很好的朋友在用AspectJ开发，开发过很多大系统，所以它能够发现大系统当中的大问题，这些关键问题点上做AspectJ上会发生什么变化，它也提出了在UML标准当中对AspectJ方面有一个支持，包括Pointcut。

钱岭：我们工作当中有通讯系统，会用到一些时序图，我们关注的是Dialog，如何保证模型是正确的，而不是这个图画就画出来了。我想在这方面有没有相关的技术呢？

Ivar  Jacobson：1967年－1972年之间，我用序列图的原型，包括序列图、活动图，在1967年－1972年和1970年－1976年分别组织开发过两个大的时序图，确实有一个现象，我们有一个很重要的发现，在用序列图、Dialog原来小很多，我们以前为有很多Dialog，我们正规描述下来发现Dialog没有那么多。同时借助状态图来描述每一个处理的时候，这个地方要非常小心来识别哪些地方的对话，如果细心的话，不会碰到那么多Dialog。据我所知，UML2.0放了很多新的东西来帮助解决这个方面的问题。同时有人建议peri网和UML应该很好结合起来来解决这方面的问题。这更多是学术的问题。

潘加宇：这里有一个在线网友的问题，请Ivar先生评价一下UML2.0当中的Use  Case。

Ivar  Jacobson：我并没有参与到UML2.0的制定工作当中去，但是我听说当时有计划在2.0对Use  Case做比较大的改变，当时我非常反对他们所提的一些建议，现在回想起来，当时的反对是非常正确的，如果不反对他们那些改变的话，我们今天就没有办法这么清晰的把Use  Case和面向方面结合起来。

如果只是针对1.1的问题，我有一个基本的假设，1.1到2.0没有发生很大变化的话，我是非常满意在目前UML标准中对Use  Case的定义，为什么呢？首先从形式的角度上来看的话，你可以识别他，Use  Case本身有行为和属性，所以这是一个很好的。从根本来说，Use  Case并不是从数学证明的东西，是非常实用型的东西，在形式化上已经做到这么一个程度已经很好了。另外一个角度，Use  Case在UML定义上有很多用途，表现出它一个强大表现力，在软件建模、业务建模当中都可以用，在用户建模当中可以用，在用户体验当中也可以用，在系统交互当中也可以用，一句话总结就是自己一个漂亮的孩子有很多很多的名字，Use  Case就是这样一个东西。

提问：我想是否一定要在系统开发当中必须使用用例？用良好的交流对内的沟通和对外的沟通，某种意义上可否可以取代用例图。我们前期做了一个项目，跟客户交流很好，内部交流也很好，项目做得非常成功，但当中没有使用任何用例图。

Ivar  Jacobson：这有点像哲学问题，是不是一定要用Use  Case，应该反问你一句，你刚才谈到内部的交流和外部交流都非常好，在内部交流的时候怎样确保交流之间的连接关系，你是怎样管理的？你有这么多人交流，连接关系是怎样的？外部交流有那么多外部关联关系，怎样把它拿到一起形成一个完整的图画，如果你真正在思考这两个问题、回答这两个问题的时候，实际上你已经自觉不自觉用类似于有Use  Case的想法，虽然没有把Use  Case的图画出来。所以Use  Case并不是让你觉得很困难的东西，它是非常符合直觉的东西，包括上午谈到从Use  Case得到测试用例，包括整个集成测试，实际上就是对用例的测试等等，像这些都是非常符合大家开发经验的直觉，而不是让你额外花很多东西要做的事情。

实际上，这是一个直觉，是每个人想的东西，用不用Use  Case是另外一回事，只是把它变得更系统化而已，把这个系统化以后，就把这个事情变得更加像流水线，同时给团队也带来很多价值。

潘加宇：下面进入第二个阶段，关于UP，统一过程，这个统一过程是成型的，当一个产品来卖的东西，这是Ivar的成就。现在又出现很多敏捷的思路，我想大家对统一过程和迭代开发有什么困惑。

钱岭：UP对于软件开发来说，难度比较高的可以用，难度低的不可以用，我想对于全新的系统是怎么用的？这个项目用了很多新技术，并不是一个发明创新的项目，并不是让过程引导发明创造，这不需要，我们自己可以想，但这怎样在过程当中把很多新项目集中在一起，是这样的意思。

 

Ivar  Jacobson ： 我们的理解是你在问一个创新型项目或者一个完全新的项目。每一个过程都能支撑你来做创新，但并不能帮助你做创造性的思考。

这个问题我还没有真正理解你的意思，我理解的是看不到RUP不能使用的东西是哪些？没有看出哪些项目不适用RUP。如果把一些新的技术组合一起，因为RUP可以加快整个开发的进程，实际上能够帮助你更快来推出。

潘加宇：我认为RUP的思想是一个迭代的思想，在每次迭代出来一个SQ的版本，这个版本可以显示给顾客，让售客看一下是否要求的需求？RUP的思想和人的认知过程是一样，人的认知过程对一个事不是马上认识，而是经过迭代来认识的，所以RUP是一个大纲，这是什么意思呢？它的大纲就是有很大扩展空间，可以根据扩展去思考和创作，RUP  Rose没有规定哪些图不可以划，也可以划，设计得好，就可以做得出好的东西。UML和Rose有扩大性，根据语言产生新的东西。

提问：RUP是否帮助我们解决一些风险性和不确定性的问题呢？规避新技术的风险？

Ivar  Jacobson：这中间会帮助RUP，它是迭代开发的东西。为什么统一过程能够帮助呢？因为统一过程实际上是一个迭代的开发模式，它把你的项目分为若干个小项目，每个小项目有两个星期到四个星期的实习时间。这样的话，应该能很好回答你刚才提到的高风险性的问题，在中间每一步迈得比较小，你的决策被分散到若干个小的迭代当中去。

中间具体操作是什么方式呢？比如刚才谈到我在用一个新的编程语言或者新的编程平台也好，就会当成一个很高的风险，类似的风险还会把全部风险列出来，然后回过头看Use  Case，哪些用例？我做这个用例能帮助我从某种程度解决或者规避左边画的风险，把用例识别出来的是最开始在迭代的时候要实现的问题。

提问：刚才说要讲RUP和敏捷开发，好象都没有讲到敏捷开发。以前有一种说法，RUP和XP这些东西属于矛盾的，RUP属于稍微重量级，敏捷开发属于轻量级的。但是我觉得从我这边的体会，RUP可能更像一个理论性，从理论上给它定了一些什么样的工程，是怎样进行的。但XP在实践当中比较有指导性，但中间有很多相重的地方，比如RUP是迭代开发，和敏捷持续开发有类似的想法，所以在这个过程当中，能否请Ivar先生讲一讲？我上午听了Ivar的讲座，当你听到需要敏捷方式开发软件的时候，是否意味着UP也是敏捷的一种方法？

Ivar  Jacobson：关于XP和统一过程，在目前有很多错误的理解或者对它的一些错误的观念，我在这里做一个澄清。在很多方面，XP和统一过程是非常接近的，刚才 那位 小姐提到重构是否跟迭代很像，的确是这样的，他们差不多是一个意思。Use  Case和用户故事是否很像，几乎是一个意思。在这中间讨论事情的时候，如果细心来看会有背后的思想基本是一致的。这里面有很大的区别是什么呢？统一过程中非常强调我需要首先把一个稳定的架构搭建出来。如果一开始没有稳定的架构，在后期项目会花更多钱甚至数十倍的架构弥补这个错误。另外一个方面，实际上更多是人性因素，极限编程谈到很多人与人之间的交往，仔细读统一过程的话，我们绝对不是说不关心人和人之间的交往，只是没有做那么深的强调。

我们讨论一个最大区别的话，作为XP和统一过程的话，中间真实的区别是什么呢？XP强调所谓的隐含知识，也就是没有明确表达的知识，这个知识存在开发人员的脑子里头，今天团队有这么多知识，就用这些知识，没有别的知识来帮助你。我们在统一过程当中的另外一个方式是表达出来的，这个知识不一定在团队当中已经存在的知识，可以通过学习和操练获得新的知识，这点是两种体系最大的区别。

在这种情况的话，我们所说的敏捷开发方法，大家知道有一个若干方法，刚才我提到XP比较多，针对的是整个敏捷开发的运动。敏捷开发的运动在这个思想上会给人一种感觉是什么呢？任何人都可以编软件，只要利用你现有的知识就可以了，可能给人造成的感觉就是在这几个大的原则下利用现有的知识就能获得成功。这个让大学生知道会比较高兴的，因为一出来就可以自由工作了。另外一些数不清的方法学的专家们可以定新的方法，这是它背后的一个驱动。

统一过程则不同，我们通过长期的工程实践发现和识别了一系列最佳实践，这些最佳实践最小的项目是好用的，最大项目也是好用的，从成功经验当中得出一系列知识，把这些知识明确表达出来和记录出来，这种方式和敏捷开发方式不一样，因为敏捷方式更多强调原则，没有真正把知识提炼出来，在形成体系的方式上是有区别的。作为统一过程来说，可以当成很大一本书，是非常丰富的知识宝库。

这个大的知识库有用吗？当然有好的方面，因为它是一个很好的知识结构，它也有缺陷的地方，这么大的知识库谁会去读一万页或者这么大的知识体。但这个地方关键在于哪里呢？做软件开发，作为开发人员需要有相应的知识，需要知识来装备你，这些知识能够帮助你真正的达到敏捷，当工程师掌握这些知识的话，开发是非常敏捷的，我想这是一个真正的敏捷。

在我最开始设计的过程中，我就知道只有10％－20％的工程师会真正来应用统一过程，为什么呢？因为统一过程太大了，是一个非常大的知识体。另外一个方面，必须要用一个非常严谨的工程方法来开发这样的过程，我把它当做一个很重要的产品来做，这个时候必须要有一套严谨方式把这套东西做出来，这套东西做出来一定是很大的东西。同时我意识到人们是不喜欢读书的，现在又找到一个新的解决方法，从而帮助大家更快应用这个过程。

1980年的时候，我提出用智能助理帮助你来开发软件，2000年，我成立一个公司Jaczon来实现这个梦想，这个公司开发出一个产品叫Waitpoint，这个产品已经得过Jolt奖，这个工具能够帮助你来识别用例，来描述用例，来帮助你设计，来帮助你做架构，来帮助你做测试等等，所以在这种方式下，智能助理的知识从而变为硬盘的知识，这种知识是作为一个辅助工具存在的。我认为这是比所谓鼓吹敏捷方法更敏捷的方式。谢谢。

潘加宇：第一阶段的时间就到这里，现在交给熊妍妍。