【分布式实时系统面向方面的QoS监控模型】 实时系统模型介绍

　　摘要：分布式实时系统是一个非常重要且资源有限的系统，系统资源的调配策略很大程度上决定了系统是否能满足实时性要求。要制定资源调配策略，首先要标识出实时系统中的各种资源，建立起资源模型。面向方面是一种全新的编程思想，它和面向对象方法结合解决了传统软件开发方法中的一些问题。文章结合面向方面技术，把QoS监控作为一个关注点，通过UML的扩展机制描述了分布式实时系统中资源模型的面向方面的QoS监控模型。
　　关键词：分布式实时系统；面向方面；资源管理；QoS监控模型
　　
　　0　引言
　　
　　动态分布式实时系统广泛应用在对响应与处理时间有较高要求的系统，如汽车，飞机，核反应堆等的控制，这些系统的故障轻则导致经济财产损失，重则对人类生命造成威胁。动态分布式实时系统是一个资源有限的系统，能否确保系统的实时性，在很大程度上取决于系统资源的调配策略。制定资源调配策略，首先要标识出实时系统中的各种资源，建立资源模型。在资源模型中，Qos(Quality of Service)对系统的行为进行监控，以保证系统在规定时间内完成任务。所以QoS监控对分布式实时系统来说是非常重要的。本文结合面向方面技术，利用UML的扩展机制描述了分布式实时系统中资源模型的面向方面的QoS监控模型。
　　
　　1　面向方面
　　
　　面向方面编程AOP(Aspect-Oriented Programming)是一种全新的编程思想，被认为是一种影响二十一世纪人类生活，工作方式，及经济的技术思想。它将非功能需求形成的横切关注点从功能需求形成的核心关注点中分离，从而可以将非功能需求与功能需求分别模块化，单独进行设计与编码，最后将两者的代码编织在一起形成最终的系统。面向方面编程(AOP)的思想与面向对象编程(OOP)的思想从思维方向上有很大的不同，它将系统开发时一维的思维方式转变成二维的思维方式。利用面向方面编程(AOP)可以解决软件开发过程中因代码杂混、分散，导致软件开发过程的可追踪性差、开发效率低，特别是代码的复用性不好、代码质量不高、软件系统维护困难等一系列问题。文献对UML在面向方面建模方法进行了探讨，通过引入时间方面来表达系统的时间特性，并对UML进行相应的扩展来建立面向方面的实时系统模型。
　　
　　
　　2　资源模型
　　
　　UML有两个profile(剖面法)与实时系统建模有关，一个是“可调度性、性能和时间说明规范的UMLTMprofile”，另一个是“建模服务质量和容错的特征及机制的UMLTMprofile”。第一个profile定义了实时系统通用资源模型，也定义了可调度性和性能分析模型。用UML描述实时系统其核心就是对Qos的描述。QoS信息直接或间接地代表了与模型相关的应用系统的软、硬件资源的物理属性。第二个profile则定义了资源使用模型。实时系统的研究对象是系统资源。系统资源是指CPU、储存空间、传输带宽等软硬件资源。在实践中系统资源是有限的，而且大多数是共享的，当一个资源需要同时处理多于一个的请求时，就要以一定的策略轮流响应不同请求。在实时系统中，响应时间的正确与否决定了系统的正确性；而能否在要求的时间内作出响应，很大程度上取决于系统资源的调配策略。要制定资源调配策略，首先就要标志出实时系统中的各种资源。
　　核心资源模型定义了资源和QoS的本质概念，这些概念也是实时资源模型的基础；驱动模型描述了实时系统实例行为间的因果关系；资源使用模型则体现了客户(服务使用者)的概念，它描述客户使用系统资源及其服务的模式；资源管理由资源、资源代理和资源管理器几个不同的功能角色组成；资源类型描述了按不同标准划分的资源分类；实现模型则描述了资源之间的关系。文献介绍了如何定义QoS，管理QoS。
　　
　　3　基于QoS的资源管理结构
　　
　　文献6介绍了基于QoS的资源管理结构。资源管理体系结构(图1)主要由5个子系统构成：资源申请、QoS管理，资源调度、资源管理和资源配置管理。资源申请模块在用户提交任务后，为应用创建一个资源集，负责本地或远程资源的申请；QoS管理模块执行层次转换，把应用Qos映射为系统QoS，根据资源的QoS协商结果，决定是否预留资源，在任务运行时监控任务资源的活动情况和QoS变化，作出维持QoS、QoS降级和关闭服务的决定；资源调度模
　　 块根据资源预留情况，采用不同的调度策略来分配资源，控制资源管理模块的执行；资源管理模块收集计算资源和网络资源的使用率和可用率，并且控制资源访问；资源配置模块用于管理和分析硬件的配置信息，其中资源配置文件描述了计算资源和网络资源的属性和特征，其它模块从它这里获取所要的信息。
　　
　　4　面向方面的QoS监控模型
　　
　　从以上所述，可以看出QoS监控可以作为―个关注点横切系统，以下就描述了分布式实时系统中资源模型的面向方面的QoS监控模型。
　　QoS监控主要是通过底层获得正在进行的Qos级别。QoS监控在资源管理模块中发挥着非常关键的作用，例如资源管理要根据QoS监控提供的QoS参数决定是否对资源预留。此外，用户对QoS的需求是变化的，且网络上提供的资源也是动态变化的(如带宽的大小)，为了要保证应用的QoS，用户就要对系统的行为进行必要的监控。从监控方法来看，不同的QoS参数反映了分布实时应用的不同服务需求，难以采用统一的动态监测方法，所以对不同的应用应采用不同的监控方法。下面我们看一个简化的资源监控模型――客户请求监控模块设置任务的QoS。在这样的场景中，考虑了三种不同的实体，用户实体(Client)，监控实体(QoSMonitor)，代理实体(QoSBroker)。图2展示了本例UML类图的简化版本，图中只示出了QoSMonitor和QoSBroker类。Client只关心自己任务Qos的变化，因此QoSBroker提供了startupOrder()这个带参数的操作(没有在类图显示)来描述操作的类型(维持QoS、QoS降级、关闭)、processid、要求资源QoS活动条件。Client一般根据在给定的时间内是否能完成任务来确定资源QoS活动条件。当监测到不能完成任务时，就会触发触发警报，然后决定下一步的动作，决定是调用degradation()方法(Qos降级)还是调用closeQoS()方法(关闭Qos)。我们在QoSMonitor中就提供了一个设置警报的操作即setAlert()方法。为了实现容错，当用户调用了startupOrder()方法时，代理类将复制它的状态。当该操作完成之后，状态又一次被复制。此外为了能保持被通知有关QoSMonitor所实施的操作细节，在QoSBroker中提供了confirm()这个方法。
　　图3为该示例的一个时序图。setAlert()和alarmTrigger()都仅仅用于协调，它横切了QoSBroker和QoSMonitor类，而duplicate()方法只是用于复制，它横切了QoSBroker类的不同示例。如果用面向对象方法来处理这些属性。会导致代码分散在许多组件中，这样就造成了代码分散。而且一个基于Java或者其它语言的实现将导致不同实体的集合(对象，组件或者其它)有相同的接口。在各个组件中，业务逻辑代码和系统日志、安全、同步等代码交织在一起，将导致代码交织。这种解决方案不但妨碍了对于单独关注点的处理，而且将影响很多系统性能，如可维护性和可重用性等。
　　我们采用AOP方法时就可以把协调和复制问题分离成不同的关注点即不同的方面，然后横切到系统中，如图4所示。这样，在QoSBroker和QoSMonitor类中，我们只关注于那些功能性问题，而协调和复制这两个方面现在被封装在两个不同的实体之中。在每个方面中定义了不同的切入点，每个切入点定义了一组位置，方面代码将被植入其中。例如，PC_dupli切入点描述了在方法starmpOrder()和confirm()方法执行之后，方法duplicate()必须被执行。这种AOP方法简化了对系统行为中形成的不同关注点的判断。协调或者复制的改变不影响到其他模块，这样就被很好的局部化了，提高了可维护性。此外它还提高了不同方面的代码的可重用性和适配性。
　　
　　5　结束语
　　
　　分布式实时系统是一个正处于发展期的系统，许多方面还有待进一步研究和完善。资源管理是分布式实时系统一个很重要的组成部分。本文采用AOP方法，给出了分布式实时系统资源管理的面向方面QoS监控模型，很好地解决了开发过程中的代码杂混、分散等问题。