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管理频道，实现你的卓越梦想！