基于代理的软件开发的组合机制和模型驱动开发的研究

理论计算机科学电子笔记114（2005）153-174www.elsevier.com/locate/entcs没有方面DavySuv'e1，WimVanderperren2，DennisWagelaar和Viviane Jonckers比利时布鲁塞尔Pleinlaan 2，1050 Vrije Universiteit Brussel，系统与软件工程实验室{dsuvee，wvdperre，dwagelaa，vejoncke}@ vub.ac.be，http://ssel.vub.ac.be摘要在本文中，我们声称，一个专门的方面模块是不需要的。相反，我们提出了一个表达面向方面的组合机制，可以应用于现有的模块。 在设计层，介绍了基于模型驱动开发的CoCompose建模框架。CoCompose允许从高级设计到最低级设计或代码级别的逐步细化。使用这些改进，CoCompose推迟了关于为特定关注点选择的模块化构造的决定。然而，在最底层的设计中，仍然需要选择专门的方面模块化构造，因为当前的面向方面技术通常引入方面模块。为了解决这个问题，提出了FuseJ编程语言，它允许将所有可能的关注点作为常规组件来实现。FuseJ引入了一种富有表现力的组件组合机制，支持组件之间的常规组合和面向方面的组合。因此，实现了从设计到实现的无缝过渡，因为在设计和实现级别都不存在专门的方面模块。关键词：基于代理的软件开发，面向代理的软件开发，组合机制，模型驱动开发。1作者获得了弗拉芒工业科学技术研究改进研究所（IWT或弗拉芒语“Vlaams instituut voor de bevordering van het wetenschappelijk-technologisch onderzoekin de2作者获得科学研究基金（FWO或佛兰德语：“Fonds voor Wetenschappelijk Onderzoek”）博士奖学金的资助1571-0661 © 2005由Elsevier B. V.出版，CC BY-NC-ND许可下开放获取。doi：10.1016/j.entcs.2004.12.012154D. Suvée等人理论计算机科学电子笔记114（2005）1531介绍面向对象的软件开发（AOSD）是一种新的开发范式，旨在实现比标准面向对象（OO）软件工程方法更好的关注点分离。AOSD声称，应用程序的一些关注点不能用标准OO技术干净地模块化，因为它们分散在系统的不同模块上或与系统的不同模块纠缠在一起。这样的关注点被称为横切，因为关注点实际上横切了系统的分解。因此，类似的逻辑在不同的模块中重复，从而导致代码重复。由于这种代码重复，从系统中添加、编辑或删除横切关注点变得非常困难。横切关注点的典型例子是调试关注点，如日志[15]和合同验证[30]，安全关注点[31]，如保密和访问控制以及描述业务特定逻辑的业务规则[6基于组件的软件工程（CBSE）是另一种软件工程范例，旨在提高单个组件和组件组合的可重用性CBSE提倡组件之间的低耦合和单个组件的高内聚。此外，组件是黑盒3实体，可独立部署[29]。事实上，当使用CBSE时，组件永远不应该显式地依赖于其他特定组件以增加可重用性。因此，CBSE极大地避免了横切关注点和混乱的代码，因为为了保持尽可能低的耦合，许多关注点在不同的组件之间分散和重复。因此，面向方面的思想在基于组件的世界中非常受欢迎。目前，有大量的技术可以将面向方面的思想集成到基于组件的软件工程中。例如JAC [21]、JBoss/AOP [13]、EAOP [9]、OIF [11]和JAsCo[28]。所有这些方法都致力于引入新的编程语言或框架，以模块化横切关注点。在基于组件的软件工程的早期周期中，对面向方面思想的支持仍然没有得到充分的探索。尽管存在几种生产质量的面向方面的技术，但是在例如设计过程中恢复面向方面的思想似乎非常困难。目前，当设计一个软件应用程序时，考虑到方面，关键的问题是：实际上，必须决定应用程序的哪些关注点3.目前对CBSE没有一致的看法例如，几个不同的应用程序，存在激励为什么黑盒、灰盒或白盒组件组合是更好选择的方法。在本文中，我们假设CBSE上的Szyperski视觉[29]具有黑盒组件组成。D. Suvée等人理论计算机科学电子笔记114（2005）153155将其建模为方面，并将其建模为组件。 在过去的几年里，所谓的“早期方面”的工作这项工作的重点是在需求工程和架构设计的早期开发阶段管理横切属性。尽管能够在早期开发阶段识别可能的横切关注点是一个重要的贡献，但开发人员仍然被迫选择特定的表达方式，因此必须选择特定的关注点。 AKKensisit等人[2]已经提出，这在软件演化时会产生问题，因为改变关注点的表示会对软件架构产生深刻的影响。例如，某个关注点最初可能被一个常规组件完美地模块化。然而，应用程序的需求可能会随着时间的推移而改变，因此作为组件模块化的关注点最终会被证明是横切的。这个关注点然后必须被重构为一个方面，这是一个繁琐且容易出错的任务。这个问题是由面向方面技术为了模块化横切关注点而引入的额外模块构造（方面）引起的。本质上，这些关注点的行为与非横切关注点的行为没有区别;只是组合机制不同。当引入单独的方面模块时，组合机制实际上与关注点本身的行为纠缠在一起。因此，其他组成机制固有地被排除。本文的主要主张是，一个专门的方面模块不应该存在。相反，我们希望将面向方面的组合机制应用于现有的模块构造。因此，软件组件不需要为了改变组合机制而被适配。为了支持这一主张，我们提出了一个建模框架，称为CoCompose，和一种编程语言，称为FuseJ。这两种方法都允许将组合机制与行为规范分离。CoCompose采用模型驱动开发（MDD）[16]，以便在通用设计元素上应用不同的组合机制CoCompose允许使用非类型化的通用概念将模型细化泛型组合概念也可以细化为常规和面向方面的组合机制。使用这些MDD细化，可以将特定实现结构的选择推迟到最低级别的设计。FuseJ是一种编程语言，它恢复了面向方面的思想，并允许将所有关注点实现为Java Bean。此外，FuseJ提供了一个强大的组合机制，能够描述面向方面和基于组件的组合。因此，新的合成机制尽可能不引人注目，例如。当表示软件时，156D. Suvée等人理论计算机科学电子笔记114（2005）153元素作为一个方法，应该可以将这个方法与其他方法组合在一起，就像它是一个通知一样。这允许推迟对特定组合机制的选择，并且还允许在现有软件模块上采用这种新的下一节将介绍CoCompose建模框架，并说明为什么显式的面向方面的组合机制在设计级别上优于单独的方面模块。然后，引入了FuseJ编程语言，它可以无缝地映射到CoCompose思想上.在第4节中，我们介绍了我们目前正在实现的支持CoCompose/FuseJ方法的工具支持。第5节讨论了相关的工作，这些工作也避免了为方面引入额外的模块化构造。最后，我们陈述了我们的结论。2设计级合成：CoComposeCoCompose是一个模型驱动开发框架，可用于逐步完善软件设计[33]此外，CoCompose可以自动确定要使用哪些细化替代方案。当前的OO设计方法，如UML [17]，并不显式地支持细化替代方案。设计的一个改进版本，从而过早地消除了其他可行的改进[2]。UML已经开始了一半的细化过程，因为它迫使开发人员选择一个特定的结构来表示设计元素（例如类，操作，包，属性，等等）。）的。CoCompose使用通用概念来表示设计元素4.第2.1小节详细解释了这些概念。每一个概念都可以有几个细化，在2.2小节中有详细解释。概念可以通过两种方式重用其他概念的精化：（1）它们可以从另一个概念继承精化，或者（2）另一个概念可以将精化复制到这个概念上。通过使用概念的精化，概念被用来以声明的方式对组合进行建模。该概念的改进更详细地说明了如何完成合成。最后，2.3小节解释了如何从CoCompose模型生成代码。2.1概念每个设计元素在CoCompose中被表示为一个概念。 概念可以参与关系，该关系指定它们与哪些其他概念相关联。第一个版本的CoCompose [32]使用了几个元素来表示设计，而目前只D. Suvée等人理论计算机科学电子笔记114（2005）153157相关.嵌套概念是包含在另一个概念中的概念。例如，名为AnInheritance的概念包含表示继承关系中的两个角色的Parent概念和Child概念。MyClass概念可以与AnInheritance概念的Parent概念有关系，这意味着它在继承关系中扮演父角色。这些关系如图1所示。Fig. 1. 将设计元素表示为概念UML语言模型可以被映射到CoCompose语言模型上，使得使用UML构造描述的设计元素具有Co-Compose表示。这种映射是在元模型级别上完成的：每个UML元素类型（例如类、操作、.. .）被映射到表示元素类型（例如，一个名为类的概念）。UML中描述的每个实际设计元素都映射到一个CoCompose概念上，该概念继承自表示UML元素类型的概念（例如，名为MyClass的类将映射到从Class概念继承的MyClass概念）。图2展示了一个用UML表示 该系统包括三个服务：预订服务，折扣服务和支付服务。预订处负责预订旅馆。折扣服务是一种通用服务，它根据特定于业务的属性分配折扣。支付服务允许从信用卡中收取费用以确认预订。这些服务由两个抽象协作组成：BookingDiscount，它将折扣应用于预订，以及BookingPayment，它在预订后触发付款。图二. 用UML表示的示例模型158D. Suvée等人理论计算机科学电子笔记114（2005）153每个元素映射到一个概念，这个概念可以从表示元素类型的另一个概 念 继 承 细 化 （ 参 见 2.2 图 3 展 示 了 BookingDiscount 协 作 和DiscountService概念的映射。 5BookingDiscount协作映射到从协作概念继承的概念，并且包含都从协作角色概念继承的DiscountService概念和BookingService概念。DiscountService概念已经被显式地标记为抽象概念，这意味着它不从任何类型表示概念继承图三. 将UML示例映射到概念2.2精炼概念每个概念都可以有几个细化，它们要么是模板设计，称为解决方案模式，要么是编程级别模板，称为实现模式，要么是可执行代码生成器，称为实现生成器。图2中的BookingDiscount协作有两个解决方案模式改进：一个使用标准的面向对象组合，另一个使用ApplyJ组合。图4显示了用UML描述的Booking-Discount协作的标准面向对象解决方案模式。它使用多个角色，作为模板参数。 角色使用“role”构造型进行注释。 在此解决方案模式中，指定了两个主要角色，即DiscountService和BookingService。当应用此解决方案模式时，DiscountService和BookingService角色将被链接到这些角色的概念替换。在图2中，BookingDiscount协作有两个与这些解决方案模式角色相对应的协作角色。 在本例中，BookingService角色由图2中的BookingService概念填充，因为它链接到BookingService协作角色。注意Booking-Service和DiscountService角色被建模为UML类。这意味着填充这些角色的任何概念都继承自Class概念（参见图3）。5请注意，图3中显示的继承关系指的是改进，而不是标准的UML类继承。D. Suvée等人理论计算机科学电子笔记114（2005）153159见图4。 BookingDiscount的面向对象解决方案模式解 决 方 案 模 式 定 义 了 另 外 两 个 角 色 ， bookHotel 和 getDiscount-Price，它们是嵌套的角色。被细化的概念不需要显式地包含bookHotel和getDiscountPrice概念。相反，填充包含角色的概念应该提供这些概念：例如，图2中的BookingService概念必须包含bookHotel操作6。每个角色都定义了一个多重性约束，它限制了一个角色可以填充的次数 。 例 如 ， 在 图 4 中 ， DiscountService 角 色 应 该 只 填 充 一 次 ， 而BookingService角色可以填充零次或多次。着色用于标记角色部分：所有与角色具有相同颜色的概念在每次填充该角色时被实例化一次。例如，为每个填充BookingService角色的概念创建BookingDiscount概念。BookingDiscount类的bookHotel操作具有Java的实现模式细化，如图4中的 注 释 所示 。 它 引 用了 模 型 中 的 其 他几 个 概 念 和/ 或 角 色 ， 例 如BookingService中的bookHotel和折扣聚合关系，这通过使用封闭的<>来 显 示 。 为 了 使 用 这 些 概 念 和 角 色 ， 需 要 为 实 现 模 式 定 义 诸 如“bookHotel必须是方法”之类的约束价格折扣是商业规则的一个例子。在文献中，业务规则已经被确定为横切关注点[6，20]。图5显示了BookingDiscount协作的ANOJ [14]解决方案模 式 UML 符 号 基 于 [24] 。在 ANOSJ 中 ， 一 个 aspect 用 于 实 现DiscountService概念。与面向对象的解决方案模式相比，ANOSJ解决方案模式避免了为DiscountService概念的每个应用程序引入子类。因此，DiscountService概念仍然是模块化的。这是一个6操作的参数类型和返回类型也应该标记为角色。 在示例中，为了保持清晰，省略了这一点。160D. Suvée等人理论计算机科学电子笔记114（2005）153然而，解决方案需要选择特定的方面模块构造。因此，最低的设计和实现级别仍然会受到组合机制与模块化结构纠缠在一起所引起在第3节中，介绍了FuseJ编程语言，以避免这个问题。图五. BookingDiscount的ANOJ解决方案模式图6显示了图2中BookingPayment协作的解决方案模式。它使用一个面向组件的BookingPayment粘合代码类，在触发ChargeEvent时调用chargeAmount操作见图6。 BookingPayment的解决方案模式使用解决方案模式的细化，设计可以细化到实际实现语言构造的级别（例如类和方法，但也可以是ApplyJ方面，切入点和建议）。图7显示了图2中的示例设计的面向对象的细化版本，图8显示了图2中的示例设计的ApplyJ细化版本。2.3代码生成代码生成过程基于先前CoCompose方法[32]中采用为了从概念生成D. Suvée等人理论计算机科学电子笔记114（2005）153161见图7。应用标准的、面向对象的解决方案模式后的示例模型见图8。 应用ANOJ解决方案模式它表示一种实现语言构造。例如，类概念的Java实现生成器生成Java类框架代码，并粘贴实现模式（如果有的话）。虽然Class概念本身没有任何实现模式，但从Class继承的概念可能有一个实现模式，并且可以重用Class实现生成器。不仅Java的模块构造（例如类，方法，. . .）有实现生成器，但也有组合构造（例如继承）。继承概念的Java实现生成器生成一个extends子句。由于Java的实现生成器对Java程序的结构有共同的知识当某些元素没有执行时，162D. Suvée等人理论计算机科学电子笔记114（2005）153定义了一个术语或实现生成器，则无法生成完整的代码，并发出警告。73实现级组成：FuseJ在上一节中，CoCompose提出了一种建模方法，允许通用概念之间的通用组合，这些通用概念可以细化为具体的构造和组合机制。然而，当传统的面向方面技术被用作细化目标时，组合机制仍然与最低设计或代码级别的基本行为纠缠在一起为了克服这个问题，提出了FuseJ语言。FuseJ的思想是将软件系统所需的所有关注点实现为常规组件，并引入一种表达性组件组合机制，该机制允许指定组件之间的常规和面向方面的交互。为此，我们提出了一种新的统一的面向组件的体系结构[27]，它在实现时、组装时和运行时不区分常规组件和面向方面的组件。在接下来的段落中，将介绍这种统一组件架构的第一个想法和概念。为了使我们的想法更具体，我们提出了FuseJ语言，这是一个实际的实现，统一的面向组件的体系结构到一个底层组件模型，在这种情况下，JavaBean。之后，我们将展示如何实现从设计到实现级别的无缝过渡，当CoCompose能够将其通用组合物细化到FuseJ语言时。3.1统一的面向代理的体系结构为了在实现层引入明确的面向方面的组合机制，提出了一种三层的面向组件的体系结构，具有组件层，门层和连接器层。组件是组件层的一部分，这些组件之间的组合（正则的和面向方面的）映射到门层和连接器层的组合上。图9描绘了这个三层模型的架构。软件系统所需的每个关注点都映射到位于组件层的组件上。它们的行为是通过一些基本组件语言来实现的因此，康-7生成的代码不打算由开发人员编辑：开发人员可以以实现模式的形式插入他的代码。D. Suvée等人理论计算机科学电子笔记114（2005）153163见图9。 统一组件架构现在将典型地通过方面模块捕获的CERN描述为常规组件。正如在介绍中已经提到的，我们认为这个组件层中包含的每个组件都是一个黑盒实体，它是独立于其他特定组件指定和部署的。组件层中包含的每个组件都包含许多服务，我们称之为功能。但是，组件提供的这些功能与组件的所有通信或来自组件的所有通信都需要通过位于栅极层中的栅极。门是组件的单个入口和出口点，提供对组件实现的某些功能的访问。因此，门可以被看作是组件内部的某种监护人。门被映射到组件内实现的一个或多个方法上。门被定义为双向通道。传入的通信具有以下特征：“执行门提供访问的组件的功能”。另一方面，传出通信具有以下语义：“当门提供访问的组件的功能被执行时这个“其他东西”取决于传出通信连接到的一些其他组件的门。传入和传出通信的概念允许门同时涉及常规组合和面向方面组合。例如，日志记录是通过方面模块实现的关注点的典型示例然而，在统一的面向组件的体系结构中，这种日志记录关注点是由常规组件实现的一个或多个门提供的。这种日志关注如何与软件系统中其他组件提供的功能进行交互（以常规或面向方面的方式）的规范并没有在门本身中指定，而是推迟到组件组合过程中。门之间的相互作用是通过使用连接器，这是位于连接器层。一个连接器将输出164D. Suvée等人理论计算机科学电子笔记114（2005）153一个（或多个）门的输入通信与一个（或多个）门的输入通信。连接器负责描述组件之间的常规和面向方面的组合，因为在组件和门实现中都省略了这一描述。指定常规组件组成的连接器与大多数组件模型中的连接器非常相似它们用于通过解决方法名或参数类型之间的不匹配来将两个组件的门粘合在一起。然而，连接器也能够指定组件之间的面向方面的组合。在这种情况下，它们对应的门以面向方面的方式粘合在一起。将面向方面的交互规范推迟到组件组合机制（在本例中是门和连接器），在实现级别上具有多个优点。组件的可重用性增加，因为组件开发者不需要在开发时决定组件是否应该以常规或面向方面的方式与软件系统内可用的其他组件交互。所有关注点都作为常规组件实现，并且连接器负责指定组件之间的交互如何发生。因此，组件的特性可以同时在常规组合和面向方面组合中重用。这个概念甚至允许在面向方面的上下文中重用现有组件。3.2实际实现：FuseJ本节介绍FuseJ语言。FuseJ语言通过将上面介绍的概念映射到现实世界的组件模型（在本例中是Java Bean），说明了在实现级别具有统一的面向组件的体系结构的思想。本文提出了一种简单的门和连接器原型语言.请记住，目前，这种简单的原型语言并不支持组件之间所有可能的面向方面的交互。识别和重新呈现这一组所需的相互作用是未来的研究。上一节介绍的酒店预订案例研究使用了三个组件：BookingService、PaymentService和Discount-Service组件。前两个组件提供常规组件功能，例如“预订酒店”或“向客户信用卡上收取特定金额的费用”。后一个组件实现一组业务规则，根据一组特定于业务的条件分配特定折扣。业务规则是通过方面模块实现的关注点的典型示例，因为特定于业务的信息通常D. Suvée等人理论计算机科学电子笔记114（2005）153165与软件系统的基本实现分散并纠缠在一起。然而，在FuseJ中，所有这三个组件都是作为常规JavaBean实现的，与它们是否涉及到常规组合或面向方面组合无关。酒店预订应用程序中的每个组件都提供有描述其提供的功能的门接口。 图10显示了上述三个组件的门接口的实现。门规范通常由两部分组成。一个模式部分，描述门在组件内部实现上的映射;一个暴露部分，暴露门的属性（输入参数，返回值，.）。）的。例如，BookingService组件的门接口提供两个门。BookHotel -gate的 模 式 部 分 （ 第 4 行 到 第6 行 ） 将 此 gate 映射到 BookingService组件的bookHotel-方法（第5行）。BookHotel-gate公开了inputHotelName属性-number 2（第8行），它表示作为输入给出的酒店名称。outputPrice属性（第9行）公开了门所映射的bookHotel -方法的返回值。类似地，ChargeForHotel门被映射到抛出的事件上，以便向客户收取酒店预订的费用（第13行到第20行）。为了将几个独立的组件组合成一个工作的软件系统，使用了连接器。这些连接器负责连接一个（或多个）门，并描述这些门应该如何组合（常规或面向方面）。酒店预订案例研究需要两个连接器才能实现其功能。 第一个连接器负责在某人预订酒店时执行折扣分配。第二个连接器负责在预订酒店时向客户的信用卡收取一定金额的费用。 后一种连接器是组件之间基于 组 件 的 常 规 组 合 的 典 型 示 例 。 BookingService- 组 件 抛 出 一 个ChargeEvent，PaymentService-组件在接收到这样一个ChargeEvent时需要采取正确的步骤。这个BookingPayment-连接器的实现如图11所示。连接器指定一个（或多个）门组合。门组合通常由两部分组成。一个连接部分（第3至8行），它连接两个门，以及一个映射部分（第9至14行），它负责指定有关门属性之间的映射。 在BookingPayment-连接器的情况下 ， Payment- Service- 组 件 的 ChargeAmount-gate 连 接 到 Booking-Service-组件的ChargeForHotel映射-BookingPayment -连接器166D. Suvée等人理论计算机科学电子笔记114（2005）1531 ginterface BookingService { 23gateBookHotel {4模式{5Float BookingService.bookHotel（String hotelname）;6}7曝光8String inputHotelName = hotelname;9浮点数outputPrice = returnvalue;10}11};1213gate ChargeForHotel {14模式{15void BookingService.fireChargeRequest（ChargeEvent事件）;16}17曝光18ChargeEvent chargeEvent = event; 19}20};2122}1ginterface DiscountService { 23登机口折扣{4模式{5Float DiscountService.getDiscountPrice（Float price）;6}7曝光8Float input = price;9浮点数outputPrice = returnvalue;10}11};1213}1 ginterface PaymentService { 23gate ChargeAmount {4模式{5void PaymentService.chargeAmount（String ccnumber，Floatamount）; 6}7曝光8String inputCCNumber = ccnumber;9int maximum = maximum;10}11};1213}见图10。 酒店预订应用程序负 责 指 定 某 些 门 属 性 转 换 ， 在 本 例 中 ， 是 ChargeForHotel- 门 的chargeEvent-属性在ChargeAmount-门的inputCCNumber和inputAmount属性上的映射。该连接器的结果是，每当客户预订酒店时，他/她都会通过PaymentService向其收费。BookingDiscount-连接器的实现负责实现D. Suvée等人理论计算机科学电子笔记114（2005）1531671个连接器BookingPayment { 23联系我们4PaymentService.ChargeAmount;5}6至{7BookingService.ChargeForHotel;8}9其中，10PaymentService.ChargeAmount.inputCCNumber=11BookingService.ChargeForHotel.chargeEvent.visaNumber;12PaymentService.ChargeAmount.inputAmount=的13预订服务.ChargeForHotel.chargeEvent.amount;14};1516}图十一岁描述常规组件组合的BookingPayment连接器将折扣分配给酒店预订价格，如图12所示.1个连接器BookingDiscount { 23联系我们4折扣服务.折扣;5}6在{7BookingService.BookHotel;8}9其中，10DiscountService.Discount.inputPrice=的11BookingService.BookHotel.outputPrice;1213}见图12。 描述面向方面的组件交互的BookingDiscount-连接器负责指定BookingService-组件的BookHotel-gate和DiscountService-组件的DiscountBookingDiscount-连接器负责指定面向方面的组合。面向方面的连接器的指定方式与常规组件组合连接器类似。连接部分现在指定了相关门之间的面向方面的交互。 在这个特殊的例子中，after-clause指定BookHotel-gate的返回值应该替换为Discount-gate的返回值。 同样，提供了一个映射部分，它将折扣门的inputPrice属性映射到outputPrice属性上在BookHotel的门口。此连接器的结果是为预订的酒店计算折扣价格。168D. Suvée等人理论计算机科学电子笔记114（2005）1533.3CoCompose回顾在第2节中，介绍了概念之间的通用组合，可以将其细化为常规或面向方面的组合机制。然而，概念是否应该映射到方面或组件上的决定在FuseJ中，软件系统的所有关注点都被描述为规则组件，并采用一种表达性组合机制来组合它们。因此，FuseJ简化了最低设计水平的细化过程。图13显示了BookingDiscount列的FuseJ解决方案模式。除了角色之外，还使用了几个特定于FuseJ的原型，例如连接器，连接和之后。图十三. BookingDiscount的FuseJ解决方案模式FuseJ解决方案模式展示了如何将图2中的声明式BookingDiscount协作几乎直接转换为FuseJ连接器。图4所示的面向对象解决方案模式被迫引入一个新的BookingDiscount类来实现组合。图5中所示的ANOSJ解决方案模式需要将DiscountService概念映射到ANOSJ方面，以便支持面向方面的交互。然而，在FuseJ解决方案模式中，CoCompose和FuseJ之间的直接映射是可能的，因为概念被细化为常规组件，概念之间的协作被细化为连接器。因此，FuseJ是CoCompose MDD细化的一个更容易的细化目标，并允许设计和实现之间更好的可追溯性图14显示了BookingPayment队列的FuseJ解决方案模式请记住，在FuseJ中，连接器还可以用于通过事件描述组件交互。图15显示了图2中示例设计的FuseJ细化版本。见图14。 BookingPayment的FuseJ解决方案模式D. Suvée等人理论计算机科学电子笔记114（2005）153169图15. 应用FuseJ解决方案模式4工具支持我们目前正在开发工具支持，以支持本文中阐述的方法。对于CoCompose建模框架，可视化绘图编辑器被开发为Eclipse IDE框架的插件[10]。这个编辑器明确地允许可视化CoCompose概念。 模型存储在CoCompose-specificXMI中[18]。我们仍在研究UMLXMI进口和出口未来，我们计划开发多个转换工具，以自动化优化步骤及代码生成。对于FuseJ，正在开发一组编译器，可实现门和连接器规范的编译。这些编译器将FuseJ规范转换为可以在FuseJ运行时基础设施中使用的常规Java类。为了实现这种运行时基础设施，我们考虑使用动态代理[25]。这些动态代理便于在代理服务器上创建代理类。给定一组接口，可以在运行时创建支持其中每个接口的对象。当代理接收到一条消息时，它将其传递给一个代理，后者负责执行一些额外的行为。 在我们的例子中，调用处理程序负责在几个组件。5相关工作最近，对象管理组织引入了模型驱动架构（MDA）标准。MDA形成了特定实现平台的抽象层它使用模型转换将高级设计（使用平台无关模型或PIM描述）细化为平台特定设计（使用平台特定模型或PSM描述）。可以定义多个分层PSM，以逐步完善设计。CoCompose适合MDA愿景，因为它也使用了几个分层的细化，这些细化是使用元级解决方案模式描述的。这些形成了中间平台模型（PM），定义了从平台无关模型（PIM）到平台特定模型（PSM）的转换。170D. Suvée等人理论计算机科学电子笔记114（2005）153在MDA的背景下，已经提出了一种基于图转换的方法来将UML设计模型转换为实现[1]。UM-LAUT [12]是一个通用的UML转换框架，例如，它可以该框架建立在UML元模型之上，并允许定义您自己的转换，这些转换可以存储在转换库中。UMLAUT不知道细化的概念，需要开发人员手动选择细化。UML模型也可以通过映射在CoCompose中使用这样，CoCompose机制就可以通过创建一个新的映射来应用于UML的在生成式编程[8]和逐步精化[4]中，特征和特征模型用于创建一系列软件系统，而不是单个系统。功能对于软件系统可以是可选的或强制的，这取决于其他功能的存在。CoCompose可以通过解决方案模式角色对可选特性进行建模，这些角色可以不填充。替代特征可以通过替代概念细化来建模。同样在实现级别，引入了几种不需要专门的方面模块的面向方面的技术。例如，多维关注点分离（MDSOC）旨在分解软件，以便它封装所有相关类型（维度）的关注点相似性，而不是一个支配其他[19]。MDSOC目前的实际实现是HyperJ for Java [20]。HyperJ在所谓的hyperslice中捕获应用程序的每一个关注点（横切或非横切）。 与FuseJ类似，HyperJ使用纯Java来描述超片，允许更容易地集成现有模块。超模块用于组成一组超片，以形成一个应用程序或新的超模块。从技术上讲，HyperJ使用字节码转换合并hyperslice，hyperslice本质上是Java类。在CBSE中，黑盒思想是非常重要的，因为它减少了不同组件之间的耦合，仅显式组件接口。因此，HyperJ并不符合基于组件的哲学。另一方面，FuseJ允许Java bean保持第一个类实体，即使在运行时。 因此，动态地替换或删除组件例如是不可能的。Composition Filters [5]是另一种非常不同的面向方面的方法。组合过滤器模型允许通过将过滤器附加到现有类来表达横切关注点。ConcernJ[23]是组合过滤器方法的实际实现之一，该方法将应用程序的所有关注点模块化为关注点构造。因此，不需要特定的方面构造。然而，ConcernJ语言确实引入了对现有代码的重大重构，以便能够模块化普通类D. Suvée等人理论计算机科学电子笔记114（2005）153171作为关注。FuseJ是向后兼容的，因为常规的Java Bean可以立即合并到该方法中。此外，与HyperJ类似，ConcernJ侵入性地改变关注点以插入横切BE。这个属性也使得ConcernJ方法不太适合基于组件的上下文中。侵入式软件组合是一种基于组件的方法，它统一了几种软件工程技术，如泛型编程，架构系统和面向方面编程[3]。入侵式软件组装的目的是提高软件构件的可重用性。为此，软件组件配备了显式和隐式挂钩。然后使用显式和单独的组合机制组合钩子。这些钩子实际上非常类似于FuseJ的门概念。然而，FuseJ中的门只能依赖于组件的公共接口，而钩子可以位于任何编程结构中。因此，钩子能够描述更精细的粒度级别，并且结果组合具有更强的表达能力。然而，与FuseJ相比，侵入式软件组合中的组件没有那么松散地耦合，因为它们能够相互依赖。从技术上讲，侵入式软件组合将组件合并到一个统一的应用程序中。毫无疑问，合并组件会产生非常有效的结果。缺点是组件在运行时会丢失它们的标识。FuseJ允许组件及其相应的连接器保持一流，即使在运行时也是如此。6结论在本文中，我们声称，一个专门的方面模块不应该存在。为了支持我们的主张，提出了一个建模框架和编程语言，不引入一个专门的方面模块 。 相 反 ， 它 提 供 了 一 种 强 大 的 组 合 机 制 来 支 持 面 向 方 面 的 组合.CoCompose建模框架基于MDD，允许从高级设计到最低级设计或代码级的逐步细化。使用这些改进，CoCompose允许推迟关于为特定关注点选择的模块化构造的决定。在细化中针对传统面向方面编程语言的缺点是，必须选择特定的方面模块，以便在这个细化的设计级别上模块化某些关注点。因此，引入FuseJ编程语言作为实现CoCompose设计的更好目标。FuseJ编程语言允许将所有关注点实现为常规组件，并提供支持面向方面组合172D. Suvée等人理论计算机科学电子笔记114（2005）153通过门和连接器。因此，即使在实现级别，也不存在单独的方面模块，并且实现了从设计到实现级别的无缝过渡。提议的FuseJ门和连接器语言只是我们想法的第一个原型。目前，FuseJ连接器的表现力还没有覆盖完整的面向方面的组合可能性，因为只支持简单的方面组合，比如before和after确定其他面向方面的组合机制是否以及如何在该模型中映射有待进一步研究。CoCompose方法的一个可能问题由于每个设计元素都可以有多个细化，因此可以使用多种可能的细化组合。针对Java、ConcernJ和JAsCo的第一个版本的CoCompose的 经 验 已 经 表 明 ， 可 扩 展 性 问 题 是 可 以 克 服 的 。 在 未 来 ，CoCompose/FuseJ的真实实验必须揭示这种方法是否可行。引用[1] Agrawal，A.，T. Levendovszky，J. Sprinkle，F. Shi和G. Karsai，通过模型驱动架构中的图形转换进行，在：模型驱动架构