毕业设计（论文） 基于面向方面编程技术的上下文敏感帮助

1、中文摘要中文摘要 随着计算机的不断发展，软件技术不断创新，人类设计的软件功能越来越强 大，由此产生的软件使用问题也越来越复杂，用户希望软件使用简易化的同时， 也希望软件提供的帮助更加智能化。即要求帮助程序能自动感应程序运行的上下 文，并根据当前上下文提供合适的帮助。本文介绍了现有上下文敏感帮助的实现 方法，指出它们的缺点，并提出了一个基于面向方面编程技术上下文管理框架， 使用该框架可降低上下文敏感帮助实现的复杂性，使其具有更大的灵活性，并适 用于其他基于程序上下文的应用软件。论文详细介绍了该框架的三个组成部分： 提供上下文的原程序、上下文缓冲池管理器和上下文应用程序。文章还探讨了如 何采用面向

2、方面编程技术向原程序加入感应其运行时上下文的程序代码的方法， 论述了如何对上下文进行收集、分析、管理、传送等技术，并研究了如何采用观 察者设计模式建立原程序与上下文应用程序之间的依赖联系。本文还分析了原程 序与上下文缓冲池管理器之间、上下文缓冲池管理器与上下文应用程序之间的通 信模式。另外，我们还参照 corba，将框架中传递的上下文信息用上下文对象进行 封装，建立了上下文之间的层次结构。文章还通过在一个开源项目 freesudoku 的 基础上进行上下文敏感帮助设计，验证了基于面向方面编程技术的上下文敏感帮 助是一个提高软件帮助智能化的可行灵活的实现技术，并说明了我们提出的框架 的可行性和易

3、扩展性。 关键词关键词：上下文敏感，帮助系统，面向方面编程，上下文结构，通信模式 abstract along with the development of the computer and innovation of the software technology, the functions of the software is becoming more and more powerful result in the problem of using software is becoming more complex. consequently, users not only hope

4、 to use the software easily, but also hope to get a more intelligent help provided by the software. this paper describes the realization of the currently context-sensitive help and analyses their shortcomings. afterward we present a context management framework based on aop. this framework can reduc

5、e the complexity of the implement, get greater flexibility and easily be applied to other application based on program context. three components of the framework are introduced particularly later: original application, context pool manager and context-sensitive application. next, we explain the tech

6、nology about weaving code to aware runtime context with aop. we describe the method of the context collection, analysis, management, and transfer. we use the observer design pattern to establish the relationship between original application and context-sensitive application. the paper goes on to ana

7、lyze the communication model among original application, context pool manager and context-sensitive application. in addition, we refer to corba to encapsulate the context information in a context object and establish the hierarchical structure of context. at last, we implement the context management

8、 framework within an open source application: freesudoku. as a conclusion, the context-sensitive help based on aop is a feasible and flexible technology to improve the intelligent of the software help system and the framework is feasible and expandable. key words：context-sensitive, help system, aop,

9、 context structure, communication model 目录目录 中文摘要中文摘要.1 abstract.2 1. 引言引言.5 1.1. 研究背景与意义.5 1.1.1.上下文敏感的研究.5 1.1.2.上下文敏感帮助系统的研究.6 1.2.当前上下文敏感研究遇到的问题.7 1.3.当前实现上下文敏感帮助系统的方法.8 1.4.利用面向方面技术实现上下文敏感帮助.10 2.相关介绍相关介绍.11 2.1.上下文的相关概念.11 2.1.1.上下文.11 2.1.2.程序上下文.11 2.1.3.上下文敏感.12 2.2.面向方面编程（aop）.13 2.2.1.aop

10、与oop的关系.13 2.2.2.aop的核心.13 2.2.3.aop的主要概念.13 2.2.4.aop的开发步骤.14 2.2.5.aop的优势.14 2.2.6.aop工具.14 2.3.相关的设计模式.15 2.3.1.设计模式.15 2.3.2.observer模式.15 2.4.corba 的相关概念 .17 2.4.1.corba.17 2.4.2.corba对象通信.18 3.框架分析框架分析.22 3.1.框架布局.22 3.2.建立基于上下文的应用.23 3.2.1.利用上下文.23 3.2.2.体现上下文敏感的sensor.24 3.2.3.实现上下文敏感应用.24 3

11、.3.应用 observer 设计模式.25 3.4.通信方式.27 3.4.1.sensor与cpm之间.27 3.4.2.sensor与handler之间.28 3.4.3.整体关系.28 3.5.上下文对象.28 3.6.上下文结构.29 4.上下文敏感帮助案例研究上下文敏感帮助案例研究freesudoku.31 4.1.关于 sudoku 介绍.31 4.2.上下文敏感帮助实现过程.32 4.2.1.主要思想.32 4.2.2.实现功能.32 4.2.3.实现时序.32 4.2.4.上下文敏感实现的类关系.33 4.3.sensor的 aop 实现.34 4.4.cpm 实现.36 4

