AOSD中文版：基于用例的面向方面软件开发

本书系统阐述了面向方面软件开发（AOSD）方法，AOSD的目标是通过使系统的功能需求、非功能需求、平台特性等诸多不同的关注点相互独立，实现更好的模块化，来构建出易于理解、易于扩展、高复用性、高质量的软件系统。AOSD将用例技术和面向方面技术有机结合在一起，为软件开发提供了一个切实可行的最佳实践集。本书还系统阐述了用例技术、AOP（面向方面编程）技术的特点和使用方法，以及实现用例与AOP结合使用的用例模块、用例切片等技术。并且通过一个现实世界中常见的“酒店管理系统”来展示了如何在项目实践中高效地应用AOSD方法。作者见解独到、精辟，不仅阐述了理论知识，还详尽说明了如何在项目的不同阶段中应用AOSD技术。这本书对于项目经理、系统分析员、系统设计师及广大开发人员，都具有很高的实用价值。本书前言译者序2000年以前，笔者在软件需求实践中，一直对如何有效地标识、组织、管理用户的需求感到十分的困惑。纷繁复杂而且拖沓冗长的“软件需求规格说明书”似乎一直没有起到它应该起的作用，如何才能够使得用户和开发团队之间建立更好的需求沟通呢？IvarJacobson先生提出的“用例驱动方法”让我找到了解决的方法。它使我们站在“用户的视角”来观察“将要开发的系统”，通过对零散的软件需求进行合并，抽象出参与系统的不同参与者（Actor），将一系列的使用场景进行抽象形成“用例”，从而清晰地勾勒出系统的框架模型。这样总结出来的需求，往往能够与用户产生共鸣，让笔者在实践中也获益匪浅。然而不久，第二个困惑又摆在了眼前，如何在“用例模型”（分析模型）的基础上进行设计呢？在从“用例描述”到“顺序图”、“活动图”的转换中，一直感到力不从心。所幸的是，Ivar先生提出的“Robustness分析方法”又让我走出了这块新的沼泽。通过控制类、边界类，以及简明、随意的Robustness图，使这种转换变得streamline（流线型）起来。遗憾的是，UML对Robustness图的舍弃，不知对多少实践者带来了这种困难。但当我对“用例驱动方法”应用得越来越自如的时候，又遇到了新的困惑。在实际的系统分析和设计实践中，我突然发现类、组件与用例之间的对应关系是交错的。也就是一个用例可能会涉及多个类或组件，而一个类或组件也可能参与了多个用例。这种交错与缠绕一度让我一度感到心力交瘁。我们刚刚通过用例实现的“松耦合”设计，却又在具体到类的层面、实现的环节再次“耦合”在一起了。怎么办？如何解决？虽然从《软件复用：结构、过程和组织》中能够领会到一些解决的方法，但是总感觉在实践应用中还是有很大的局限性。正是在这个时候，我从亚马逊网站上看到了本书。基于自己对AOP的了解，一看书名就让我感到无比的兴奋，心里念叨着“找到答案了，找到了！”。当找到一些更详细的资料和部分章节后，我确认了自己的想法，因此毫不犹豫地向CSDN的熊妍妍推荐了本书。在她的大力支持下，我终于看到了本书的全貌，答案浮出了水面：AOP为你提供了一种手段，可以将横切关注点的实现代码分离，并模块化成为“方面”。面向方面提供了一种组合机制，使得在编译时甚至是运行时，再将横切行为组合到预期的操作和类中成为可能。而在操作和类的源代码中则可以摆脱横切关注点，从而使程序更易于理解和维护。为了推进AOP的发展，本书作者提出了AOSD，其目标主要围绕着如何使整个系统更好地模块化。它包括使功能性需求、非功能需求、平台特性等许多不同的关注点更好地模块化，从而使它们之间相互独立。保持所有的关注点相互独立，将使你构建的系统具有更易于理解的结构，并且更易于配置和扩展，以满足涉众各种洐生的需求。如何进行AOSD？如何识别方面？何时用类而非方面？如何详细说明方面？这需要一个明确的系统化方法来帮助你进行AOSD。而事实上，已经有一种成熟的系统化方法。它就是用例驱动方法。它提供了一种明确的、聚焦于实现涉众关注点并给最终用户传递价值的开发方法。哈，和我的预想一样。用例驱动方法与AOP的结合，必将会引发一场软件开发范型的革命。而通过阅读本书，你可以清除用例驱动方法的认识误区，了解方面技术的基本概念，掌握应用用例（applicationusecase）、基础结构用例（infrastructureusecase）及用例模块等新手段的应用，了解如何结合二者实现弹性的架构设计。而且本书还为你指出了一条实践AOSD的通途，可以说这是一本从实践中来，又回到实践中去的好书。相信阅读过本书的读者一定也会和笔者有相同的感受，一定不要错过这本经典的好书。在此，我必须感谢参与了本书部分章节初译工作的周松奕（第11~14章）和吴兰陟（第15~16章）两位同仁；感谢CSDN的熊妍妍、博文视点的责任编辑陈兴璐，感谢她们辛劳细致的工作；同时也对参与了审校工作的IvarJacobsonSoftwareChina公司的专家们、UMLChina的潘加宇表示衷心的感谢，他们的工作使本书的翻译质量得到了很大的提高和保证。最后要感谢我的父母和妻子许高芳对我多年来的默默支持与鼓励。鉴于笔者水平有限，因此在此必须感谢每一位读者，希望能够得到您的反馈与批评。欢迎来信（xf@csai.cn）与我一起交流与本书相关，与用例分析技术、需求工程、系统分析以及设计等软件开发相关的话题。徐锋2005年10月于厦门紫荆园

