Ivar聊天实录：技术发展、职业生涯、AOP、UML2、RUP
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奖，这个工具能够帮助你来识别用例，来描述用例，来帮助你设计，来帮助你做架构，来帮助你做测试等等，所以在这种方式下，智能助理的知识从而变为硬盘的知识，这种知识是作为一个辅助工具存在的。我认为这是比所谓鼓吹敏捷方法更敏捷的方式。谢谢。
潘加宇：第一阶段的时间就到这里，现在交给熊妍妍。
Ivar聊天实录：职业生涯部分
熊妍妍：提到职业发展道路，我想在座的各位大多数都已经进入了30岁这个坎，在中国有“三十而立”的说法，请问Ivar，您在30岁的时候，对自己的职业生涯是如何规划的？现在有哪些目标实现了？有哪些目标没有实现？
Ivar Jacobson：一个基本出发点就是要跟从你的直觉，在我30岁的时候，我可以成为管理者，但是我没有，为什么呢？大家知道一旦走到管理阶梯的时候，是一个阶梯一个阶梯往上跑。不管在哪个层次，上面一个层次总是一个很差的老板，怎么办呢？我还是着眼于提高自己，我相信能把自己的能力提高到一个层次的时候，我能比所谓的管理人员赚更多的钱，最后事实也是这样，我比爱立信所有的管理层都多挣很多的钱。
熊妍妍：其实在整个IT技术领域，能像Ivar这样成为首富，至少有富豪称号的人也是屈指可数的，Ivar既能成为首富，又是大师，为什么呢？
Ivar Jacobson：这是关于激情，简短回答一下，你要对工作和生活都要有激情，在我整个职业生涯当中从来没有做任何基于钱的事情，没有跟着钱走，而是跟着我心中的目标，跟着我心中的激情走，这是非常重要的。举个简单例子，在组件技术刚刚发明的时候，当时是一个全新的技术，当时爱立信没有人说这是可以做的，这是有意义的。大家想的方式有点像对于一群盲人解释看东西是怎么回事，类似于这种问题，当时花了很多工夫做这种事情，遇到了很多困难，但是还是用不懈的努力坚持做下来。在这中间包括在中国开办公司，主要目标绝不是为了到这来领一笔财富，我已经足够富了，不需要获得更多财富，我主要的激情在于帮助人们获得成功，帮助软件企业或者软件团队获得成功，这是我最大的激情。在中国这样一个地方，做这样的事情是很有挑战性的，对我来说也是激发我激情所在的地方，正是因为有挑战，所以才会到这个地方。我也希望让其他人富有。
周坚：我30岁进的华为，在这之前我在市场做了一年，非常的累，感觉那一年做得很苦，我以前还做过一年开发，我是研究生毕业，学机械，找工作是机械工程研究师，还要有经验，但没有经验，还要写程序，当时学软件的人不多。做了两年软件开发之后决定想做市场，做了一年市场，当时还做过一点开发。做完市场以后又转做开发，这是一个成功的经历，我现在转为做管理，到2002年，是我最后一次做设计，这三年就没有做过具体开发工作，2002年的时候我也36岁了，我有一个师兄现在在我们公司，也在华为做设计，这也有，主要是觉得自己适合做设计。我师兄已经40多岁了，也有很多途径，但没有像Ivar出去开公司的想法，但他一直拒绝，他说感觉做管理不是自己的兴趣所在，因为他更关心技术，虽然很吃力，因为做软件这行跟别的不一样，软件这一行得天天看新东西，但有些东西是要积累的，特别是在背景比较长的行业，比如通讯业，资源是有连续性的，我觉得主要还是看自己喜不喜欢，喜欢，进入这个行当，在中国也可以干得很长。但是从收入来讲，比转做管理的，发展起来更快一点。但是做管理层上去更快一点，而做技术的，要慢慢的往上走。
青润：中国软件企业很少有培训和发展的机会，相对看到国外进入中国大陆的企业，有IBM、惠普等都给员工提供培训的机会。Ivar成立的公司有没有提供更多培训，从而帮助技术员水平的提高。就像Ivar所说的不是单纯致富，而是帮助别人赚钱。
Ivar Jacobson：这个中间是这样一个关系，像今天的公开课大家都来了，我可以去大学做一些演讲，完全都是免费的。如果是两个星期或者一个月，对技能真正有提高的课程的话，会请美国或者欧洲最好的讲师到中国开办课。在开办课的过程中，这些讲师本身要拿工资，他们的工资都是很高的，在这种情况下，作为公司本身没有办法。但是有一种可能性，就是政府提供一些资助，把课程的费用进一步降低。
熊妍妍：刚才谈到从技术到管理的道路，也谈到职位，在座各位专家如果按照职位来讲，郭眈的衔头是最大的，仅次于总裁，请谈一下你个人发展的经历？
郭眈：我在百度做搜索引擎，说实话，我在公司，举个例子，百度来了一个新软件，部门的成员跟我们一块儿开会，我们问他谁还没来，就说周总出去了，我就访问他周总是谁？在百度里没有叫什么什么总或者什么什么的称呼，别人叫我郭总，我说不要叫郭总，叫郭眈就可以了。在百度来讲，从我个人来讲虽然做技术总监，包括我和我的组员的沟通是很平等的沟通，不像刚才Ivar所说的楼梯，谁在上面谁在下面。
说一下我的个人发展过程，我是在98年硕士毕业，在学校里呆了两年，我进入百度之前实际上对自己的发展规划是很浑沌的状况，我大学以后读研究生，读研究生之后又读硕士生，没有参加过公司的招聘会或者面试会，我有一个朋友看到网上招聘的广告，说两个从美国硅谷回来的人想在国内做一个公司，说你没事跟我一块儿去吧，我就去了，那时去我也没有带简历，也没有当成是面试，就想认识两个人聊一聊，后来幸运的是我被他们看中了，下午的时候，那两个人当中一人给我们打电话，说你对我们做的这个东西感觉怎么样，想不想再聊一聊？我说我对你们做的搜索引擎很感兴趣。我很赞同刚才Ivar说的那一句话，你做事情的时候有激情在里面，我当时觉得对搜索引擎很感兴趣，在座各位都是做软件出身的，如果做一件别人没有做过的产品出来，而且很酷，你自己很会有成就感，想做这样的事情，当时我就是这样的事情。
当时中国只有搜狐做搜索引擎，而且是目录式的网站搜索引擎，如果我做出一个搜索引擎，是NO.1，是中国第一个人做搜索引擎，我会觉得特别的自豪和骄傲。那时候我就加入百度，大概过了一个星期还是两个星期就动手写百度搜索引擎第一行代码，我想重申一句话，我觉得激情和兴趣是很重要一点，如果你想在自己的职业上和发展上有更高发展和更高投入的话，一定要找准自己的兴趣点在什么地方，你只有有了兴趣才能花无穷的精力，投入时间，甚至牺牲你
我说一下从技术路线走到管理路线时的一个想法，一方面感觉到自己的工作得到认可了，另外一方面发现老板其实挺坏的，他让我当经理，实际上是把他手上的一些事情扔到我这儿来管，做计划安排和人员招聘，都让我来做了，后来他发现我负责的事情越来越多，原来做一个产品，后来做两个，以至于有很多产品让我做。我最主要的体会是责任越来越大，肩上担子越来越重了，为此我可能付出越来越多。比如原来晚上加班到七点，以后加班到九、十点钟，到最后甚至周末都要加班。以前我参加了一个活动，一个工程师想从技术路线向管理路线走的话，一定要确认你自己能承担起这么大的责任。中国有句古话“兵熊熊一个，将熊熊一窝”，我想这是很大的责任体会。下一步的职业规划，我希望在今年内把什么东西做出来，我在今年要完成什么目标，做完什么工作。
我很早就仰慕钱岭的名头，名片上写着高级研究员，我想钱岭在技术方面继续深造的典范上，还是把时间交给你吧。
钱岭：每个人有不同的想法，从程序员走到管理都有一个发展的机会。前一段时间朗讯公司在裁员，事后我碰到一个人，我就问他，他说挺紧张的，我说为什么紧张呢？不能把自己看得更开阔吗？当时开发人员有一个特点，就是做一个东西总是在重复，没有做新的东西，把自己圈在一个很小的地方。我想自己做资源的话，要学增值和保值的技术，有些技术是既不增值也不保值，就是重复。相反，一个增值的技术，Ivar发明的技术，他学的知识就是不断增值的技术。
熊妍妍：在民间钱五哥这个名字很响，就像郭眈那样，你有这么一个好的名声，是否偶尔有过自己做的想法呢？
钱岭：有过。但没有冲动的原因就是觉得自己积累得还不够。我想继续念书，做了一些前期的准备，但还是没有做，在清华混了五年，从朗讯行业到通讯行业还有很多新的东西要学，总觉得有学不够的知识，我虽然说学一些增值保值的知识，但也学了一些垃圾性的知识，把时间给浪费了。我很羡慕潘加宇。
潘加宇：刚才说有冲动，我觉得这不是冲动，不管是创业也好，上班也好，这是很严肃的事情。没有冲动，冲动是做不了事情的。激情是有的，激情是伴随一个人的一生，有些人一辈子追求的是看到社会变得很好，希望Ivar的软件公司能力改善的效率等，这是要有的。激情不属于冲动，但做事是很严肃的，我也是打工，然后跳槽，我现在31岁，我是89年的大学生，我毕业做程序员，然后自己做，我觉得首先是自己要学到有用的东西。另外，对自己应该做什么和不应该做什么，应该有自己的优势。有些东西很能赚钱，我在《程序员》里有一篇故事，被删除很多字，里面写了即时贴，我看到网页可以知道分类，有点像百度的帖发，比如搜索“刘翔”，就会有很多帖发。那是99年的时候，后来为什么没有成功呢？因为有钱赚，但有风险投资。给我的启示就是如果你没有热情，虽然房地产有钱、儿童用品有钱，我去做就没有意义了，因为世界上聪明的人太多了，如果网络游戏有钱，我去做，但如果你没有热情的话是竞争不过别人的。帮助软件开发用例的方法，把它用到项目当中来，我是有热情做的，既然有热情就不怕任何竞争，为什么？因为可以面对任何挑战，Ivar来了，到中国开公司。如果Ivar请你帮他们，我非常热情，为什么呢？因为我做的事情是第一线的问题，所以还是要找准自己的位置，这是我的一点启发。
熊妍妍：刚才谈到职业选择已经谈到很多次，在面对选择的时候，一定要挖掘自己优势的地方，做和别人不一样的东西，这样在挑战过程中就能把握住自己，所以我觉得他的成长经历给大家还是有借鉴意义的。
刘清富：我觉得这是讲软件职业发布的事情，属于技术的领域，在一个组织当中有很多人会走这条道路，特别是那些极具富有天才创造力的工程师，以前在这方面做的是一个典范。我想问钱岭的是，你的老板怎样使你的价值得到增值？对富有天才创造力工程师的建议？
钱岭：我并没有怎么增值，有两个原因。当时我刚去的时候，开发部有一个项目做软件评估项目，老板问我是否去？说不管。软件评估做了一年多，在技术上得到了承认，当时在开发部做了一个项目，在研究院做了一个项目，老板给我最大的增值就是给了我空间。时间上是靠时间，老板没有给我时间，项目压得很紧，而且还照样要做。对于工程师的建议，我觉得要多承担公司的责任。朗讯做产品线当中，每个人只是一个小零件，这个小零件，也许用旧了，用老了，换一个新的来做这很常见，产品生产就是这样的，软件开发也是产品生产的过程，新旧更替，怎么让别人替不了你，这是重要的。怎样做一个金饭碗，就是要学一些增值保值的知识，这也算我的一个建议吧。
我想问Ivar博士，还是关于技术职业发展的问题，Ivar做PHD的时候，很大一块是在工业界来做，在研究学术界当中，UP是学术界，包括也是工程界的事情，您是怎样处理自己的研究和工程？您觉得哪一个更重要？
Ivar Jacobson：我个人的经历是这样的，在得到电子工程硕士学位之后我加入了爱立信，在爱立信工作期间发明了包括序列图的技术，这些技术是组件技术相关的方法，在那当中发明的。爱立信发现了这是一个人才，以半工半读的方式到学校深造获得了博士学位，1985年获得了博士学位。获得博士学位，对我后来职业发展生涯帮助很大。上博士学位的时候，才真正用数学方法形式化以前的方法，对以后UML的定义等等工作打下一个坚实的基础。在这中间，有一句话是这么说的，“没有什么东西可以比一个好的理论更实际或者更接近实践”。
AOP：分离关注点
《程序员》：很高兴在两年以后又见到您。您和我们《程序员》杂志也算是老朋友了，作为对老朋友的问候，想请您聊聊这两年间做了一些什么事情，并介绍一下您的近况。
Ivar Jacobson:谢谢大家的关心。这两年我主要从事有关AOP的研究，并在这方面写了一本新书《Aspect-Oriented Software Development with Use Cases》，这本书下个月就会出版了。另外，今年我开办了一家软件咨询顾问公司，在新加坡、美国、欧洲和韩国都有分支机构，目前正在筹备在中国开设分公司。
《程序员》：您提到对AOP的一些研究，能否简单介绍一下AOP技术？
Ivar Jacobson:实际上AOP思想的产生已经有很长时间了，早在1986年，我就写过一篇关于AOP的文章。说到底，AOP的核心思想就是在编程的时候把各种特性分离，在这一点上，它和Use Case有共通之处。所以，本质上来讲，AOP和Use Case技术非常地相近。
我可以举一个例子说明AOP的作用。如果有一个非常大的系统，其中大概有1000万行的代码。假如你要给这样一个应用系统加上“身份认证”的功能，那么每一个交易都需要修改，改动是非常大的。也许“身份认证”这个新特性也就是一行、两行的代码，但把它放进1000万行的代码就会造成其它部分需要大量的修改。这会消耗相当长的时间，而且会具有相当的风险。
所以，我们用另外一种思路去对待这种情况：我们不去动那1000万行的基本代码，只是把“身份认证”的功能放进一个独立的小模块，然后再把这个小模块“织入”其他的功能模块中，让它发挥作用。这样一来，修改的工作量就变得小多了。这只是AOP的一个最简单的运用。
《程序员》：在目前的J2EE应用里，AOP通常应用在事务管理、安全性、远程调用等方面。除了这几个方面之外，AOP还能应用在什么方面？
Ivar Jacobson:实际上AOP不光是可以用在刚才提到的那些方面，它可以用于整个软件开发的生命周期，比如说像业务建模、需求管理，这些阶段都可以用上AOP相关的技术。AOP还有助于发现生命周期中各个阶段的模式（pattern），这对于任何一个阶段都是很有意义的。
《程序员》：您认为AOP的核心概念是什么？是拦截器吗？还是别的什么？
Ivar Jacobson:我想AOP的核心概念是分离关注点（separation of concerns）——如何把项目各方关注的问题分离开。尤其是那些横切性（crosscutting）的问题，例如事务管理、身份认证之类的，如何把它们分离出来并模块化，这就是AOP的核心概念。至于拦截器、过滤器什么的，那些都是具体的实现技术。如果你只盯着这些实现技术，难免会错过AOSD的关键所在。
《程序员》：那么落实到实现技术，AOP的实现手段有哪些？它们有什么优点和缺点？您个人比较欣赏哪种实现？
Ivar Jacobson:眼下最流行的AOP实现应该是AspectJ了，有很多相关的范例和资料可以参考。AspectJ的实现方式是对Java语言加以扩展，所以你必须学习一些新的语法才能使用它。也有一些实现技术不修改编程语言本身，而是在外部加上XML格式的部署描述符。如果使用这些实现，你不用学新的编程语法，不过就得去学习它们的XML格式和语义。而且，aspect的思想不仅仅可以运用在编程的层面，很多层面都可以运用，所以很难说哪种工具“最好”，你必须针对自己的需要选择合适的工具。
《程序员》：您的意思是，除了编程工具（例如AspectJ、Nanning、JBoss AOP之类）以外，还有别的aspect工具，是这样吗？
Ivar Jacobson:如今AOP的编程工具确实发展很快，比如Spring框架，我觉得就是很好的工具。不过早在这些工具出现之前，我们就一直在努力保持关注点（尤其是横切关注点）的分离，比如说用Servlet过滤器（filter）来处理日志、安全性检查等横切性问题。当然了，这种实现不够好，因为它只提供一个切入点，也就是doFilter()方法。但不管怎么说，这也是处理横切关注点的一种办法。
再比如说，在做网络性能测试时，我们常常会在客户机和服务器之间放一台代理服务器，它负责记录客户机和服务器之间传递的消息，并在屏幕上回显。这也是一种以非侵入性的方式处理横切性问题的做法。总而言之，AOSD最重要的概念就是分离关注点。只要你始终记住这一点，具体的工具就问题不大了，你总可以想出合适的办法来解决。
《程序员》：那么AOP又如何与Use Case结合呢？
Ivar Jacobson:从根本上来说，Use Case就是对软件项目参与者关注点的建模。在设计阶段，我们把来自不同参与者的Use Case组织为切片（slice）的形式，这些切片就可以用AOP的方式实现，并组合成为完整的系统。你可以去看我们的新书《Aspect Oriented Software Development with Use Cases》，这本书的前言部分就介绍了对这方面技术的概述。
再说得具体一点，aspect可以用于保持Use Case的独立性，不管在设计阶段还是实现阶段都是如此。aspect可以：
1. 保持Use Case彼此分离；
2. 保持Use Case与领域模型分离；
3. 保持功能性需求与非功能性需求分离，或者说，保持应用逻辑与基础设施逻辑分离；
4. 保持应用逻辑与平台特性分离；
5. 保持测试与被测对象分离。
“分而治之”一直都是软件开发的核心思想，AOP只不过为我们提供了另一种“分而治之”的方式。从这一点来说，它没有什么特别的，也没有什么神秘的。
UML 2.0：庞大与混乱
《程序员》：请问UML 2.0有什么重要的新特性？和1.0有什么大的区别？
Ivar Jacobson:因为UML 1.0是比较久远的版本，很多方面都比较初级，而且UML的正式投入使用也是从1.1版本开始的。如果要和2.0相比的话，应该用1.5的版本来比较才公道。
全部的UML 2.0新特性，我记得并不是很清楚。不过总而言之，UML 2.0是非常大的一个语言，里面加入了非常多新的特性，比如说对于分布式系统和实时系统都加入了支持、加入了“端口”（port）的概念，还加入了一些其他的标志性符号。尤其是在序列图（sequence diagram）加入了很多的特性，使它可以描述更复杂的、可能包含并发的时序。
《程序员》：有这么多的改进，UML 2.0会不会变得过分庞大、过分复杂？
Ivar Jacobson:似乎外界普遍认为UML 2.0有些过于庞大，但在我看来，它还不够大。UML的庞大是有原因的：开发者确实有很多的问题，需要一个比较大、比较完整的语言才能清楚地描述这些问题。
至于UML 2.0是否太复杂，我想问题不在于语言的“大”和“小”，而是在于你学UML 2.0的过程：你有没有一些好的方法，或者有没有得到合适的协助。我建议可以循序渐进地来学习，从比较小的模组开始了解UML 2.0是比较好的方法。另外，也可以求助于一些工具，例如我开设的Jaczone.com网站就提供了很多这方面的帮助。
《程序员》：两年前您曾经着重提到“可执行UML”，并认为这是未来的技术趋势之一。现在两年过去了，现在可执行UML的发展情况如何呢？
Ivar Jacobson:可执行的UML并没有如我所预期的发展，最大的原因是这里存在着不同的标准。“如何从UML翻译到软件代码”，在这方面不同的厂商有不同的做法。现在看上去，大概有三种途径都可以从UML快速转到代码，IBM、微软和Borland都有自己的一套做法。但是，这几家最终没有达成共识性的东西。所以，可执行的UML作为标准提出还有待时日。
实际上MDA（模型驱动的体系结构）面临的状况和可执行的UML也是完全相同的：由于各家厂商在标准上还没有达成共识，对开发人员和最终用户来说还没有统一的、可以放心使用的解决办法。虽然IBM一直在倡导标准、倡导开源（例如Eclipse），但我担心，其他的厂商未必会沿着IBM的路线去走。
方法学：继续苦读RUP
《程序员》：现在敏捷方法在中国开始逐渐流行。作为RUP的创始人，请问您对敏捷方法有什么看法？
Ivar Jacobson:敏捷方法的代表XP是以代码为核心的一种方法，这里有很多的东西是未知的，知识只存在于两个地方：开发者的头脑和最后的代码。而RUP则不同，它更强调知识的收集、知识的表现和知识的定义过程。只有经过这个过程，知识才是可用的，所以，这两种方法是有区别的。
再具体一点，敏捷方法更侧重于个别的领域。在每一个领域做软件开发的时候，可能会用到不同的知识，使用敏捷编程的时候，做的每件事都是很具体的，出现的问题不带有共性，很难从不同的项目中抽取出来公共的东西。但统一过程（Unified Process）则不同：它首先强调对知识的收集、整理和加工定义，强调在软件开发的时候要有好的体系结构。所以它更有利于知识的积累和共享。
《程序员》：那么对于中小企业，应该如何利用RUP来提高效率？
Ivar Jacobson:很多小公司里有很多出色的开发人员，他们常常能创造出自己的方法。可因为这些方法掌握在部分优秀人员手上，当他们离开了，他们的方法也特别容易失效。照我的经验，即使公司只有5个人，也应采用UP，这样才能保证公司的成长不会让开发方法失效。
小企业、小团队应该怎么用UP？不是把UP全盘照搬过来，而是要对它进行剪裁，在里面挑选一些适合当时产品规模的部分来使用。UP中最重要的部分我认为应该是：（1）Use Case；（2）单元测试；（3）迭代式开发；（4）分层架构。对于小型企业，首先做好这四件事，开发过程就有了基本的保障。
《程序员》：除了规模普遍较小之外，您认为中国软件工程和其他国家还有什么不同？
Ivar Jacobson:我发现中国和国外最大的差别就是中国的软件开发人员都非常年轻，软件从业人员平均年纪比西方年轻十岁以上。这里不乏非常聪明的软件开发人员，他们开发的速度和热情是非常惊人的，但他们不见得有非常深厚的经验。所以，现在国内的软件企业普遍有一个现象，就是开发的速度可能非常快，可是开发软件的成熟度还不足。在这个阶段，这些企业尤其需要引入像UP这样成熟而且具有可操作性的方法。
《程序员》：请您介绍一下学习RUP和UML的资料？
Ivar Jacobson:在这方面我有两个建议。首先就是《统一软件开发过程》那本书，那是学习RUP的最佳教材，内容非常的详尽。另外，在网上有许多RUP和UML的参考资料，尤其是在IBM的网站可以找到成百上千关于RUP和UML的文章，那是一个很好的资源库。
《程序员》：最后，请您给中国的程序员说一句话。两年前，您说的是“让中国的开发者赶紧去学习RUP”，这次不能再说同样的话了。
Ivar Jacobson:好的软件来自于聪明的开发者，聪明的开发者来自于有能力的编程人员，有能力的编程人员需要更多的经验以及方法来支撑他。要有更好的软件开发的经验和方法，一定要继续苦读RUP。继续苦读RUP，这就是我给中国程序员的建议。
轉自CSDN
推荐到鲜果：
评论