12、.5.handler 搜索帮助.39 4.5.1.xml 注册文件.39 4.5.2.freehandler 实现.41 4.6.实现界面.41 5.总结和展望总结和展望.45 5.1.工作总结.45 5.2.未来的工作.45 致谢致谢.47 参考文献参考文献.48 附录附录.49 1. 引言引言 1.1. 研究背景与意义研究背景与意义 1.1.1. 上下文敏感的研究上下文敏感的研究 正随着计算机技术的发展，硬件性能不断提高，手提电脑、掌上电脑、手机、 各类嵌入式系统等纷纷进入了我们的日常生活，在其上运行的软件越来越多，各 种浏览软件、播放软件、游戏软件为我们的生活带来了无限的精彩与乐趣；各类

13、 编程软件，开发工具为软件设计师的软件开发工作提供了巨大的帮助；形形色色 的管理工具、编辑工具给人们的日常工作带来了工作方式的革命；大量专用的嵌 入式系统，为我们的生活提供了更大的方便，创造出更多的可能 一些软件为提高其应用的专业性，在同一领域处理更多业务、提供更多服务， 于是在软件中加入了大量功能，于是，越来越多集成软件出现在我们面前，软件 规模越来越大，正向专业化逐步发展。在软件功能多元化的同时，用户的操作选 择越来越多，操作也越来越复杂，这同时也对用户的能力提出了更高的要求。一 个功能强大的软件可能附带一本厚厚的使用手册，用户在享受软件提供的强大服 务之前必须学习大量关于该软件的知识，如

14、各类功能所需的操作、专业术语、配 置环境信息。随着人性化要求的不断提高，软件开发时应考虑更多人为与环 境因素，因此我们希望软件能具备智能化，能通过简单的操作实现强大的功能。 对于单个软件而言，我们希望软件能根据用户操作的行为判断用户的意图，自动 执行相关代码并引导用户正确使用软件。对多个软件而言，由于不同类型软件间 可能没有统一的接口或没有一个公认的通信机制，很多时候需要用户进行手工配 置以达到不同软件间相互配合工作的目的，因此我们希望软件间合作也具有自适 应性。 在要求软件专业化的同时，我们也要求软件具有通用性。因为软件应用平台 越来越多，不可能针对每种平台为同一应用设计专用软件，正如 ja

15、va 所提出的： 一次编译，多处执行。我们希望软件也具有适应各种应用环境的能力，这也促进 了普适计算研究的发展。普适计算的目标是使计算机在整个物理环境中都是可获 得的，而用户又察觉不到计算机的存在。其两个特点为：“随时随地”和“透明” ， “其中“随时随地”指人们无论在何时何地都可以获得数字化服务，而不需要特 意走到一个专门的计算机面前；而“透明”是指人们 获得这种服务不需要花过多 的注意力，相比“随时随地” ， “透明”性这一特性是普适计算一个更本质的要求， 实现“透明”性，要求计算和服务的访问方式是十分自然的，甚至用户本身注意 不到的、蕴涵的方式进行”1。这要求计算机设备能够更好地理解环境

16、状态和用 户的需求，对不同的环境状态和用户需求，提供不同的多元化服务，并且通过蕴 涵的状态信息提高计算机和服务的效率。所以，充分感应环境中的上下文是实现 普适计算系统“透明”性这一本质目标的重要途径。 上下文敏感技术因此成为实现软件智能化和软件通用化目标的关键性技术。 上下文敏感技术主要是对动态上下文信息进行捕获，特别在普适计算中，上下文 将随任务而变化，而且由于工作环境是具体的，软件执行的背景情况不但复杂而 且是动态变化的，使上下文的动态问题更加突出。利用动态的上下文信息来引导 软件的提供各类人性化服务，即软件具有上下文敏感的特性，是未来软件发展的 一个方向。 1.1.2. 上下文敏感帮助系

17、统的研究上下文敏感帮助系统的研究 由于软件功能的多样性和使用方法的复杂性，软件不可避免需要具备一个帮 助系统。帮助系统主要为用户提供各类帮助，是人机交互的一种重要方式。而上 下文敏感在人机交互中尤其重要，软件需根据用户使用的环境，使用习惯和当前 操作方式，提供有效的帮助信息。这所有的信息都是软件运行的上下文。具有上 下文敏感的帮助系统(context-sensitive help)可以减少用户输入计算机的上下文信 息，增强帮助的对应性，使帮助更加透明化；通过感应上下文判断用户意图，自 动提供帮助，使用户随时随地得到准确的帮助，也是增强软件易用性的一种表现。 那什么样的帮助系统才是一个优秀的帮助

18、系统呢？这主要有以下三个方面要 求： 无处不在的帮助 用户对帮助信息的需求可谓是多方位的：用户拿到一个新软件的时候，会先 翻看帮助系统的新特点部分；在日常使用中，他可能需要任何一个对话框中各选 项的帮助信息；如果用户界面上有比较独特的工具或状态栏中出现不常见的显示， 他会调用“这是什么”的帮助功能；用户在对某种功能有疑问时，帮助系统能提 供相关的帮助主题。对于用户的误操作，除了给予明确的提示外，还应提供相关 的帮助信息。当用户不能明确描述遇到的问题时，帮助搜索和疑难解答将为他提 供必要的信息。当以上的一切都无能为力的时候，应当提示用户拨打技术支持电 话或访问技术支持网站。如果一个软件的帮助系统

