《计算机应用技术硕士学位毕业论文网格环境下的异构动态实时系统服务质量的面向方面建模.doc》由会员分享，可在线阅读，更多相关《计算机应用技术硕士学位毕业论文网格环境下的异构动态实时系统服务质量的面向方面建模.doc（74页珍藏版）》请在三一办公上搜索。
1、摘 要复杂动态分布式实时系统中的服务质量QoS的描述、控制、管理、协商及保证是一项非常复杂和具有挑战性的工作，服务质量QoS直接关系到系统的性能。但是QoS的研究仍缺乏完整、清晰的技术体系，没有一种QoS解决方案成功地满足了复杂动态分布式实时系统环境中的所有服务质量需求。由于复杂动态分布式实时系统具有的异构性、分布性、动态性和自治性，对分布式系统的建模和实现中经常会出现同样的问题。如果不考虑局部故障、带宽的动态变化、安全要素等等，面向对象是一种很合适的抽象。但是当处理分布式系统中出现的方面时，面向对象的设计很明显地失去了它的优势。我们对服务质量（QoS）的处理提出了一种将各分散服务中的方面融合
2、起来的机制，可以把QoS作为分布式程序中的一个方面来进行处理。本文通过对统一建模语言UML的扩展，对分布式系统的QoS建立模型。首先对QoS建立框架元模型，再建立QoS的剖面图，将UML扩展成支持面向方面的QoS建模语言QML，并通过简单实例来分析这一建模语言的应用，最后，通过一个分布式系统中QoS的面向方面应用，说明了如何利用基于UML的面向方面编程(AOP)技术来建模实时系统。我们通过结合传统的网格QoS结构模型，把QoS关注从系统中抽象为一个独立于系统的QoS方面，从结构建模、行为建模、方面织入以及代码产生几个方面实现面向方面的建模方法，更好的提供网格环境下QoS保证，分离了QoS关注，
3、提高软件的重用性。关键词：网格QoS；统一建模语言；实时系统；面向方面；UML扩展ABSTRACTIn the complex dynamic distributional real time system,the description, the control, the management, the consultation and the guarantee of Qos is a very complex and challenging work,Quality of Service(QoS) is directly related to systems performance. B
4、ut the There are still have a completely, workable technical system in QoS Research, without a solution successfully satified all the requirement in the complex dynamic distributional real time system environment.Because of the isomerism, the distributivity, the dynamic and the autonomy in complex d
5、ynamic distributional real time system, there always has the similar problem in distributional systems modelling. Without considering of the partial failure, the dynamic changing of bandwidth , the security essential factors and so on, Object-Oriented is a very good abstracts way. But when it faces
6、time aspect appearing in the distributional system, the Object-Oriented design has lost its superiority very obviously. We introduce a mechanism called Aspect-Oriented to intergrate each dispersion service in aspect, This mechanism could take QoS in the distributional software as an aspect. This art
7、icle build the distributional systems QoS model. through extensing the unification modelling language(UML), First, we establish a QoS frame metamodel, then we establish a QoS profile model, extense the UML to QoS modelling language(QML) for supporting Aspects, and analyzes this modelling language th
8、rough the simple example. Finally, we explained how to establish real time systems model, using AOP based on UML. We can abstract QoS concern to a independent QoS Aspect from the whole system, through integrating with the traditional QoS architecture. Then we can implete the Aspect-Oriented modeling
9、 mathod, through the structure modelling, the behavior modelling, the aspect weaving, as well as the code producing, provide better QoS guarantee in grid environment, separate the QoS concern, enhances the softwares reusability.Keywords: Grid QoS; Unified Modelling Language; Real-Time System; Aspect
10、-Oriented; UML extension 目 录摘 要IABSTRACTII目 录IV第一章 绪论1.1研究背景1.2本课题研究的现状和意义1.3本文的工作和结构第二章 面向方面相关理论和应用2.1面向方面技术的发展2.2面向方面的基本概念2.3AOSD建模2.4AspectJ介绍第三章 基于UML的面向方面建模方法13.1统一建模语言UML13.1.1UML重要元素13.1.2UML的可扩展性33.2用UML进行面向方面建模33.2.1方面的描述43.2.3方面和方面之间关系的描述53.3面向对象编程AOP元素UML表示63.3.1表示切入点63.3.2表示通知与引入73.3.3表示
11、方面8第四章 实时系统QoS面向方面的建模94.1网格服务质量QoS基本概念和关键技术94.1.1网络QoS与网格QoS的关系104.1.2网格QoS的要求104.1.3网格QoS控制模型114.1.4网格QoS关键技术134.2QoS的分层模型154.2.1网格QoS参数划分154.2.2网格QoS的层次结构模型16第五章基于UML的QoS建模195.1基本原理和概要模型195.1.1 QoS建模语言构造器195.1.2 QoS建模元素205.2QoS框架元模型215.2.1一般QoS框架215.2.2 QoS属性225.2.3 QoS约束245.2.4 QoS级别245.2.5 基于asp
12、ectJ的QoS面向方面建模265.3QoS剖面图275.3.1 QoS属性子剖面图285.3.2 QoS约束子剖面图325.3.3 QoS行为子剖面图345.3.4 统一资源集成子剖面图355.4使用QML进行面向方面的扩展和应用365.4.1 QML的基本设计思路365.4.2 QML的实例应用375.5面向方面的QoS实际应用分析405.5.1QoS在简单网络收音机系统中的应用405.5.2传统的QoS 特性描述模型415.5.3 QoS方面的结构模型425.5.4结构关系425.5.5系统实时方面的分析445.5.6织入QoS方面46结 论参 考 文 献49攻读学位期间发表的论文53独
13、创性声明54致 谢55CONTENTS CHINESE ABSTRACTIENGLISH ABSTRACTIICHINESE CONTENTSVENGLISH CONTENTSVIIChapter1 Introduction1.1Research Backgroud1.2The Meaning and Innovation of this Article1.3The Content and the Chapter of this ArticleChapter2 Introduction of AOP2.1The Devolopment of AOP Technology2.2The Basic
14、 Concept of AOP2.3AOSD ModelingChapter3 AOP Modeling Mathod Based on UML83.1 UML83.1.1Important Element in UML83.1.2The Expansibility of UML103.2Aspect Oriented Modeling in UML103.2.1 Aspects Description113.2.3 Description between Aspects123.3Descripe AOP Element Using UML133.3.1 Description of Poin
15、tCut133.3.2 Description of Advice and Introduce143.3.3Aspects Representation15Chapter4 Aspect-Oriented Modeling of RealTime System QoS164.1Basic Concept and Key Technology of Grid QoS164.1.1Relationship Between Grid QoS and Web QoS174.1.2Requirement of Grid QoS174.1.3Control Model of Grid QoS184.1.4
16、Key Technology of Grid QoS204.2Submodel of QoS224.2.1Grid QoS Characteristic224.2.2Architecture of Grid QoS23Chapter5Qos Modeling based on UML265.1Basic Principle and Brief Model265.1.1 Constructors of QoS Modeling Languages265.1.2 QoS Modeling Elements275.2 QoS Framework Metamodel275.2.1 General Qo
17、S Framework285.2.2 QoS Characteristic295.2.3 QoS Constraint315.2.4 QoS Level315.3 UML QoS Profile335.3.1QoS Characteristics Subprofile335.3.2 QoS Constraints Subprofile385.3.3 QoS Behavior Subprofile405.3.4 Integration of General Resource SubProfile415.4AO Extestion and Application Using QML425.4.1
18、Basic Design Thought in QML425.4.2 Example of QML435.5Example of Aspect-Oriented QoS465.5.1An Application in CORBA Event Service465.5.2Traditional QoS Characteristic Description Model465.5.3 Architectrue Model of QoS Aspect485.5.4 Architectrue Relationship485.5.5Weaving in QoS Aspect49ConclusionRefe
19、rences53Publications during Masters Study57Promethean Announcement58Acknowledgement59 第一章 绪论随着软件行业的飞速发展，分布式实时系统的应用越来越广泛，服务质量保证作为一个网络服务中最基本的问题也越来越重要。在应用面向方面方法对分布式实时系统的建模和应用研究上已经有了初步的成果，但是应用面向方面方法对网格环境下的实时系统的服务质量进行建模和应用基本上是一片空白，在网格环境下的实时系统，尤其是其服务质量的保证，存在许多应用面向方面方法的空间，例如时间方面的问题，安全机制方面的问题。分布式实时系统的时间分析是非
20、常复杂的，不同的分布式实时系统具有不同的时间特性需求。它的时间方面包括确定的时间、不确定的时间和模糊时间等。为了简化多种时间混淆在一起形成的复杂性，我们可以把这些时间进行分类，并分离出来形成子时间方面。根据面向方面的思想，不同的时间子方面还可以利用不同的形式化语言来表达。在实现所有方面模型之后，又可以把它们织入到系统，完成它在系统特定的作用。目前，各种形式化语言都是通过扩展实时性来建模实时系统，还没有一种较完善的语言能够表达所有的时间特性。复杂动态分布式实时系统中的服务质量QoS的描述、控制、管理、协商及保证是一项非常复杂和具有挑战性的工作，服务质量QoS直接关系到系统的性能。但是QoS的研究
21、仍缺乏完整、清晰的技术体系,没有一种QoS解决方案成功地满足了复杂动态分布式实时系统环境中的所有服务质量需求1。本文通过面向方面的方法对实时系统的QoS建立模型，首先使用面向方面的方法对实时系统中服务质量层次结构的各个子层分别建立模型，综合上面建立的模型对实时系统中服务质量建立面向方面完整的模型，再通过扩展OMG IDL（对象管理组织 接口定义语言）将建立的QoS模型集成到一般的面向对象的中间件中去，检验建立的QoS模型的能效。1.1 研究背景由于复杂动态分布式实时系统具有的异构性、分布性、动态性和自治性，对分布式系统的建模和实现中经常会出现同样的问题。如果不考虑局部故障、带宽的动态变化、安全
22、要素等等，面向对象是一种很合适的抽象。但是当处理分布式系统中出现的方面时，面向对象的设计很明显地失去了它的优势。对服务质量（QoS）的处理提出了一种将各分散服务中的方面融合起来的机制。因此，可以把QoS作为分布式程序中的一个方面来进行处理。1.2 本课题研究的现状和意义在应用面向方面方法对分布式实时系统的建模和应用研究上已经有了初步的成果，但是应用面向方面方法对网格环境下的实时系统的服务质量进行建模和应用基本上是一片空白，在网格环境下的实时系统，尤其是其服务质量的保证，存在许多应用面向方面方法的空间，例如时间方面的问题，安全机制方面的问题。分布式实时系统的时间分析是非常复杂的，不同的分布式实时
23、系统具有不同的时间特性需求。它的时间方面包括确定的时间、不确定的时间和模糊时间等。为了简化多种时间混淆在一起形成的复杂性，我们可以把这些时间进行分类，并分离出来形成子时间方面。根据面向方面的思想，不同的时间子方面还可以利用不同的形式化语言来表达。在实现所有方面模型之后，又可以把它们织入到系统，完成它在系统特定的作用。目前，各种形式化语言都是通过扩展实时性来建模实时系统，还没有一种较完善的语言能够表达所有的时间特性。复杂动态分布式实时系统中的服务质量QoS的描述、控制、管理、协商及保证是一项非常复杂和具有挑战性的工作，服务质量QoS直接关系到系统的性能。但是QoS的研究仍缺乏完整、清晰的技术体系
24、,没有一种QoS解决方案成功地满足了复杂动态分布式实时系统环境中的所有服务质量需求。面向方面软件设计(AOSD)方法是基于关注分离技术，能够把系统划分为不同的方面，并且每个方面能够单独地设计和实现。实时系统的面向方面建模就在于能把时间方面独立处理，因此可以建立一个时间方面模型来统一表达系统的时间特性。并且，这个时间模型可以根据需要进一步细化为多个子方面，例如确定时间方面、随机时间方面和模糊时问方面等，每个时间子方面根据各自的特点利用不同的形式化方法来表示。这些不同的时间子方面实现之后能够重新构造成一个时间方面，并管理着系统的实时性。通过面向方面的方法对实时系统的QoS建立模型可以把整个系统中的
25、QoS抽取出来进行建模，再通过扩展UML可以将QoS扩展为满足QoS需求的QML，满足所需求的系统的QoS保证建模。1.3 本文的工作和结构本文的基本思路：应用面向方面的方法对实时系统的QoS进行建模。即首先对网格服务质量QoS进行层次分析，提出合理的层次结构，应用基于UML的面向方面建模方法对各个层次建模。再通过扩展UML建模方法的QML对QoS建模，最后通过实例分析面向方面技术在QoS建型中的应用。本文的主要工作：基于UML2.0建立各个层次QoS的模型，扩展UML为QML，通过面向方面的方法进行QoS建模，通过应用实例，分析面向方面技术在QoS建模中的应用。本文的结构：第一章绪论，分析了
26、本文的研究背景和课题研究现状。第二章介绍了本文关注的面向方面开发技术；第三章详细介绍了基于UML的面向方面建模方法；第四章讨论了QoS的基本概念和关键元素，并提出了QoS的层次模型。第五章是本文的主体部分，应用扩展UML的方法建立QoS分层模型，并对前面层次模型进行整合，并通过应用实例分析面向方面技术在QoS中的应用。 第二章 面向方面相关理论和应用本章介绍面向方面技术的发展和特点，重点介绍面向方面编程（AOP）技术的特点。同时介绍面向方面的一些基本概念，为本文后面应用面向方面的方法建立QoS的模型提供理论基础。2.1 面向方面技术的发展当前，面向对象编程(OOP) 2和基于组件的软件开发得到
27、了广泛的使用，OOP表明了它处理复杂问题的能力，但是OOP无法模块化横切(crosscut)整个系统的关注点(concerns)，这些关注点称为横切关注点(crosscutting concerns)，如时间要求、安全、QoS监测、日志等。这些非功能单元弥散在整个系统中，导致了代码分散(code scattering)；并且与功能单元混杂在一起，导致了代码纠缠(code tangling)，降低了程序的可理解性、可复用性和可维护性。解决问题需要分离关注点，将不同的关注点分离成模块。面向方面编程 (AOP)将关注点实现为分离的方面， 然而实现仅仅是软件开发过程中的一个阶段。要在整个软件开发过程应
28、用面向方面技术， 就需要对AOP中元素进行详述、可视化、构造和文档化。2.2 面向方面的基本概念面向方面编程(AOP)把系统不同的关注分离出来并单独设计，可以解决面向对象编程不能简单解决的复杂问题3 4。面向方面建模技术允许系统开发者在系统设计时，从核心功能性需求中分离出不同的关注，例如实时性、安全性、错误和异常处理、日志、同步控制、调度、分布式管理等，并且支持各个方面的组合和绑定来实现系统的集成。从系统分离出来的各类关注可以与系统其他部分同步开发，进行单独设计而不必考虑其他方面和系统的核心组件。实时性是实时系统的最重要特性，可以利用AOP技术把实时系统的实时性作为开发系统的一个独立的方面，并
29、建立相应的时间模型来实现和管理时间方面，从而方便实时系统的设计和开发，确保系统的实时性。下面我们将简单介绍一下面向方面的基本概念，包括连接点、横切点、通知、类型间声明、方面等。连接点(join point)是程序运行流程中的一点，可以看成是在程序运行的过程中发生的一个事件(things that happen)。典型的连接点有方法的调用、对象的初始化、域的读写、异常处理的执行等。横切点( pointcut )收集程序运行流程中的连接点;换句话说，横切点是某些连接点的集合，这些连接点或是通过逻辑关系组合起来，或是通过通配、 正则表达式等方式集中起来。横切点代表了具有某个或某些特征的一类连接点，如
30、“某个类所有方法的调用”、“所有名字含set子串的方法的执行”、“对某个类所有字符串类型的域成员的读取”等。横切点是面向方面理论的重要概念。一般来说，连接点极少单个出现，通常都是以横切点的形式出现在方面中。通知(advice)定义了当程序到达某些连接点时需要执行的操作。通知通常有三种:before通知、after 通知和around通知，分别表示在连接点之前、之后和代替连接点执行的操作。通知的威力在于它可以访问在连接点运行时的上下文中的值，因此可以根据情况作出不同的反应。 类型间声明(inter-typedeclaration)是指那些跨越类/构件和它们的层次结构的声明。这些声明可能是横跨多个
31、类的成员声明或者是类之间继承关系的改变。不像通知是动态操作，类型间声明是编译时的静态操作。典型的类型间声明有定义类的成员方法、定义类的域成员、定义类的继承关系、定义异常等。在类型间声明中对类/构件的定义或层次结构的改变，只在相关的方面中有效;在其他方面或类/构件中则不产生任何作用。也就是说，类型间声明实际上并没有影响到原来的面向对象结构，即没有破坏原来面向方面所定义的内容。上述的横切点、通知以及类型间声明，组成了方面(aspect)的最核心部分(同时也是方面有别于类的最明显特征) ;核心部分再加上方面自身的域成员和方法定义，构成了一个完整的方面。换句话说，方面是横切点、通知和类型间声明等的联合
32、体。从结构上讲，方面很像面向对象中的类，类是数据对象和数据操作的统一体。 编织是把特定连接点的实现代码( advice )插入到相应的连接点代码上。通过编织工具，通知会“插入”到通知对应的连接点的前面、后面或连接点所在的代码中。编织技术主要有两种，一种是静态编织，即在系统编译时把方面编织到构件中;另一种时动态编织，即在系统运行时把方面部署到构件中。静态编织要求程序员在系统编译前就确定方面的实现代码，而动态编织则可以在系统运行后自由地启用和禁用方面。静态编织对系统性能损耗较少，而动态编织对系统性能损耗相对较多，但运用更灵活，而且系统性能的损耗可以通过并发处理等方法来弥补。因此，动态编织是编织技术
33、的主流趋势。2.3 AOSD建模AOSD即面向方面软件的开发方法5为我们提供了一个分别独立分析和设计系统的各个核心关注点和横切关注点(系统级关注点) 的机制，并能够在软件开发后期实现横切关注点与相关核心关注点的集成，甚至能够将一个横切关注点实现代码织入(Weave)到软件系统中，而无须改动原系统的各个模块。这种方法解决了面向对象方法遇到的难题AOSD方法是面向对象方法的演绎与发展，该方法引入了“方面”( Aspect)来描述横切关注点，并给出了将方面与原系统相合成的技术。AOSD方法根据系统分析的结果，分离出系统关注点与一般关注点，对于一般关注点可以使用面向对象(OO) 方法实现，而对于用OO
34、方法难以 清晰的封装并模块化实现的系统关注点，可以用面向方面( AO) 方法封装为独立的模块。方面的实现与传统的开发方法中模块的实现不同，方面之间是一种弱藕合的关系，各Aspect的开发以及各核心关注点的开发彼此独立，只有在系统组装时刻，才将各方面和主代码编排、融合在一起。这使得软件开发过程中不需考虑各个模块之间错综复杂的关系，在很大程度上降低了软件开发的难度；同时在软件的维护阶段，要将一个横跨系统多个模块的新特性加入到系统中去，无须分别修改各个模块，只须将此横切特性设计成一个方面，再和相关模块编译一次即可，这可以极大地降低软件维护的难度和复杂度。AOSD方法是构建在OOSD方法的基础上的，是
35、对OOSD方法的一种继承与发展, AOSD方法可以更好地描述OOSD方法不擅长描述的横跨多个模块的需求或特性，很好地将关注点分离，从而可以模块化地实现横切特性，有效地解决复杂系统的横切关注点分离、设计和实现的问题，实现各构件或模块的弱藕合性。在系统功能设计时，不需考虑散杂在对象中的关注点，降低了开发和维护难度的同时也提高了代码的复用粒度。2.4 AspectJ介绍在所有AOP的Java实现中，开放源码产品AspectJ最受瞩目。AspectJ对Java语言进行了扩展，通过引入方面aspect等基本元素，使其成为面向方面编程语言。AspectJ语言是Java语言的超集，所有Java程序均可视为A
36、spect程序。读者可从http:/eclipse.org/aspectj免费下载AsepctJ。AspectJ包括语言规范和语言实现两部分。语言规范规定如何书写程序。其中，未扩展的Java被用于实现核心关注点和横切关注点的基本逻辑部分(横切模块)；Java的扩展用于实现关注点的横切，即定义编排规则。语言实现部分提供编排器。AspectJ的编译器集成了Java编译器，因而大多数情况下被称为AspectJ编译器。横切(Crosscutting)：在AspectJ中，对编排规则的实现称为横切。AspectJ提供了两类横切模型：第一类是在某些明确定义的程序执行点上，定义附加操作，及运行条件。这类横切
37、称为动态横切(dynamic crosscutting)。动态横切非常类似于CORBA中的拦截器(interceptor)，其功能是在执行程序中的特定点拦截并获得控制权。第二类是对已有的Java对象类型，改变其构造，例如增加类的成员数据。这类横切称为静态横切(static crosscutting)。动态横切(Dynamics crosscutting)：相对于静态横切，动态横切在软件项目中使用更为广泛。与AspectJ动态横切机制有关的基本概念，有连接点(join point)、切点(pointcut)、通知(advice)等。连接点(Join point)：连接点， 即程序流程中某个可以被
38、识别的点或位置。如对一个方法的调用，或是对一个成员的赋值。连接点是一个抽象概念，而非AspectJ的语言元素。引入这一概念，可方便地表达横切操作。在一个程序流程中存在多种各不相同的连接点。切点(Pointcut)：切点是连接点的集合，它定义了程序流程中的若干连接点。切点声明可出现在方面(aspect)、类(class)、界面(interface)定义中，与成员数据、成员方法一样，切点也具有访问属性(public、protected、private等)。在AspectJ的语言规范中， 切点可以用署名或匿名形式声明。其作用与类的署名或匿名形式相同。署名形式是为了多次引用，而匿名形式是为了方便一次性
39、的使用，例如在通知(advice)声明中，一次性使用。通知(Advice)：通知是AspectJ的语言结构，与Java方法(method)类似。它表述在切点所选定的连接点处要执行的横切行为。通知的一般表述为：通知类型：切点执行逻辑。其中切点可以是署名切点名或匿名切点。花括号内的执行逻辑将在连接点本身、之前或之后被运行。AspectJ根据执行逻辑运行的位置，提供了三种通知类型：1before。此类通知规定，在连接点之前运行执行逻辑。例如，通知before()：myPointCut()表示在程序执行署名切点myPointCut()选定的连接点之前，完成内的执行逻辑。2after。此类通知规定，在连
40、接点处程序执行返回之后，完成执行逻辑。返回可以是正常的，也可能抛出例外(throw exception)。AspectJ提供三种after类型的通知，分别表示三种不同的返回方式：正常返回、抛出例外、正常返回或抛出例外。a 正常返回： 例如after()returning：myPointCut()。b 抛出例外： 例如after()throwing ： myPointCut()。C 正常返回或抛出例外： 例如after()：myPointCut()。3around。此类通知规定，其执行逻辑将取代连接点处的执行逻辑。要注意的是，如果在通知的执行逻辑中需要完成连接点处的执行逻辑，程序员必须在其中使用
41、特殊关键词-process()，而不能作简单的调用。如果在通知的的执行逻辑中对其连接点处的执行逻辑作任何直接或间接调用，就会再次触发该通知而引发死循环(infinity loop)。第三章 基于UML的面向方面建模方法统一建模语言6( Unified Modeling Language ,UML)是一种对软件系统制品(artifact) 进行详述、可视化、构造和文档化的图形语言。UML广泛用于面向对象系统的建模。UML由对象管理组织(Object Management Group , OMG)管理。OMG于1997年发布了UML1.1，现在发展到UML2.0。 UML是可扩展的，这样可以将其用
42、于不同领域的建模。对面向方面建模的研究主要集中在如何扩展UML使其支持面向方面领域。3.1统一建模语言UML 面向对象的分析与设计(OOA&D)方法的发展在80年代末至90年代中出现了一个高潮,UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson(UML之父)的表示方法,而且对其作了进一步的发展,并最终统一为业界所接受的标准建模语言。UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。3.1.1UML重要元素统一建模语言（UML
43、）提供了一种对软件系统进行可视化、详述、构造和文档化的工业标准机制。UML利用一套动态的、支持不断发展的特征来组织其思想。最新版本UML2.0提供稳定的技术基础结构，考虑到软件开发过程的更多的自动化功能，支持对模型驱动架构的应用。自从UML在上世纪90年代后期首次出现后，软件经历了一次变革-衍生出结构复杂的分布式系统和Web应用系统结构。UML已经适应了这种变化。UML有一种用户配置文件的扩展机制，可以将UML应用于特定的软件问题或者某种业务领域7。UML有多种视图：用例视图、逻辑视图、实现视图、进程视图和部署视图。每种视图由多个图来描述，图中包含了强调系统某个特定方向的信息。同时，一个图又是
44、多个视图的组成部分。从不同视图来观察系统，可以是人们在某段时间内能够集中注意系统的一个方面。例如，若想从外部用户的角度描述系统的功能，可以用用例视图；若想设计系统的体系结构和动态行为，可以用逻辑视图。逻辑视图包括静态的类图、对象图，动态的状态机、顺序图、协作图和活动图，是最常用的一类设计图。跟本文研究内容相关的是进程视图。进程视图显示的是与系统内与进程性能相关的一些主要元素，其目的是将系统划分为多个进程，并将其分配到各个处理器上。它考虑的是系统的非功能性方面，重点是系统的并发性。进程视图由状态机、交互图（顺序图和协作图）、活动图和部署图组成。本文用性能场景图和扩展的分层队列网替代上述的进程视图
45、，使焦点集中在性能建模与分析。性能场景图的原型之一是顺序图。顺序图的重点是显示对象之间发送的消息的时间顺序，同时也显示对象之间的交互。图中时间是从上到下推移的，消息使用位于垂直对象线之间带消息箭头的直线表示。一个顺序图表示一个交互片断，也称为场景。给场景添加上时间因素，可以描述一个交互的响应时延。为了避免使UML过于复杂，UML省略了一些在其它建模语言中可以找到的细节信息。同时，UML预留了一些补救措施扩展机制。UML的扩展机制是显式存在的，用户可以轻松地为特定领域添加新的语义和新的内容。UML2.0体系结构现在属于一个范围更广泛的建模领域，几乎能提供所有的方案。UML有三种扩展元素：构造型（
46、stereotype）、标记值（tagged value）和约束（constraint）。构造型可以对任意的UML元素添加新的或额外的语义，每个构造型对应UML元模型中的一个元类。例如用表示方面元类。标记值可以为模型元素添加新的特征，表示为名称值。约束是指用来对UML中的元素的语义进行限制的规则，表达约束的字符串用花括号括起来。约束表达式可以是UML对象约束语言（OCL），也可以是程序设计语言，也可以是形式化符号，甚至是自然语言。3.1.2UML的可扩展性 UML的扩展机制包括构造型(stereotype)、标记值(tagged value)和约束(constraint )。 UML允许继承原
47、有构造块来生成新的构造块，这些新的构造快就是构造型。新的构造块与基构造块有同样的结构，但是可以有不同的语义、不同的约束、不同的标记值。每个构造型对应 UML元模型中的一个元类。在图形上，构造型可以表示为用书名号括起来的名称，如Aspect，也可以为构造型定义一个新的图符。标记值可以为模型元素添加新的特征，如软件的版本信息.标记值可以表示为名称=值。约束扩展了建模元素的语义，可以增加新的规则或修改语义。约束用“ ”括起来的串表示。3.2用UML进行面向方面建模由于面向方面是一个新的编程典范，而UML主要应用于面向对象系统的建模，用UML 进行面向方面的建模就要使用合适的图符来表达方面概念，也要给这些图符赋予正确的语义。这不但需要正确表示面向方面中的元素，而且还要能用清晰的方式表达方面与基本类(核心类)之间的关系8。由于面向方面建模是一个比较新的领域，实际上面向方面编程的方法也还在发展中，所以并没有形成统一的建模方法。为了能从整体上了解面向方面社区在建模领域的研究，本节比较全面的介绍了各种建模方法，可以根据参考文献找到这些方法的详细资料。资料9较