　　IvarJacobson博士，是许多技术“之父”，这包括组件及基于组件的软件架构，用例，现代业务工程，以及Rational统一过程。他还是统一建模语言（UML）的三位创始之一。同时他也是关于这些方法和技术的五本畅销书籍的作者，以及两本关于UML的引领性书籍的合著者。Ivar博士是JacobsonAB公司的创始人，在该公司他与其女儿、合作者AgnetaJacobson共同开发一套开创性的新产品，它将包括支持软件开发的智能代理。同时他还是IvarJacotsonConsulting公司（IJC）的创始人，其目标是向全世界的开发团队推广优秀的软件开发实践。Pan-WeiNg博士，在IvarJacobsonConsulting公司（IJC）扮演了多个角色。Pan-Wei博士负责针对软件架构、用例、迭代开发、方面技术等相关技术的最佳实践定义、开发相关素材。这些工作通常要基于实践进行，才能够确保归纳的最佳实践切实、实用。Pan-Wei博士还积极地和客户一起工作，以确保这些公司和项目团队能够快速、安全地采用这些最佳实践。

序 xvii
致谢 xxxi
第1篇用例和方面的应用实例
第1章要解决的问题 3
1.1组件现在的用途 3
1.1.1使用组件构建系统 4
1.1.2组件的益处 6
1.2组件的局限性 6
1.2.1无法使对等关注点相互分离 8
1.2.2无法使扩展相互分离 9
1.3寻求解决方案 11
1.3.1对于扩展的早期支持 12
1.3.2UML对扩展的支持 15
1.4使关注点保持分离 16
第2章使用方面技术来解决问题 17
2.1使用方面技术寻求解决方案 17
2.2基于方面技术使对等关注点保持分离 19
2.3基于方面技术使扩展保持分离 21
2.4方法学指导的需要 26
第3章现在基于用例 29
3.1用例概述 29
3.2用例驱动开发 32
3.3用例的角色和益处 34
3.4用例技术的缺口（gap） 34
3.5基于方面来填补缺口（gap） 35
第4章将来基于用例模块 37
4.1通过叠加用例切片来构建系统 38
4.2使对等用例保持分离 40
4.3使扩展用例保持分离 42
4.4基于用例模块开发 45
第2篇基于用例捕获关注点并建模
第5章基于用例对关注点建模 51
5.1用例建模 51
5.2用例实例和事件流 53
5.3用例描述 54
5.4用例事件流的可视化 57
5.5总结与强调 60
第6章用例结构化 61
6.1用例关系 61
6.2用例扩展关系 63
6.3用例包含关系 70
6.4用例泛化 73
6.5公共用例 77
6.6总结与强调 79
第7章基于用例捕获关注点 81
第3篇基于用例模块实现关注点分离
第8章基于用例切片使对等用例保持分离 105
第9章基于pointcut使扩展保持分离 127
第10章基于用例模块构建系统 145
第4篇基于用例和方面建立架构
第11章通往弹性软件架构之路 167
第12章基于对等的应用用例使功能需求保持分离 187
第13章基于应用-扩展用例使功能需求保持分离 213
第14章基于基础结构用例使非功能需求保持分离 239
第15章基于平台相关用例切片使平台特性保持分离 263
第16章基于用例测试切片使测试保持分离 301
第17章架构评估 319
第18章架构描述 339
第5篇在项目中应用用例和方面
第19章运作一个项目 357
19.1迭代式开发 357
19.1.1项目中的阶段 358
19.1.2迭代中的活动 359
19.2估算开发工作量 359
19.2.1在项目之初进行估算 360
19.2.2对估算进行提炼 362
19.3项目的计划和监控 363
19.3.1项目延误估算 363
19.3.2使项目跟上进度 364
19.4保持关注点分离带来的生产率提高 365
19.5总结与强调 367
第20章方法剪裁 369
20.1实现正确的平衡 369
20.2选择应用的科目 370
20.3在项目的不同阶段采用 373
20.4总结与强调 374
第21章方面与超越 375
21.1在扩展（Extensions）上构建系统 375
21.2均衡各种最佳实践 376
21.3未来之路 377
附录A使用UML对方面和用例切片建模 379
附录B符号指南 387
参考文献 395
术语表 399
索引 407