19、在各个方面都从用户角度进行 设计，那么使用这样的软件是一件多么轻松而愉快的事情。 细粒度的帮助 帮助系统能够根据多种信息搜索相关的帮助。用户手册与帮助系统都能够帮 助用户使用软件，但优秀的搜索功能则使软件帮助系统的使用率大大高于用户手 册。帮助索引能否为用户提供真正的帮助，与帮助的粒度有很大关系。以办公软 件中段落格式功能的帮助页为例，索引词最少可以有一个，即段落；也可以有多 个，如段落、行距、缩进、排版等；好的帮助系统将设置多层索引，如段落-行距- 缩进-排版等。索引词的丰富和层次化，将大大缩小帮助的粒度，使用户在需要的 时候能真正得到帮助。 准确有效的帮助 功能表述上不出现错误只是对帮助系

20、统最基本的要求，帮助系统还应当做到 排版统一、格式美观；表达风格一致；没有病句、不使用过长的句子；帮助形式 多样，这些都是优秀的帮助系统应当做到的。与其他用户文档不同，帮助系统还 涉及到与软件的连接问题，保证帮助系统与软件运行上下文的挂接正确性和帮助 文件中各页面间交叉引用的正确性，也是帮助系统制作的一个重要任务，需要编 程人员和文档开发人员的协同工作。 因此，帮助文件的编写制作工作是极其繁琐的，但却是软件开发不可缺少的 部分，不同的软件可以按照各自的风格选择帮助文件的内容、格式和风格。具备 优秀的帮助系统，可以提高用户对软件的信赖程度。 上下文敏感帮助系统由于考虑了用户上下文和程序本身的上下

21、文信息，因此 可以从多个角度判断用户需要帮助的情况，增大帮助的范围，当软件帮助系统能 根据上下文判断用户需要帮助时，自动弹出帮助，实现软件向用户主动交流，并 共同配合完成工作。上下文信息可以是各种类型的，可以是用户的环境信息，如 系统语言、物理位置、当前时间、网络状况，也可以是程序运行时的各类定位信 息，如所在窗口、组件，更可以是用户操作的各类信息，如同一个错误操作出现 的次数、习惯操作的步骤等。上下文信息的丰富多样大大增强软件帮助系统搜索 相关帮助的能力。上下文敏感帮助系统是对原有帮助系统的一种改进，因此可以 利用充分当前大量的帮助系统制作工具，还可以根据上下文信息，实现多类帮助 形式之间的

22、自动选择，集合各类帮助文件的优点，共同服务用户。综上所述，加 入上下文敏感的帮助系统会使软件帮助更加灵活，更加人性化，是一个优秀的帮 助系统。 1.2. 当前上下文敏感研究遇到的问题当前上下文敏感研究遇到的问题 当前，业界还还在努力研究希望给出上下文的精确定义，而实践方面，开发 人员也面临巨大的挑战，当前主要面临以下三类棘手问题，这些问题阻碍了上下 文应用的建立和使用： 感知上下文所固有的困难 如何获取、使用和存储上下文，如何建立上下文敏感的应用系统，在理论研 究方面还存在很多争议，没有一个统一的框架；在实践方面，上下文的获取通过 许多非传统设备，随着技术的不断进步，室外的 gps 可获取位置

23、信息，通过 wireless sensor network 技术可获取室内定位信息，通过各类图像捕获设备、探测 设备，我们获得更多可用的上下文信息，上下文信息已甚少来自鼠标键盘。另一 方面，上下文具有动态特性，如何实时发现上下文、应用上下文，也是一个不可 回避的问题。面对上下文种类的多样性、数据格式和精度的不同，如何对上下文 进行管理、抽象和分析集成，是实现上下文敏感系统的面临的第一道难题。 尽管存在以上困难，研究者们仍通过各种方法对上下文进行了各式应用，但 是这些系统仅专注于某个特定领域或特定的过程，他们的成果很难被其他系统所 重用。 上下文敏感系统向通用化发展 传统的上下文敏感系统一般都是

24、专有系统，这些系统的应用程序通常直接与 硬件设备交互，这虽然在一定程度上有利于效率的提高，但同时也限制了系统的 发展和对环境系统的应变能力，而上下文敏感系统却正是为面向动态多变的环境 而设计的。相关的研究工作者开始意识到这个问题，因此，提高上下文敏感系统 的通用性研究正渐渐得到重视。 上下文敏感应用规模日益扩大 鉴于上下文的利用对系统的帮助显而易见，基于上下文的应用的规模也越来 越大，大规模的上下文敏感应用不仅使其固有的困难更加难以解决，同时也面临 其他任何大规模软件系统所遇到的问题，如开发困难、维护困难等。传统的上下 文敏感应用的规模通常较小，它一般都通过定制以便能在专用系统上运行。虽然 这

