面向方面编程和逻辑元编程在遗留业务软件中的应用分析

理论计算机科学电子笔记166（2007）63-80www.elsevier.com/locate/entcs面向企业的遗留业务软件克里斯·德舒特，布拉姆·亚当斯{Kris.DeSchutter，Bram.Adams}@ UGent.beGhislain Ho Mingman软件工程实验室，INTEC比利时根特大学摘要这篇文章涉及到第一次尝试，看看面向方面编程（AOP）和逻辑Meta编程（LMP）是否可以帮助振兴遗留的业务软件。通过逆向工程、重组和整合等四个实际案例的分析，讨论了面向方面的范例在遗留环境的两种主要编程语言的上下文中：Cobol和C。关键词：AOP，LMP，遗留软件，演化。1引言这篇论文讨论了面向方面编程（AOP）[8]和逻辑元编程（LMP）[16]技术的结合是否真的有助于振兴遗留业务软件的问题这种假设可能是这样的（细节见第2节）并不是一个新的假设。 例如，它是作者参与的ARRIBA1 理由是，使用方面，人们可以从外部对原始遗留应用程序进行仪表化、转换或修改，而不必以任何特殊的方式准备它们。这开辟了一条道路-或者说是另一条道路-逆向工程，重组，集成，错误修复，一般的维护等。虽然将AOP应用于现实生活中的遗留应用程序的想法是一个令人信服的想法，但还没有真正的案例研究（见下文）可以做到这一点。虽然已经有了一些关于“遗留”OO代码的实验我们认为这很可能是由于缺乏可用于此类环境的AOP实例化。虽然第一作者1ARRIBA：业务应用程序重组和集成的架构资源;由IWT-Flanders赞助的GBOU项目。更多信息请访问http://arriba.vub.ac.be/1571-0661 © 2006 Elsevier B. V.在CC BY-NC-ND许可下开放访问。doi：10.1016/j.entcs.2006.08.00264K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）63已经朝着“AZERCOBOL”的方向取得了进展（参见[ 9 ]，与R al f L aümmel合作完成的工作），这意味着您在实际应用中的所有可用性都不存在。遗留C应用程序的情况稍微好一些，因为有许多不同的可用AOP实例[1]，但在这里，AOP在工业遗留代码的实际问题中的应用仍然处于起步阶段。因此，本文采取了不同的方法来验证我们的假设：我们试图写下几个虚构（尽管现实）案例的方面。我们的想法是，如果假设成立，我们至少应该能够处理这一步。因此，本文认为，有效性的必要条件，而不是充分的。为了使这个实验最好地工作，这里提供的例子将有非常不同的范围，对应于ARRIBA第一个（第3节）将是逆向工程，其中方面被用作一种使能技术。第二部分（第4节）将讨论业务逻辑的恢复。第三个示例（第5节）将处理业务应用程序的封装，当希望将这些遗留应用程序集成到面向服务（SOA）环境中时，这应该是有用的第四个也是最后一个例子（第6节）将集中在维护/错误修复问题上，使用Y2K错误作为例子。应该指出的是，我们已经能够在一个真实的案例研究中测试出第一个问题，我们将在本文中报告一些主要的发现。其他人还没有得到这种验证。2假设业务应用程序是特定业务流程的实例化，因此它们非常容易受到其演变的影响。随着企业全球化的不断发展，以及对公司之间互联性的需求越来越大，扩展和集成业务应用程序的压力也越来越大。除了在集成不同的业务模型及其相关业务流程方面的困难之外，让业务应用程序进行协作也是一个主要的难题：除了少数情况之外，这些应用程序的文档和支持都不充分（甚至不存在）。一般来说，数据存储库和运行的程序提供了它们实现的信息结构和应用程序的唯一因此，这些应用程序的实际数据和源代码构成了唯一可靠的文档。合并业务应用程序总是需要应用人的经验。不幸的是，在对其资产了解甚少的环境中，这种专门知识永远无法得到充分利用。作为ARRIBA项目的一部分，我们关注于如何将新兴的AOP范式（与LMP相结合）应用于此问题。AOP认识到所谓的横切关注点（CCC）所引起的问题，并试图解决它们。简单地说，一些关注A是横切w.r.t.另一个（B）如果AK. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）6365（混合）与B的实现（更多细节见[14]等）。这些症状不能在传统的范式中自然地处理，如OO或过程式编程，因此程序最终成为复杂，脆弱的结构，难以维护，进化甚至理解。除了精确指出CCC的存在之外，AOP还使用所谓的方面来处理它们。这些是专用于一个CCC的单独模块（通常）。它们包含一个或多个更小的“ad- vice”结构，其主体可以用基础语言编写，构成CCC的完整实现。这里的关键问题是，在程序执行到达“基本”代码的正确位置（由通知的“切入点”标识的“连接点”）时，通知代码需要附加到（“编织”到）“基本”代码。这是由一个“方面编织器”来处理的，例如在编译时。简而言之，AOP承诺使用方面对CCC进行干净的模块化。另一方面，LMP是声明式元编程的一种特殊形式，其中元程序可以基于逻辑规则和表示程序的事实，元数据或任何其他有用的知识来编写[16]。因此，LMP可以作为AOP的补充，我们通过在建议的切入点中使用LMP来利用这一点。我们认为，LMP和AOP的这种组合有助于业务架构的恢复，以及业务应用程序的重组和集成首先，通过将AOP嵌入到现有的业务环境中，我们可以为软件开发人员提供灵活的工具链，同时避免陡峭的学习曲线。在使用这个工具链时，不需要脱离现有的开发技术;只有使用增强它们的东西的激励。这可以实现更快的周转可用的专业知识。第二，LMP可以用于以声明的方式表达业务概念和业务应用程序的架构描述。这使得在更高的抽象级别上使用应用程序成为可能，这将允许更好的架构描述出现。通过使这些描述可用于实际使用，我们可以积极地鼓励发展和理解。在接下来的四个部分中，我们将研究AOP和LMP的结合是否确实能够表达遗留系统中现实问题的解决方案。3启用遗留软件为了帮助遗留系统发展，需要彻底了解手头的系统。由于在这些环境中，通常缺乏（最新的）文档，人们被迫应用逆向工程技术。动态分析是一种方法，通过分析系统动态运行时行为的轨迹[6，17]。我们将在这里讨论的AOP的作用是通过对现有应用程序应用一些跟踪方面来启用这些技术。66K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）63int周围清理（姓名）（Jp）：20次处决（JP，”main”）&& 日志文件（文件）&& stringify（文件，名称）22、整数i;24FP = fopen（Name，“a”）;/*开放 在append模式 **/i=proceed（）;fclose（fp）;28返回i;30}1静态文件 * fp;3周围类型在（Jp）上跟踪（Type）：call（Jp， “^（？！. *printf$|. *scanf$）。*$“）5&&型（Jp，Type）&&！is_void（Type）{Ⅰ型7例;9fprintf（fp，“before. （。 %s。我， %s。 ）\n“，Jp ->functionName，Jp -> fileName）;11return（）;13fprintf（fp，“after. （。 %s。我， %s。 ）\n”，15Jp-> functionName，Jp-> fileName）;17返回一、}Fig. 1. 一个通用的跟踪方面：跟踪通知。图二. 一个通用的跟踪方面：初始化和清理。3.1代码图1显示了用Aspicere3编写的通用跟踪方面的第2部分，Aspicere 3是我们开发的C方面语言[18]。在Aspicere中，aspect是一个C模块，它也可以包含advice（例如： 第3 通知由签名（第3行）组成， 一个切入点（第4的建议图1在调用除printf和scanf家族（第4行）之外的所有过程时被激活，并且仅用于那些确实返回值（切入点）的过程第5行的条件是类型不是void）。通知将在这些事件之前和之后（分别在第9行和第14行调用fprintf）将跟踪信息流式传输到文件fp（在第1行声明）在跟踪建议代码之间，可以通过第12行上的proceed调用调用事件本身。文件指针fp的打开和关闭是通过以类似的方式通知主过程（图2）的单独执行来实现的这里有两件重要的事情要注意。 第一个是在第10行和第15行使用一个类似于ANOJ的thisJoinPoint构造（[7]）来检索2我们不显示无效程序的建议，因为这相当于图1的建议，减去需要 一个临时变量来保存返回值。3网址：http://users.ugent.be/~badams/aspicere/的 网 站 。K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）6367关于当前运行时事件的上下文特定信息被建议输出到跟踪。第二个是使用Type作为一种泛型类型指定器。它在跟踪通知（第7行）中使用，以处理可能出现的各种可能的返回类型，而C无法以统一的方式处理这个类型指定符的值是由方面编织器在匹配基本程序中的连接点时提取的（第5行的类型谓词），并且在通知中像C++模板参数一样实例化。这两个增加的内容提供了遗留基础语言中缺少的相关和上下文信息。如果没有它们，AOP在遗留语言中就不可行，而许多现代OO语言本身已经具有这些特性。3.2评价：亲应用于逆向工程环境，AOP和模板机制的使用允许非侵入性和直观地提取隐藏在遗留系统中的知识，而无需事先调查或探索源代码[18]。人们不必像[3]中那样首先提取所有可用的类型并写下所有类型3.3评价：对照由于源代码是跨多个平台的C程序的最可移植的表示，Aspicere依赖于源到源编织策略，这对应于正常C编译之前的额外预处理过程。更具体地说，通过将通知转换为（多个）过程，将方面转换为真正的C编译单元这将以自然的方式启用普通的C可见性规则，即图1中FP的可见性与包含方面的模块相关联为了完全实现这种模块化，这个单一的转换方面还需要链接到每个建议的应用程序中。由于构建所有应用程序的make文件系统是由无数工具和预处理器（例如嵌入式SQL）产生的对象文件、库和可执行文件之间的非常复杂的依赖关系链，所有这些都可能是进程建议的输入，因此Aspicere的编织器 横切制作文件 系统4.然而，我们需要找出在构建的每个阶段都产生了什么，并解开伴随的链接器依赖关系。如果所有的make文件都是自动生成的，例如使用automake，可以尝试用包装器脚本替换（即别名）正在使用的工具，这些脚本在调用原始工具之前调用编织过程。这里的问题是，这是一个全有或全无的方法。在某些情况下，可能需要编织（例如，对GCC的直接调用），而在其它情况下则不是（例如，当从ESQL内调用GCC时）。让替代者足够聪明，知道什么时候做什么不是一件小事。在[18]中，我们将图1的跟踪方面应用于大型案例研究（ANSI-C的453 Kbps），以实现动态分析。该系统由267个制造文件组成，4这个问题比方面编织器的应用广泛得多：任何时候，为了向构建系统添加新的构建步骤或新的资源，出现了类似的问题68K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）63所有这些都是生成的。如果没有对构建系统的深入了解，很难判断源文件是在链接所有应用程序之前首先编译的，还是（更有可能）所有应用程序都是一个接一个地编译和链接的。因此，我们的编织方法不能立即应用，我们不得不求助于一个特别的解决方案，导致编织应用程序的性能（轻微）下降。虽然可以使用方面来启用动态分析，而不需要以任何方式预先编译遗留应用程序的源代码，但是仍然面临必须为这些应用程序准备构建系统（一次）的问题。由于许多这样的应用程序依赖于自定义的，有时复杂的make file层次结构（或类似的），任何真正使用AOP来振兴遗留软件（参见第4节）都将取决于这个问题的解决方案。4遗留软件当在软件中实现时，业务知识、信息和规则往往分布在整个系统中。 对于用Cobol编写的应用程序，情况更是如此，因为Cobol是一种针对业务处理的语言，但没有现代的模块化机制。随着时间的推移，这些信息往往会丢失，因此当需要进行一些维护时，人们又被迫进行逆向工程。我们认为，AOP可以提供一个灵活的工具，这样的电子商务。我们现在将重新回顾[10]中的一个案例，其中Isabel Quixels和第一作者讨论了使用动态方面从遗留中挖掘业务规则的可能性应用. 布丽·埃弗里说，情况是这样的：“我们的会计部门报告说，我们的几个员工被认可的意外和不明原因的奖金500欧元。会计部门有权要求知道这笔不可预见费用的原因。“我们现在将重新审视这一案例，展示可用于实现该文件所载设想这里显示的代码是用Cobble6编写的，Cobble 6是由R al f Lüa mmel和第一作者[ 9 ]编写的一个“AspectC obol“语言的一个新的实现4.1代码我们首先要注意到，我们并不是完全处于黑暗之中。会计部门可以给我们一份“幸运”的员工名单我们可以将这些知识编码为事实：元数据师.2事实科.幸运节值七 七 七 七 。4幸运节值3 1 4 1 号* >等。5.Cobol（CommonBusiness Oriented Language）6网址：http://users.ugent.be/~kdschutt/cobble/网站。K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）6369这段代码的内容是“员工7777、3141等获得了意外的奖金”。此外，我们还可以在复印本中找到正在处理的员工文件的定义（大致类似于C中的标题文件）：1数据部门。文件部分。3FD雇员档案。01员工。505EIDPIC9（4）.* >等。最后，从日志输出中，我们可以找出持有员工年终奖金总额的数据项的名称。这个数据项BNS-EUR原来是一个编辑过的图片。由此我们得出结论，它只用于漂亮地打印输出，而不是执行实际计算。在执行过程中的某个时候，奖金的正确值被移动到BNS-EUR，并随后打印出来。所以我们的第一个任务是找出这个变量是什么。我们通过跟踪所有移动到BNS-EUR来实现这一点，但仅在处理我们的幸运员工：查找源项科.2使用之前 任何声明和 名称 的接收器平等到 “BNS欧元“4和 结合 LOC到位置我觉得我等于幸运儿。6我的建议。DISPLAYEID，“：. “，LOC.简而言之，该建议指出，在所有将BNS-EUR作为接收数据项（第3行）的语句（第2行）之前，如果EID（当前正在处理的员工的ID;请参见上面的数据定义）等于幸运ID（运行时条件为第5行），我们显示该语句的位置以及当前id。在几个字符串文字（因此我们可以立即忽略）中，我们找到一个名为BNS-EOY的变量，其名称表明它包含年终奖金的全部值。我们的下一步是弄清楚最终价值是如何计算的。我们设置了另一个方面来跟踪修改变量BNS-EOY的所有语句，但同样只在处理一个幸运的雇员时。我们分三步来做第一个：1TRAC E-B NS-EOY剖面N。使用 之前任何声明3和接收器的名称等于“BNS-EOY“和绑定地址5和DIFEID等于幸运儿D。我的建议。7DISPLAYEID，“：. 斯泰门河 霸王“，LOC.在执行任何将BNS-EOY作为接收数据项（第3行）的语句（第2行）之前，以及在处理幸运员工（第5行）时，这将输出该语句的位置。下一页：1 TRACE-BNS-EOY-发送器 科. 在任何声明3和接收者的名称等于“BNS-EOY“和绑定发送给发送者5并将发送名称绑定到发送名称，并将DIFEID绑定到LuckyE ID。7我的建议。显示发送人姓名，“。发送。“，发送。70K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）63这将在执行上述任何语句之前输出所有发送数据项（第4行和第5行）的名称和值。这让我们看到了贡献- 价值观。最后，我们想知道已经计算出的BNS-EOY的新值。痕量-BNS-EOY-值科.2使用 后 任何声明和 名称的 接收器平等到 “BNS-EOY“4和DIFEID等于幸运儿D。我的建议。6DISPLA Y“BNS-EOY. =. “，BNS-EOY.我们现在发现一个名为B31241的数据项（隐式），它的值始终为500，并在每次跟踪中添加到BNS-EOY中。在继续前进之前，我们要确保我们走在正确的道路上。我们要验证B31241的添加仅针对我们的幸运员工列表触发。同样，动态方面允许我们跟踪这个添加的执行，并帮助我们验证我们的基本假设确实成立。我们首先将“罪魁祸首”语句的位置记录元数据师.2事实科.罪责-位置值666.4* >其他事实像以前我们假设的检验可以编码为：TRACE-BNS-EOY-发送器科.2使用 之前任何声明和位置平等至罪犯位置4和我的感觉不等于幸运。我的建议。6DISPLA YEID，“：. 巴克河去吧。你好。 绘图 伯湾 “的。这将测试在任何其他雇员的进程中是否触发了罪魁祸首语句。如果是这样，那么我们的假设就错了。也可能是会计部门漏掉了一个幸运的员工。鉴于我们确实走在正确的轨道上，现在的问题是：为什么这种价值增加了幸运的员工，而不是其他人？不幸的是，这背后的逻辑似乎分散在整个应用程序中。因此，为了弄清楚这一点，我们希望有一个执行跟踪每个幸运的员工，包括所有测试的报告，并通过了，直到并包括点，添加了B31241。动态方面使我们能够获得这些特定的痕迹。首先是一些前期工作：WORKING-ST ORAG E N部分。201FLA GPIC9值0。88标志设置值1.488未设置标志值0。FLAG数据项将用于指示何时应激活跟踪，何时不应激活。为了便于使用，我们还定义了两个这些反映了我们的企业目前的状况。我们的第一个建议用于触发跟踪的开始：跟踪-开始科.2使用后读取语句和名称的文件平等到 “雇员档案”4和 结合LOC 到位置我觉得我等于幸运儿。K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）63716我的建议。设置标志设置为true8DISPLAYEID，“：. 斯塔尔湾 霸王“，LOC.也就是说，无论何时读取了新的雇员记录（第2行和第3行），并且该记录是一个幸运雇员的记录（第5行），我们都将该标记设置为true（第7行）。我们还做了一些初始日志记录（第8行）。当我们到达罪魁祸首语句时，需要下一个建议来停止跟踪：跟踪停止科.2使用 后 任何声明和位置平等到犯罪地点。4我的建议。SETFL AG-NO T-SETTOTRU E.6DISPLAYEID，“：. 斯托山口 霸王“，LOC.接下来就是实际的追踪了。我们捕获过程的流程，以及所有条件语句的执行：跟踪程序科.2使用AROUND过程并将过程绑定到名称4、将锚钉固定在位置上，如果设置了标记。6我的建议。DISPLAYEID，“：. 在...之前“我 想，PROC，“。 霸王“，LO C.8继续。DISPLAYEID，“：. 阿夫特河“我想，PROC，“。 霸王“，LOC.10跟踪条件科.12围绕任何声明和条件14并将锚钉固定在位置上，如果设置了旗帜。16我的建议。DISPLAYEID，“：. 在...之前 条件;状况 霸王“，LOC.18继续。DISPLAYEID，“：. 阿夫特河 条件;状况 霸王“，LOC.从这个轨迹中，我们可以推断出从开始处理幸运员工到添加意外奖金的路径。更重要的是，我们可以看到通过的条件，从中我们可以（希望）推断出确切的原因。调查到此结束 对于那些好奇的人，我们发现B31241是以下商业规则的一部分：它是员工在销售至少100件编号为31241的产品显然该产品代码在前一年被分配给一个新产品。 这是 一旦与另一种已停产数年的产品相关。相关的奖金被留在代码中，直到员工开始销售新产品才被触发。4.2评价：亲AOP+LMP为我们的研究提供了一个灵活而强大的工具。动态方面允许通过启用智能跟踪、假设验证和业务逻辑挖掘来LMP增加了记录和利用恢复的知识的能力72K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）631调度科。使用周围3和 结合 PARA段落和 结合 PARA-NAME 到名称 帕拉5如果方法名称与PARA-NAME相同。我的建议。7执行段落9封装部分。使用周围。11我的建议。执 行MER ROR-HANDLING.13出口处图3.第三章。基本过程封装的方面4.3评价：对照首先，要求（参见第3.3节）Cobble编织器已集成到构建系统中在编织过程中，每个新的方面都需要重新编织，重新编译，重新链接和重新部署整个基础系统，到目前为止，这比调试工具或诸如DTRACE [4]或ATOM [13]等仪器技术的成本更高。例如，DTRACE是一个内置于（Solaris）操作系统中的脚本跟踪系统，能够从运行的程序中提取用户定义的信息。5封装程序在[12]中，Harry和Stephan Sneed讨论了从遗留主机程序创建Web服务。他们认为，虽然存在包装表示访问和数据库访问以用于分布式环境的工具，“访问[...] 这些程序的商业逻辑，还没有真正解决。“在早期的论文[11]中，Harry Sneed讨论了一个自定义工具，该工具允许封装Cobol过程，以便能够将它们视为该工具的一部分负责在程序开始时创建一个switch语句，该语句根据作为程序参数传递的方法名我们将研究基于方面的解决方案。5.1基本问题图3显示了如何使用AOP和LMP以通用的方式实现过程（或“业务逻辑”）的封装这里显示的方面是用Cobble编写的，包括两个自由利用LMP特性的建议第一个通知DISPATCHING（第1-7行）负责调度。它在整个程序的执行过程中起作用（第2行），并对程序中的每个段落起作用（第3行）。后一种结果是由段落选择器的歧义引起的这可以是许多值中的任何一个。 Cobble所做的不是只选择一个，而是选择所有的：对于切入点的每一个可能的解决方案，建议都被一个接一个地激活。然而，发送建议将K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）6373只有当METHOD-NAME与所选段落的名称匹配时才会被触发这是在第5行的运行时条件中编码的。最后，通知主体在被激活时，只需调用正确的段落（第7行上的PERFORM第二个建议ENCAPSULATION（第9-13行）是一个通用的总括。它捕获整个程序的执行（第10行），但用一个调用错误处理段（第12行）和立即退出程序（第13行）。净效应是，只要METHOD-NAME中的值与程序中的任何段落名称不这一点，加上第一个建议，给了我们想要的效果。剩下的问题是METHOD-NAME在哪里定义，以及它如何进入我们的程序。第一个问题的答案很简单：任何从外部传入Cobol程序的参数都必须在链接节中定义。即：1 联动科.01方法 NA MEPICX（30）值空间此外，程序部门需要声明它期望这个数据项作为外部的输入：程序司使用方法名称。这就引出了一个问题，即这个输入参数METHOD-NAME是如何以类似AOP的方式添加简单地说：它不是。 我们默认我们的方面和伴随的输入参数在目标程序内部定义（所谓的“内部方面”）。当然，对于一个真正通用的METHOD-NAME数据项的定义不是大问题。我们可以简单地在一个方面模块中定义它，在编织时，它会增强目标程序（模一些alpha重命名以防止意外的名称捕获）：1 识别师.ASPECT-ID. 程 序 包装。3数据师.5 联动科.01方法NA MEPICX（30）值空间由此可见，METHOD-NAME将被用作基本程序的输入参数。链接部分的概念对于外部方面模块本身没有意义，因为方面永远不会以这种方式被调用5.2扩展问题当我们考虑到段落通常包含用作输入和输出的各种变量时，问题的复杂性会增加Sneed对于每 个 [ 封 装 的 ] 方 法 ， 都 会 创 建 一 个 数 据 结 构 ， 其 中 包 括 作为 输 入 和 输 出 处 理 的 所 有 变 量 。然后，在虚拟链接区域上重新定义该区域。输入变量变成参数，输出变量变成74K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）63{识别师.2ASPECT-ID。程 序 包装。4个数据师.联动科.601方法PICX（30）值空间}的情况下，{01切片-名称>重新定义VSPACE.}，22all（（record（R，Ws ss），name（R，RName）），（clone_and_shift（ R，“RName>-Name>“，SR），24{}））26）），28 {使用方法名称进行除法，VSPACE。DEDEVELOPATIVES. }的情况下，30public void run（[name]，[name]，[name]，[name]）32{ WRAPPING-FOR-部分。使用周围3.4和IF法----数值等于““。包装 -车身Y.36}，all（（top_record（R，Wss），name（R，RName）），38{ 移动- Name > 到.}）的情况下，40{执行.}all（（top_record（R，Wss），name（R，RName）），42. 移动<产品名称> 到-.}）44）），46 {封装部分使用周围。48我的建议。执行处理垃圾。50出口程序.ENDDEVELOPATIVE S. 个文件夹8 findall（[姓名，段落，Wss]，10（paragraph（Name，Para），slice（Para，Slice），12wss（切片，Wss）14）的情况下，AllInOut16 ）的情况下，max_size（AllInOut，虚拟尺寸），18 {01VSPACEPICX（）。 }，20 all（member（[Name，Para，Wss]，AllInOut），（见图4。 全过程封装（第一部分）。图五.全过程封装（第2部分）。变量的结果。”换句话说，必须找到封装过程所依赖的所有数据项。然后这些被收集到新的记录中（每个过程一个），所有这些记录重新定义了相同的“虚拟链接区域”（用C语言来说：所有新生成的typedef的联合）。这个连接区域也必须作为整个程序的输入数据K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）6375项引入。76K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）63这样的需求似乎远远超出了AOP的范围虽然它有一个横切关注点（cfr。“for 相反，图4和图5中的代码显示了解决问题的不同方法。 它既不是用Cobble也不是Aspicere编码的，对AOP+LMP方程的不同看法。虽然前面的例子是基于嵌入在AOP中的LMP，但这段代码是基于生成式编程方法的，类似于[2]。代码可以读如下。有什么东西吗在花括号中（{. }）是要生成的（方面-）代码。这可以通过在尖括号（. . >），在处理过程中会扩展其他的都是Prolog，这里用来驱动方面的生成。让我们将这些知识应用于图4和图5中的代码。图4中的第1行和第2行声明了方面的头，而第4-6行如前所述。第8-15行我们从每个文件中提取工作存储部分（第12行的wss/2），它为我们提供了所需的输入和输出参数，这些参数在AllInOut（第14行）中收集。从中我们提取出最大的一个的大小（第17行的maxsize/2），接下来在定义虚拟存储空间时使用（第18行）。然后，对于每个段落（即AllInOut的每个成员），我们生成虚拟空间的重新定义，以包括该段落所依赖的所有数据项（第20-26行）。重新定义可以在第21行看到，在那里它被赋予了一个唯一的名称（即SLICED-paragraph-name）。它的结构是通过检查该段的工作存储部分中的所有记录来定义的(line 22），在更新级别号的同时用一个新的、唯一的名称克隆每个记录（第23行），然后输出这个新记录（第24行）。数据定义到此结束接下来（图5），过程划分被放下，声明必要的参数（第28行）。然后我们生成类似于图3的建议，但现在他们需要执行一些额外的工作。 首先，它们必须将数据从为段落重新定义的虚拟存储空间转移到为程序定义的原始记录（第37-39行）。然后可以放心地调用原始段落（第40行）。然后，计算出的值通过将它们移回虚拟存储空间来检索，再次为段落重新定义剩下的就是通用的catch-all（第46-50行5.3评价：亲尽管这个问题具有固有的复杂性，但AOP+LMP允许我们以一种通用的方式轻松地写下横切关注点。LMP被用来通过对程序的推理来定义我们的方面，而AOP被用来处理应用程序的实际修改。当然，我们很高兴地使用了一个切片谓词来完成大部分困难的工作（第11行）。尽管如此，使用隐藏此类算法的库是我们可以从LMP中获得的另一个好处K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）63775.4评价：对照上述方面的难点在于在另一个程序上声明额外输入数据项的语义。我们期望发生什么？• 由方面引入的输入数据项是否替换了建议程序中现有的输入项，或者被视为对它们的添加• 如果它被添加到它们中，那么它将进入现有的输入列表的哪里？在前线？在后面？• 当多个方面定义这样的输入项时会发生什么？它们以什么顺序出现？• 我们如何处理更新woven程序被调用的站点？添加一个额外的输入项将打破这些。考虑一下C或Java的等价物：在过程或方法上引入新参数意味着什么？更重要的是，我们应该允许这样做吗？对生成式方法的需求给出了一个明确的暗示，即我们在这里触及了当前AOP语言技术的边界，但目前还不清楚这是否意味着当前的语言研究还不够先进，或者AOP不适合解决这个问题。62000年问题综合症2000年问题可能是遗留系统在转换为欧元货币之前发生意外变化的最著名例子。重要的是要明白，这并不是因为缺乏技术或技术的成熟度，而是因为人们没有认识到，早在60年代编写的代码在那么AOP+LMP是否有助于解决这个问题呢？问题陈述当然提出了一个横切关注点：无论何时以某种方式访问日期，都要确保年份被延长。6.1代码这就提出了我们的第一个问题：如何在Cobol中识别日期的数据项虽然Cobol有结构化的记录，以及严格的数据在它们之间传输的规则，但它们不携带任何语义信息。知道哪些是日期，哪些不是，需要人类的专业知识。LMP的好处是我们可以用它来编码。在C语言中，灾难预计在2038年7月发生（因此是Y2K38），由于C语言更先进的类型化机制，识别问题不那么严重 在（ANSI-）C中的日期可以围绕标准时间规定（在“time. h”中）构建在前一种情况下，在使用超过32位表示整数的系统上重新编译源代码可以在7更多信息请访问http://www.merlyn.demon.co。英国/critdate.htm.78K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）63在后一种情况下，C允许变量被声明为用户定义类型的实例，而在Cobol中，变量必须根据相同的低级Cobol原语（例如十位数的序列）来声明。C中的这些用户定义类型很可能是模块化的，允许本地化（非AOP）解决方案。Cobol的第二个问题：已知哪些数据项携带日期信息，我们如何知道哪一部分编码年份？可能某个项目只保存当年的数据，或者保存当天的所有数据。一个数据项可以是公历格式（即“yyddd”），而不是标准格式（“yymmdd”）。 当然，这个“标准”可能因地区而异（作者将其写成“ddmmyy”）。但同样，我们可以使用LMP来编码这些知识。让我们假设我们可以检查（基于设计信息）保存日期的数据项然后我们可以这样写：A-YY MM DD-FIX截面N返回G我的-DATE。2使用周围发送数据项和发送数据项是日期。4我的建议。移动进行到我的约会（3：8）。6如果我的日期（3：4）大于50，则将19移到我的日期（1：2）8其他移动20到我的约会（1：2）。这个建议有两个问题。一个是MY-DATE的定义（被称为第1行的返回值，并假设具有“yyyymmdd”格式）。在Cobol中，所有的数据定义都是全局的。因此，MY-DATE是一个在所有通知之间共享的唯一数据项虽然这在大多数情况下可能是安全的，但每当我们嵌套执行此类建议时，它可能会导致微妙的错误。8Cobble中的所有建议也是如此。只是需要一个特定的返回值使它更容易浮出水面。当然，在这种情况下，fix将要求为所有建议实例化复制此数据项，例如使用第5.2节。最大的问题在于编织。当致力于源到源的方法时，就像我们使用Cobble一样，在语句级别9以下编织任何东西都是不可能的。由于Cobol缺乏函数10的概念，我们不能像在C中那样用对过程的调用（无论是通知还是原始类型）来代替对数据项的访问。对此的补救办法是切换到机器代码编织，但我们不愿意这样做，因为我们将失去平台独立性。常见的虚拟机解决方案（例如ACUCobol）也不普及。8 虽然不是在这种情况下，因为通知主体的结构只引用PROCEED之后声明9即子表达式，如接收器和接收器等。10函数可以在以后的Cobol版本中编写。 然而，我们对遗留系统的关注排除了在这里使用这些系统。K. 德舒特湾Adams/Electronic Notes in Theoretical Computer Science 166（2007）6379问题好了吗？如何/为什么？逆向工程好(LMP in）AOP业务规则挖掘好AOP中的LMP逻辑封装（基本）好AOP中的LMP逻辑封装（扩展）好LMP中的AOPY2K38（ANSI-C）N/A模块化已经Y2K（Cobol）没有类型太弱表1我们的调查结果摘要。6.2评价：亲如果有关于各种日期格式的设计信息，如果方面编织技术更加成熟，则特定于应用的方面可以解决诸如Y2K或转换为欧元等意外变化问题6.3评价：对照正如6.1节的前两个问题所示，在弱类型遗留环境中，清晰地访问设计信息是先决条件。即便如此，供应商依赖性将AOP实现锁定在特定的语言方言中，使最后提到的两个问题变得更糟。这也是只实施第3在为Cobol（某些方言）构建方面编织器时遇到的其他障碍是它的语法不明确，语句类型和子句的种类繁多等。7结论表1总结了我们的发现。BrieMoney说，我们讨论了逆向工程、重组和集成问题，使用了与（经典）遗留软件相关的四个问题，并展示了如何通过AOP和LMP的混合来帮助其中的三个问题。基于C语言的跟踪和Cobol语言的业务规则挖掘的逆向工程在AOP中采用LMP作为切入点机制，运行顺利。在Cobol中封装过程，这是一个典型的遗留集成场景，需要在LMP中嵌入AOP的更具生成性的方法，因为我们在这里显然触及了一些至于Y2K重构问题，Cobol的语义，特别是它缺乏类型，对AOP解决方案来说有太多的限制。在C中，Y