|
面向方面建模用模型驱动开发(MDD)的方法来简化面向方面的开发。这种面向方面建模的方法包括在设计时使用面向方面的关键字注释UML面向方面模型单元以用于访问横切关系。特殊目标环境的面向方面代码在从UML到目标转换（target
transformation）时生成。文章的以下部分将引入用于MDD架构的面向对象设计，它为使用IBM? Rational? Software
Architect（以后简称，Software Architect）的AspectJ 和Java开发团队提供了一种新的软件开发方式。此构架可以让使用者很方便地为应用程序里的多种横切关系封装他们自己的基于AspectJ的机制，这些横切关系可以在设计建模期间引入到一个应用程序中。 面向方面技术是对用于访问横切关系却不破坏对象的面向对象编程的一个重要补充，现在，支持应用面向方面的工具越来越多，最有代表性的例子是AspectJ Development Tools (AJDT) Eclipse 项目，它提供了支持AspectJ的工具，因此面向方面所带来的好处也被更深入地了解。但是，为了能够利用此项技术，开发者仍然需要学习一种新的编程语法和方式。 面向方面建模使用模型驱动开发（MDD）的方法用来解决这个问题。建模者/开发者可以将面向方面技术应用于UML模型（典型的是类图）并且在UML 到 Java?转换的同时生成 相应的 AspectJ。建模者/开发者不需要了解任何有关面向方面技术的的知识，而仅仅需要制定将哪个方面应用到这个模型中去。 UML为设计师和开发者提供一个为面向对象系统和它们内部之间交互过程实现可视化的方法。如IBM? Rational Rose? 和Software Architect这样的建模工具了提供丰富的建模环境。 简单的说，模型驱动开发就是通过使用抽象的模型进行软件开发。应用软件和系统的模型在不同的抽象级别中创建，并且通过自动或人工的方式驱动低抽象级别的模型进化（图1）。这种软件开发方式的模型被认为是开发流程的一流工件。他们就好像软件开发活动中的源代码一样以位为单位。 图1. 应用软件开发项目中的典型模型 这个模型提供了一种关注应用软件中特定部分的关系而不依赖于其它关系的机制。比如，数据模型总是和持久数据（对象状态）以及它的结构有关。它与用户界面的动态行为无关，甚至和事务逻辑行为也无关。选择开发进程的不同模型种类来匹配特定的任务和行为，因此所有工作通常只关注分派任务的领域。这不仅让开发团队成员成为专家并且定义了一个分离工件和过程开发的方法。 例如，一个保留的用于事务应用程序的用例可以提供一个关于此用例的文本描述（易读的）。这个描述可以让团队中不是此技术领域专家的成员看懂。分析师可以使用呈现出应用程序行为的对象来对系统进行描述。在模型中使用包含保留实体的详尽规格和控制器类（用于实体管理）的程序表和类表把它们纪录成文档。这个被分析模型驱动的设计模型可以使用 EJB的多种接口实体，实现类，部署描述符以及对实现设计所必需的具体工件来实现实体。 设计模型抽象级别中，源代码的差别是很小的，以至于现成的代码生成器（转换）可以把模型转为源代码和配置文件，如图2所示。甚至在某些场合可以生成（当特定设计模式已被应用）行为（方法实体）。 图2. 将模型转换为代码 横切关系是一个跨越各个层次或子系统进行分享和展示的问题。例如，通常的关系包括：
传统的访问横切关系的方法包括插入API或框架，在开发过程中通过IDE和其它类型的自动操作引入。这也许会导致难以维持的代码，并会导致开发者的注意力从对象的核心事务功能性转移到关系的集成。 Aspects 提供了一个非入侵的解决方法用于访问横切关系。 对象在开发完成之后，方面将特定的关系行为引入到系统。当对象被编译后，它们的功能已被组合编排到运行代码中。只留下了没有被关系使用的对象事务代码。 方面功能可以通过多种方法编排对象的行为。例如，图3显示了一些对象方法的UML行为。我们把焦点集中在对象的代码和行为而不是任何横切关系。这些关系在其它对象或者在编排在主控制流程中的方面中执行。 图3. 一个典型对象方法的的控制流 在对象方法访问之前（图4）或之后（图5），方面功能都可以嵌入到所有的流程中去。方面还可以安置在对象方法的周围，在那里 方面可以选择决定绕开或激活目标方法（图6）。 图4. 在一个方法前被激活的方面行为 图5. 在一个方法后被激活的方面行为 方面自身的开发
用于MDD框架的面向方面技术使它可以很容易地让设计师封装以方面为基础的体系架构机制，所以普通的开发者——有些许或完全没有面向方面的有关技术技术——也可以在应用程序的开发过程中使用面向方面技术。 MDD是一个用于软件开发的方法论，而方面是为软件应用程序传达功能的方法。 两者相辅相成；然而在过去却总不会把他们想到一起。用于MDD框架的变相方面技术把两者结合在一起用于解决如何让大型开发团队在MDD使用过程中更便捷地发挥面向方面的优势。这里的关键问题在于那些想在应用程序中使用面向方面的开发者需要了解如何编写将方面与正在进行的系统部分结合在一起的面向方面代码。 架构师用UML进行系统实现建模典型的是在分析和设计的层面上进行的。在设计层面，软件设计师对想要建立的工件进行代码编写的态度是鲜明的，在那里，架构师把访问横切关系作为非功能需求访问的一种手段。 然而，为了记录在对象模型中的横切关系的使用情况，设计师经常需要创建详细冗长的文件以便祥尽描述对体系结构方面的考虑事项。然后，开发者需要理解这些体系结构方面的考虑事项，或者利用面向方面的技术——假设他们已经充分地掌握了这些技术——或者他们更可能使用一个更传统的方法比如刚才已经提及的API和框架。 把面向方面技术和MDD集成在一起解决了这两个问题。本文就介绍了这种机制，方面可以被引入到开发工作中——使用标准的文本建模符号——无需了解他们是如何创建的或者此项技术所需的最低技术要求。 最重要的是开发者(不清楚面向方面技术的细节)也可以标记那些与之前开发的面向方面有关的模型单元。当这些模型单元被实现(或者转换为代码后)，任何方面必需的粘合代码会自动创建，并和预先确定的方面进行结合。图7显示了一个类中几个操作的注释过程。这个类是一个操作的实现，并且仅仅具体的操作可以创建。在这个例子中getCatalog()操作模型元素用<<Log>>注释，而getCatalogs()操作模型元素用<<Cache>>注释。 图7. 使用方面关键字对模型进行注释 图8. 生成AspectJ代码 软件设计师可以基于面向方面的技术开发这样的一个机制，并且，面向方面技术应用于MDD框架包也是一个可以再利用的资产。这些面向方面已经几乎完成，但是几个对它们(指出定义在目标应用程序中的单元)的定义却很抽象。这很重要，因为——在目标应用程序生成之前——这些以面向方面为基础的架构机制就已经建立并且进行测试——只需要等待最终横切的确定，让目标应用程序中使用的方面进行具体化。这个横切定义只有在应用程序开始定义之后才会得知。 这些抽象的面向方面被封装，可以在开发者的工作站中安装使用。在那里，可以将它们应用在正在开发中的应用程序的特定的，离散的地点。开发者可以不用了解面向方面的技术并且通过选择模型单元(包，类，或者操作 )并且通过已安装的面向方面的UML标记这些元素来应用此面向方面的技术。在随后的代码生成转化的过程中，我们将在项目中引入开发前期的方面——或者包含它们的库，并且抽象的方面也会进行稍加具体的引申并安排到目标应用程序中去。 使用面向方面方法的最大好处是——可实现任何数量的架构机制，并且可以访问目标应用程序中不同的关系——可以在任何特定应用程序着手之前进行开发。它们可以在资源库中开发和储存，并且可以在日后开发项目过程中下载使用。其它的优点是那些非面向方面的开发者在正确的指引下可以在常规的MDD处理过程中使用面向方面的技术。不需要额外的技术——不需要知道目标和特殊方面的使用。 本文为Software Architect引入可用于MDD架构的面向方面技术。这是一个简单的架构，用于包装和开发以AspectJ为基础的架构机制和代码。可将此架构用于正在开发中的应用程序，在开发团队将面向方面应用于真实的项目时却无需掌握任何有关它的重要技术。它可以对向方面的机制进行开发并建立资源库，选择性地安装和应用于还在开发过程中的应用程序的特定部分。它可以使软件设计师和面向方面的专家与大型团队分享他们的经验与技术，可以让开发团队把全部精力放在设计和实行应用程序的事务及域的功能性。 |