25、些定制为软件高效运行提供了所需的条件，但它却创建了一个不灵活的结构， 存在不容易修改、升级和与其他产品集成等缺点。唯一的解决办法是使用开放系 统技术解决大规模上下文敏感系统所面临的问题。 总的来说，当前上下文敏感的应用需建立一个通用的上下文敏感应用支持环 境，创造出一个研究和开发平台，在它之上可以更全面的解决上下文敏感的相关 问题，更迅速的构建出上下文敏感应用。因此，建立上下文敏感应用框架具有基 础性的意义，会直接影响到上下文敏感研究的开展和应用的推广。 1.3. 当前实现上下文敏感帮助系统的方法当前实现上下文敏感帮助系统的方法 帮助系统（help system） ，是指对应用程序的特性说明，

26、以及应用范围的简单 介绍文件，类似于一个整理过的大型 faq 集。由于用户需要方便快捷地使用程序， 帮助系统应运而生。用户按下帮助按钮或者帮助快捷键，如 windows 系统中的 f1 键，或达到软件预设的帮助条件，便会启动帮助系统，一般的帮助系统是通过目 录和索引实现的。帮助系统第一步会显示帮助的根目录信息的窗口，通过不断提 出问题，要求用户输入相关上下文信息，逐层细化问题，确定用户当前上下文， 并利搜索相关的帮助主题。该方法可能遇到以下问题：首先，对于一个对专业术 语不太了解的用户，将无法准确描述他当前的状况甚至给出错误的信息，从而导 致无法得到有效的帮助；其次，程序内部运行状态的信息，根

27、本不可能从用户那 里获得，例如用户进入同一的错误操作状态次数、某些内部状态信息，这些数据 可能对搜索帮助起到很大的作用，但这种方法不可能实现这些信息的利用；再次， 这种通过人机对话的方式获得上下文，也会给用户带来额外的工作负担，重复输 入大量仅用于帮助的信息，会降低用户对软件的认同度。因此，仅通过人机对话 方式获得上下文的帮助系统，不具备上下文敏感的特性。上下文敏感帮助系统应 能减少用户的干预，能自动、准确地获得其所需的各类相关信息。 许多软件意识到帮助系统应考虑用户当前的状态信息，于是便出现了许多基 于内容的敏感帮助。内容敏感的帮助是具有用户友好特点的提供帮助方式。当用 户单击一个特定的图标

28、或者字段时就会有一个弹出窗口解释功能或者这个字段下 一步要做的事情。内容敏感的帮助可以分为以下三类： 窗口级帮助：当应用程序的窗口拥有焦点时，用户按下帮助键以启动帮助 系统的特定主题，它通常是一个介绍主题。 字段级帮助：当应用程序的 gui 上的一个特定组件 - 如文本字段或者 按钮 - 拥有焦点时，用户按下帮助键或者单击一个按钮以启动帮助系统 的描述当前组件的特定主题。 屏幕级帮助：用户单击一个按钮以调出具有描述应用程序当前屏幕的特定 主题的帮助系统。 但这些内容敏感帮助都仅仅是基于组件的，只是考虑了位置信息，而且要求 软件的视图部分有固定的框架结构，如利用 javahelp 编写帮助，必须

29、要求 java 程序使用 swing 框架。在编写帮助文档的时候，现有方法是在软件编写时为每个 控件加入一个帮助的 id，并为每个 id 编写特定的帮助文件，当用户启动帮助服 务，程序将获取当前用户操作的控件的 id，通过该 id 寻找其对应的帮助文件。 这种帮助需要将帮助 id 在软件编写阶段硬编码进程序，而且只能定位用户操作的 控件信息，无法获取程序运行时的其他信息，如不能在用户第二次出现同样错误 操作的时候提供更加详细的帮助。因此，用户希望软件能考虑更多的上下文信息， 如根据其操作的具体过程，其使用习惯提供更加准确的帮助。 还有很多软件在制作帮助系统时考虑其他的上下文信息，如在 word

30、 程序中， 按 f1 会调出帮助助手，助手会根据它探测到的上下文推测用户最可能需要了解的 问题并在屏幕上列出来。为了感应更多的上下文信息用于帮助主题搜索，部分软 件在软件设计中加入一些专门用于记录用户操作的变量和获取上下文信息的程序 片断，使更多的上下文信息可以被检测和使用。如获取操作系统语言、记录用户 操作过程只要帮助系统需要，软件设计时都可以加入代码实现上下文的提取。 这种设计虽能达到上下文敏感帮助的效果，却增加的软件设计复杂度，增大了软 件维护的难度，主要是因为：第一，上下文信息是从程序的各不相连的部分获得 的，获取上下文的代码将分散于整个程序的各个角落，造成代码纠结，增大了模 块间的耦

31、合度；第二，由于上下文相关的代码是硬编码进程序的，当上下文敏感 帮助需要考虑更多的上下文信息或修改原来的上下文敏感代码时，软件需要重新 进行整体设计修改，这对软件维护更新提出了更高的要求；第三，这种方法没有 统一的设计模式，只能根据具体软件具体设计，技术不具备通用性；第四，软件 的运行是相互影响的，上下文敏感帮助可能需要利用其他软件的上下文信息，而 这种设计方法无法做到上下文信息共享，因此不具备可扩展性。 现有的各类上下文敏感帮助系统的实现方法，都需要软件开发者和帮助系统 开发者从软件设计初期便开始紧密配合工作。两方面开发者必须先协商确定将用 到那些上下文信息，但在软件开发过程中，需求是不断进

32、化的，上下文在软件设 计初期可能未完全考虑清楚，或在帮助的粒度可通过加入新的上下文而变小时， 由于代码纠结，后期加入新的上下文代码将增大软件开发的难度，大大削弱了软 件的健壮性。 综上所述，现有上下文敏感帮助的实现方法仍存在不少缺点，仅能针对特定 软件通过硬编码的方式设计，提供有限度的上下文敏感帮助，设计复杂，且容易 导致代码纠结，增大了软件维护的难度，也不利于软件日后的升级更新。因此， 更好的上下文敏感帮助应能自动获取各类上下文信息，减少用户干预，自动提供 有效的帮助。另外，软件开发与上下文敏感帮助应从物理上分离，分散关注点， 抛弃硬编码的方式，在软件开发完成后根据需要通过简单灵活的方式加入

33、这些上 下文敏感帮助代码，从而降低程序模块间的耦合度。这种设计方法不单可用于新 设计的软件，还可以用于对原有软件的改进。更进一步，上下文应在程序间共享， 增强帮助系统的自适应性。因此，我们需要一个统一的上下文获取-管理-使用框架， 使上下文信息使用更加灵活，降低软件开发维护难度。 1.4. 利用面向方面技术实现上下文敏感帮助利用面向方面技术实现上下文敏感帮助 随着软件编程技术的发展，面向方面编程技术日趋成熟，在面向对象编程技 术的基础上，进一步分散关注点，通过后期织入的方式，使各关注点彼此配合工 作。这种技术也为我们实现上下文敏感帮助提供了一个更简单更合理的实现方法。 将探测上下文信息的代码写

34、入方面，利用面向方面技术把方面织入软件源程序中， 这些织入的代码我们称为上下文传感器（sensor） ，sensor 将上下文信息传递给一 个公共的中间件处理，在中间件中，程序可以共享到其他软件的上下文，经分析 处理后的上下文信息传给上下文敏感帮助程序，进行上下文帮助的搜索显示。该 处理方式从物理上分离了程序代码，上下文信息获取使用更加灵活，降低了程序 的耦合度，简化了程序的功能实现。基于面向方面编程技术的上下文敏感帮助的 实现的框架、技术还适合于其他基于上下文信息的应用，为基于上下文的软件开 发提供了一个可选的的框架。 2. 相关介绍相关介绍 2.1. 上下文的相关概念上下文的相关概念 2.

35、1.1. 上下文上下文 面对上下文的各类应用，我们需要搞清的第一个概念就是上下文（context） 。 根据不同的使用环境和应用目的，人们提出了不同的定义。 schilit bill n.：附近的人、物、位置、标识。2 ryan nick：用户的位置、环境、身份、时间。3 brown peter j：用户周围人的位置、标识、时间、季节、温度等。4 franklin 和 flaschbart：上下文是应用程序环境的状态。5 现在比较认可的是 a.k.dey and g.d.abowd 在上下文研究中给出的定义：上 下文是一种信息输入，该信息可以是任一种描述与用户及其应用相关的环境实体 的信息，包

36、括任务、地点、时间、物体等。6 以上众多的描述，无非都是以“列举上下文信息”和“描述上下文信息”两 种方法来对上下文进行定义。列举上下文有利于特定应用的使用和建模，并且列 举越具体，越有利于特定应用程序的实现；但对于不同领域的应用，则缺乏通用 的指导意义，且难以被应用，因为在考虑新的上下文信息时，这些定义无法帮助 我们界定是否属于上下文信息。描述上下文的定义方法比列举定义更有通用性， 但这种定义对分析和确定上下文元素缺乏指导意义。如 果对上下文定义过于概 括，将不能给具体应用的实现提供更多的帮助。因此一个较为明确的上下文定义 能帮助人们了解上下文的特点，且有利于工程人员的抽象和使用。 但想准确

37、界定智能空间中上下文的内涵和外延还是比较困难的事情，目前的 定义都不具备好的操作性。比如 a.k.dey and g.d.abowd 给出的定义实际上是把 上下文的概念的模糊性转移到了“场景”上。由于无法给出精确定义，因此我们 研究通过从多种角度对目前已实现的上下文敏感应用中使用的各种上下文和其他 一些研究者公认的比较重要的上下文进行总结，来得出我们必须处理的上下文信 息。 2.1.2. 程序上下文程序上下文 在计算机软件开发中，我们主要关心的是程序上下文（program context） 。程 序上下文是指任何能够用于描述应用程序状态的信息。那些被探测获取上下文的 应用程序我们称为原程序（o

38、riginal application） ，程序上下文可以分为内部和外 部上下文，内部程序上下文包括原程序中组件的状态、原程序发生的各种事件、 原程序中的调用栈；外部程序上下文可以是程序运行的本地信息，如时区、 语言、用户权限和用户标识，或者是任何计算机底层资源，如内存、磁盘、cpu 等信息。 根据程序上下文对原程序的重要性，我们还可以将程序上下文分为主要上下 文（primary context）和次要上下文（secondary context） ，主要上下文是那些描述 实体是谁、在什么位置、在什么时间和是什么问题的上下文信息，利用这些信息 可以确定当前这种状态为什么发生。根据主要上下文所描述

39、的信息，可以分为四 种程序上下文：位置（location） 、标识（identity） 、活动（activity）和时间 （time） 。次要上下文是那些能被主要上下文索引到的上下文信息，因为它们都是 主要上下文确定的实体所具有的特征。我们从基于程序上下文的应用程序观点来 看，主要上下文对应于原程序的重要数据结构和一些主要的方法调用，而次要上 下文是程序外部上下文和一些由主要上下文标识的实体的特性。 2.1.3. 上下文敏感上下文敏感 上下文敏感（context aware 或 context sensitive） ，是一种应用系统，该应用 系统利用上下文（context）向用户主动提供与用户

40、任务相关的信息和服务，是对 当前上下文变化和过去上下文进行感知的应用。上下文信息来自于各种硬件或软 件，我们将这些上下文统称为生数据（raw data） ，由于生数据类型多样，表示形 式复杂多变，为了统一格式，上下文必须进行预处理，即我们必须对生数据进行 数据抽象。另外，在上下文敏感过程中，我们还要处理上下文动态性和并发性引 起的探测时机，调度策略等问题。由于上下文信息多样性，带来了数据隐蔽性的 问题，我们必须解决 what、who 和 how 三个问题：what 指什么样的信息可以被 收集；who 表示通过什么设备或方式去获得这些信息；how 指多大的信息可以被 存储，用户如何选择可用数据等

41、问题。 上下文敏感应用主要有三种。第一种，当探测到上下文信息后，向用户展示 该上下文所表示的相关信息和这些信息代表的实体能提供的各类服务。如 cyberguides 系统，这是一种电子导游系统，主要使用位置上下文信息，去提供给 用户比传统的旅行指南更为精确和合适的指引；第二种，根据上下文自动执行服 务。如 word 中检测到一个单词为句子开头第一个单词时，自动将单词第一个字 母转为大写；第三种，利用上下文标注实体。如保存一个新编写的 word 文档时， 软件自动将当前计算机用户名和当前时间等上下文信息标注到该 word 文档中，下 次当该文档成为鼠标焦点时，自动显示该文档的作者和修改时间。 利

42、用了上下文信息，可有效减少了用户的输入，增强了软件提供服务的透明 性，也提高了人机交互的效率，从而更好的提升用户的效率。上下文敏感有助于 新型应用和服务的发展，软件不仅能从用户处获得信息，还能够自动利用更多的 手段获得所需数据，而且隐含人机交互复杂繁琐的过程。上下文敏感软件只收集 必须的信息，因此可自动过滤无关信息，优化信息供应，在信息爆炸的环境下， 解决信息泛滥的问题；自动获取所需信息，也解决了所需信息缺乏等问题。上下 文敏感给软件带来了新的发展方向，大大促进了软件产业、信息产业的发展。 2.2. 面向方面编程（面向方面编程（aop） 2.2.1. aop 与与 oop 的关系的关系 面向方

43、面编程（aspect oriented programming，aop）是 oop 的延续，实际 是 gof 设计模式的延续，是调用者和被调用者之间的解耦。如果说 oop 是关注 将需求功能划分为不同的并且相对独立，封装良好的类，并让它们有着属于自己 的行为，依靠继承和多态等来定义彼此的关联的话，那么 aop 则是希望能够将通 将需求功能从不相关的类当中分离出来，能够使很多类共享一个行为，一旦发生 变化，不必修改很多类，而只需要修改这个行为即可。aop 和 oop 不但不是互 相竞争的技术而且彼此还是很好的互补。oop 主要用于为同一对象层次的公用行 为建模。它的弱点是将公共行为应用于多个无关

44、对象模型之间。而这恰恰是 aop 适合的地方。有了 aop，我们可以定义交叉的关系，并将这些关系应用于跨模块 的、彼此不同的对象模型。aop 同时还可以让我们层次化功能性而不是嵌入功能 性，从而使得代码有更好的可读性和可维护性。 2.2.2. aop 的核心的核心 aop 的基本思想是将不同方面（aspect）的代码分别开来写，达到逻辑清晰， 可复用的目的。与 oop 不同，aop 的核心是关注点（concern） ，一个关注点就是 一个特定的目的,一块我们感兴趣的区域。许多关注点会在多个模块中出现，我们 称为横切关注点（crosscutting concerns） ，使用现有的编程方法，横切

45、关注点会横 越多个模块，结果是使系统难以设计、理解、实现和演进。大多数软件项目都选 择 oop 的编程方式，oop 已经表明了它处理一般行为的能力，但是，我们看到 oop 不能很好地处理横越多个（经常是不相关的）模块的行为。相比之下，aop 填补了这个空白，它很可能会是编程方法学发展的一个里程碑。aop 将程序分为 核心关注点（业务）与横切关注点（可能有纠结的功能，例如日志、事务等） 。 aop 并不与 oop 冲突，oop 是 aop 中实现业务的手段，我们主要用 oop 来做 核心关注点与横切关注点的实现，然后用 aop 将这两种关注点合并产出最终程序。 aop 实现横切关注点的主要方法就

46、是分离关注点，aop 从其本质上讲，使你 可以用一种松散耦合的方式来实现独立的关注点，然后使用一种称为织入 （weave）的技术来建立最终系统。 2.2.3. aop 的主要概念的主要概念 连接点（jointpoint）是一个在程序流程中定义明确的点，可以是一个方法的 调用或一个方法的返回，该返回可以是一个正常的返回或者抛出一个异常。使用 aop，我们需要一个在程序中识别连接点的方法，在 aspectj 中使用切入点 （pointcut）来描述一个或多个连接点，切入点是表示一组连接点，这些连接点或 是通过逻辑关系组合起来，或是通过通配、正则表达式等方式集中起来，它定义 了相应的参考建议将要发生

47、的地方。参考建议（advise）定义了在切入点里面定义 的程序点具体要做的操作，如日志功能的代码，它通过 before、after 和 around 来区别是在每个连接点之前、之后还是代替执行的代码。方面（aspect）声明类 似于 java 中的类声明，在方面中会包含着一些切入点以及相应的参考建议。 2.2.4. aop 的开发步骤的开发步骤 aop 开发有三个清晰的步骤： 方面分解：分解需求，找出横切关注点。在这一步里，你把核心关注点和横 切关注点分离开来。 关注点实现：使用 oop 技术各自独立的实现这些关注点。 方面的重新组合：在这一步里，方面集成器通过创建一个模块单元一方面 来指定重

48、组的规则， 对程序的组装过程即为织入（weaving） ，使用这些规则来构 建最终系统。 2.2.5. aop 的优势的优势 使用 aop 方法实现横切关注点比在需要的地方人工插入代码有以下几条好处： 你只需要在一个地方放置你所有需要加入的功能代码。 减少代码纠结，分散关注点。 插入和删除方面更加灵活，你可以轻易地从构建配置中删除方面。 插入和删除代码都是通过软件自动执行的。这可以消除人为的错误，同时 你删除 aop 代码时可以确信所有新加入的代码都被删除了，不会忽略任 何东西。 可以制作一个可重复使用的方面，它可能被应用到其他应用程序中。 当 aop 软件需要升级时，只需删除原有方面，加入升

49、级后的方面，这使 升级工作变得更加简单。 2.2.6. aop 工具工具 当前主流的 aop 工具有 aspectj、aspectwerkz、jboss aop、spring aop。aspectj 采用了语言扩展，提供了一种代码风格，这种风格是 java 语言的一 种扩展，而其他三种技术都采用了普通 java 语言与基于 xml 和注释的方面语言 的组合。从集成的观点来看，aspectj 对 java 语言的扩展，有利于方面声明拥 有与类声明一样简洁的格式和易于编辑的方式。但扩展 java 语言会使每种解析 java 源代码的工具都必须扩展，才能理解方面。aspectj 提供自己的编译器，该

50、 编译器还具有切入点静态检查的功能。aspectj 和 aspectwerkz 都支持构建字节 码时加入方面的构建时编织和类装入时候加入方面的装入时编织，但是 aspectj 侧重于前者，而 aspectwerkz 侧重于后者。jboss aop 和 spring aop 侧重于在 运行时使用动态代理和拦截器调用方面。这将使 java vm 技术扩展到支持运行时 编织，但目前这仍然处在研究阶段。使用运行时拦截框架的关键好处是：它很自 然地扩展了方面的热部署（hot deployment） ，这意味着可以在运行时激活或禁用 所应用的通知。热部署是 jboss aop 的核心特性，它提供了一个应用

51、服务器管理 控制台，可以激活和禁止某些方面。spring aop 完全基于代理机制，因此，这种 工具很适合粗粒度的横切，但是纯粹基于代理的 aop 不能用来通知精细的连接点 （例如方法调用或字段设置） ，spring aop 容易学习，横跨应用服务器的方面库具 有可移植性。 2.3. 相关的设计模式相关的设计模式 2.3.1. 设计模式设计模式 设计模式是面向对象技术的最新进展之一，它源自建筑学和人类学，是对软 件设计中不断重复出现、可以以某种相同方式解决的问题的一种解决方案，是描 述设计动机的一种方式，设计模式是对软件界已经存在的、针对各种具体问题的 优秀设计经验的总结。使用设计模式是为了可

52、重用代码、让代码更容易被他人理 解、保证代码可靠性。gamma、helm、johnson 和 vlissides 合著的design patterns: elements of reusable object-oriented software给出了编录和描 述设计模式的一种格式，编录了 23 种设计模式和在这些设计模式的基础上推导出 了一些面向对象的策略和方法。 设计模式分为三类：创建型，用于创建或实例化对象，如 abstract factory 模式、singleton 模式和 double-checked locking 模式；结构型，用于处理接口、 将已有的对象组合起来，如 decor

53、ator 模式、adapter 模式和 bridge 模式；行为 型，用于封装变化，如 strategy 模式、observer 模式。 2.3.2. observer 模式模式 在设计模式一书中对 observer 模式的设计意图进行如下的描述：“定义 对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它 的对象都将得到通知并自动更新。 ”7 经常会有这样一组对象，当某个事件发生时，这些对象都需要得到通知。我 们希望这种通知能够自动发出，但是，我们不希望每次侦听通知的对象集改变时， 都要修改通知对象。我们希望将通知者和被通知者解耦。 这是一种很常用的模式，又称为依赖（dep

54、endents）或发布订阅 （publish-subscribe） ，与 com 中的通知过程也很类似。java 中，该模式是通过 observer 接口和 observable 类来实现的。在基于规则的专家系统中，经常通过守 护（daemon）规则来实现。 observer 模式的结构如下图 1： 图 1： observer 模式结构 observer 模式有两种参与者： 目标（subject）：触发事件的对象，是观察者观察的对象。它保存了一个关 注它的所有观察者的列表，并提供了 attach 和 detach 两个接口供观察者注册到 它的观察者列表中,在事件发生后，它的 notify 接口

55、会通知观察者列表中的所有 观察对象。 观察者（observer）：所有希望在事件发生后获得通知的对象。它具有一个 接收通知的方法 update。 目标和观察者接口包含了它们之间相互联系的方法，继承它们的对象还添加 了具体对象包含的状态信息和获取这些信息的方法。所有观察者都使用统一的接 口 update 方法，当需要通知观察者时，notify 方法在一个循环中一次调用所有观 察者的 update 方法，被通知的观察者再调用给出通知的具体对象的 getstate 方 法获取目标对象的状态信息，其时序图如图 2。 图 2 observer 模式时序图 对象之间存在依赖关系时候并不一定需要用到 obs

56、erver 模式，如果观察者是 是固定的，即这种依赖关系是固定的，则引入 observer 模式只会增加复杂性。 observer 模式适用于变化或动态的依赖关系，当需要得到某事件通知的对象列表 是变化的，或者是有条件的，使用 observer 模式更具价值。这些变化可能是由于 需求的变化，或者由于需要通知的对象列表的变化而引起的。如果系统在不同的 情况下运行，或由不同的用户运行，需要的观察者列表都会不同，这时 observer 模式也很有用。 observer 模式体现了几条面向对象原则： 对象自我负责：observer 对象有多种，但都从 subject 对象收集所需 信息，并自己完成相应

57、的操作。 抽象类：observer 类表示了“需要得到通知的对象”这一概念，它为 目标提供了一个通知 observer 的公共接口。 多态封装：subject 不知道与那种观察者通信。实际上，observer 类 封装了各种特定的 observer。这意味着如果我在未来有新的 observer， 不需要修改 subject 类。 2.4. corba 的相关概念的相关概念 2.4.1. corba corba（common object request broker architecture，公共对象请求代理 体系结构）是由 omg 组织制订的一种标准的面向对象应用程序体系规范。 omg（ob

58、ject management group）是成立于 1989 年的非盈利联盟，其宗旨是通过 制订与维护规范标准以促进面向对象技术的理论与实践发展，特别是在日新月异 的分布式计算领域。omg 蜚声全球的主要成果是发布了中间件规范与面向对象建模 规范，其中间件规范的核心为 corba，另外还包括对象服务、公共设施、领域接口 等规范。 corba 是 omg 早期最具影响力的规范集，它保证了应用程序的可互操作性以及 对于计算机硬件、操作系统、网络结构与通信协议、编程语言等平台的无关性。 corba 规范集由一系列规范组成，包括 orb 体系结构、接口定义语言 idl、idl 到 各种程序设计语言的

59、映射、orb 件通信协议 giop 和 iiop 等。 corba 顺应软件技术发展的潮流，成功融合了两种软件体系结构的风格：一种 是基于消息传递的客户机/服务器技术，一种是面向对象软件开发技术。corba 采 用面向对象方法创建在不同应用程序中可复用与可共享的软件组件，每一对象对 外隐藏其内部工作细节，并提供一个具有明确定义的外部接口，从而降低应用程 序的复杂性。 corba 的平台无关性很适合用于集成企业内的异质计算机系统，它支持多种主 流的程序设计语言，并允许在单个分布式应用程序中混合使用这些语言。corba 的 最大特点是提供了在异质分布式环境中对象之间的高度可互操作性，从而保证了 建

60、立在不同 corba 产品之上的分布式对象之间的相互通信。corba 提供一个工业标 准而不是一个软件产品，使用 corba 标准也为开发人员的实现提供了较高程度的 可移植性。 corba 的典型应用是开发需要有效处理大量客户请求的服务程序，corba 的可 伸缩性与容错性使得许多大型网站后台都应用了 corba 技术，也使 orb 成为许多 企业级应用服务器的通信基础设施。 2.4.2. corba 对象通信对象通信 corba 规范支持经典的同步通信，同步通信要求通信双方必须同时就绪才可进 行通信，经典的同步通信还导致客户程序阻塞以等待服务程序的答复。 corba 还支持延迟同步通信和单向