基于网格的面向agent软件分析与设计建模方法及环境研究(1)

《基于网格的面向agent软件分析与设计建模方法及环境研究(1)》由会员上传分享，免费在线阅读，更多相关内容在学术论文-天天文库。

上海大学博士学位论文摘要网格是一种由硬件和软件构成的信息技术基础设施，能提供可靠的、可协调的、可扩展的和廉价的高端计算能力的访问，并支持动态的、分布式的虚拟组织之间不同资源的共享和协作。基于网格的问题求解称作网格计算，网格计算是近年来兴起的一个研究热点。网格计算环境具有异构性、可扩展性、动态自适应性等特点，这些特性使得运行在网格平台上的软件系统不同于在集中和封闭环境下发展起来的传统软件形态，将呈现出以自主性、协同性、开放性以及互操作性为基本特征的全新形态。我们将这种新的软件形态定义为网格软件，或称网格分布式系统。软件建模技术的发展是通过不断提出更具表达能力、更符合人类思维模式的抽象机制来为复杂系统建立模型。过程抽象、抽象数据类型、以及目前比较常用的“对象”和“组件”都属于这样的抽象机制。目前在软件领域占主导地位的软件方法是面向对象方法，但是面向对象软件技术体系其本质上是一种静态和封闭的框架体系，难以适应网格环境开放、动态和多变的特点，因此，网格软件这种新型的软件形态对传统的软件理论、方法、技术和平台提出了一系列挑战。从分布式人工智能观点考虑，网格计算和多Agent系统具有很强的相似性。最明显表现在多Agent系统中的实体和网格实体都具有自治性iAgent还具有其他一些和网格实体相关的特性，如社会能力、自适应性和自发性等；同时，Agent和网格实体～样具有异构性，不同的Agent可以由不同的程序设计语言、体系结构和技术实现，Agent的这些特点使之成为研究网格实体的一种重要的抽象机制。当前主要的面向Agent建模技术基本上是针对传统的封闭式软件体系结构而提出，对于网格软件的建模缺乏有效的概念抽象枧制和直观的模型描述，基于对现有网格技术和主要面向Agent软件工程方法的研究，我们选择OGSA开放式网格体系结构做为网格软件的运行平台(或称应用背景)，依照面向Agent软件工程的要求，提出以Agent做为基本单元的分析策略，形成了AOMG(Agent-OrientedModelingbasedOilGrid)软件建模方法，能够有效地建立基于网格的新型分布式系统模型。该方法的研究内容主要包括：(1)提出了以0GSA网格体系结构为应用背景，基于Agent抽象机制的分布式软件系统结构。(21在传统Agent定义的基础上，结合网格软体形态的一些特征和OGSA结构的以服务为核心的基本思想，对Agent概念重新定义，并引入虚拟组织、开放式组织、网格Agem(GridAgent)和Agent服务等新的抽象概念，为网格软件的分析和设计建模提供概念抽象机制：(3)通过改进现有的i·建模框架以及对UML的扩展，结合组织建模思想，AOMG提供了一套适合描述网格分布式应用的可视化建模框架，通过统一的可视化模型语言实现了对网格软件的直观描述。在建立模型语言的同时，AOMG建模框架提出了基V 海大学博L学位论文于元模型层次的模型变换规则，很好地解决了需求分析过程中的Agent抽取问题，缩小了设计过程中从Agent抽象层次到对象层次之间的鸿沟。(4)任何一种系统化的建模方法，都必须建立在对建模概念和基本模型的语法和语义的精确定义的基础上。为此，在AOMG建模概念基础上，通过扩展Object．Z，我们提出了AOMG形式化建模框架，FormalAOMG。该框架为AOMG建模方法中各种概念和元模型提供了精确无二义性的定义，同时为AOMG可视化建模框架中的模型变换规则提供了基于精确语义描述的形式化基础。FormalAOMG既可以做为独立的针对网格软件的形式化建模语言，也可以做为AOMG建模方法在后续设计、实现和模型验证过程中的一种补充。(5)对于网格软件来说，为了实现服务的共享，如何在网格环境中选择资源以及如何为其他网格应用提供资源是需要解决的重要问题，因此需要提供一种有效的资源匹配机制。在AOMG建模方法中，我们采用了基于本体的资源匹配方法。通过扩展U／VIL类图来建立网格应用的资源本体模型，而为了准确快速地构造基于OWL(WebOntologyLanguage)的可用本体，我们在UML和OWL之间建立一个元模型语义映射关系表。(6)为了验证AOMG方法体系中各种建模思想以及模型语言的有效性，我们开发了一个基于AOMG方法体系的建模环境一AOMGToolkits。AOMGToolldts建模环境提供了可视化的模型编辑器以及基于元模型层次的模型变换工具，实现了基于OWL的模型存储，同时通过元模型的刻面约束机制实现了AOMG元模型语法的正确性检查。(7)通过一个电子政务网格门户系统完整地演示了网格软件系统的需求获取、分析模型和设计模型的建立(包括基于形式化框架的模型建立)、Agent的抽取、分析模型到设计模型的映射、资源本体的建立等内容。关键词：网格计算，Agent，网格Agent，网格服务，AOMG建模方法，Object—Z语言，形式化建模框架，本体，OWL，模型映射规则，模型语法检查VI E海大学博士学位论义ABSTRACT“Grid”isahardwareandsoftwareinfrastructurethatprovidesdependable，consistent，pervasive，andinexpensiveaccesstohi曲一endcomputationalcapabilities．Gridcoordinatesresourcesharingandproblemsolvingindynamic，multi-institutionalvirtualorganizations．Grid-basedProblemSolvingiscalledgridcomputing，whichhasemergedasaresearchhotspotfieldcurrently．Distributedenvironmentbasedgridcomputinghascharacteristicssuchasheterogeneity,extensibility,opennessandadaptability．Therefore，softwaresystemsbasedon鲥dinfrastructurearedifferentfromsoftwaresystemsbasedonconventionaldistributedenvironment．Itistoappearautonomous，cooperately,openandinteroperable．WecalledthissoftwareformGridSoftware，orGridDistributed@stem．Progressinsoftwaremodelingtechnologiesoverthepasttwodecadeshasbeenmadethrou【曲thedevelopmentofincreasinglypowerfulandnaturalhi曲一levelabstractionswimwhichtomodelmaddevelopcomplexsystems．Proceduralabs订acfion，abstractdatatypes，and，mostrecently,objectsandcomponentsareallexamplesofsuchabstractions．Objeethasbecomethechiefparadigminsoftwareengineeringfield，whereas，object—orientedmodelingmethodisastaticandclosetechnologyframeworkinessence．FromtheperspectiveofGr耐Software．object—orientedmethodsaredifficulttoadaptwelltothefeaturesofgridsoRware．Thedevelopmentofgridcomputinghaschallengedconventionalsoftwarearchitectures，methods，technologiesandplatforms．If鲥dcomputingisconsideredfromaDistributedArtificialIntelligence(DAI)perspective，itissimilartoaMulti—AgentSystem(MAS)，sinceentitiesinaMASandthegridhaveautonomousbehavior．Autonomyisoneofthekeyabstractionfeaturesofagents．Otherfeaturesofagentsrelevanttogridentitiesincludesocialability,aswellasadaptabilityandpro—activeness．DifferentInaddition，softwareagentsareheterogeneous，whichcouldbeimplementedindifferentprogramminglanguagesandtechnologies．Thesecharacteristicsofagentsjustifytheselectionofagentsasthemainabstractionformodelinggridsoftware．Mostoftoday’sAgent-orientcdmodelingmethodsemphasizemodelingconventionalclosesoftwarearchitecture，andwhilemodela面dsoftware，theylackofeffectiveconceptabstractionanddeclarativemodels．Basedontheresearchofgridarchitectureandmainagent-orientedsoftwaremodelingmethods，thisthesisputsforwardanewmodelingmethodforagent-orentedanalysisanddesignbasedonOGSAarchitecture，AOMG(Agent—OrientedModelingbasedonGrid)．ThemainresearchcontentsofAOMGmethodinclude：1．Proposesamulti—agentarchitectureofthedistributedsoftwarethatbasedonOGSAgridinfrastructure．V¨ 上海大学博士学位论文2．Basedontraditionaldefinitionofagent，incorporatingthecharacteristicsofGridSoftwareandtheideaofgridservicefromOGSA，AOMGredefinestheconceptofagent，aswellintroducessomenewabstractionconcepts(suchasVirtualOrganization，GridAgentandGridService)relatedtogirdarchitecture．Thesenewconceptsprovideanabstractionmechanismformodeling面dsoftware．3．Byimprovingi+frameworkandextendingUML，andtakingviewpointsfromOrganization，AOMGpresentsavisualmodelingframeworkforgridsoftware．Atthesametime，AOMGprovidesmodelmappingrulesbasedonmeta-modellevel，whichsolvetheproblemofagent’Selicitationduringrequirementanalysisstage，andnarrowthegapbetweenanlysismodelsatagent-levelanddesignmodelsatobject—level，4．AtthebasisofAOMGmodelingtheory,byextendingObject—zlanguage．thisthesisproposesaformalmodelingframework，FormalAOMGThisformalframeworkprovidesmeaningsforcommonconceptsandtermsofAOMGpreciselyandunambiguously,anddoesSOinareadableandunderstandablemanner．Aswell，itprovidesafoundationforsubsequentdevelopmentofnewandincreasinglymorerefinedconcepts，aswellprovidesformalfoundationformodels’transformationanddevelopmentofvisualmodelingenvironment，5．Inordertoenableresourcesharingandcoordinatedproblemsolvingindynamicmulti-institutionalvirtualorganizations，it’Snecessarytosolvetheresourcematchingproblem．InAOMGmethod，Weproposeanontology-basedresourcematchingmethod，andpresentaresourceontologymodelbyextendingUMLclassmodel．Ameta-modelmappingruletablebetweenUMLandOWLisproposedtofacilitatetheconstructionofOWL-basedresourceontology．6．Inordertotestthevalidityoftheabovemethods，wedevelopamodelingenvironmentbasedonAOMGmethod，AOMGToolkits．Thismodelingenvironmentsupportsdevelopertomodelsystemvisually,analyzeandcheckmodels．AOMGToolkitsstoremodelsinOWLformat，andcheckmodelsyntaxbyintroducingmeta-model’Sfacetconstraint．7Throughane-government鲥dportalapplicationexample，wedemonstratetherequirementacquirementofgridsoftware，thecreationofanalysismodelsanddesignmodels(aswellformalmodels)，elicitationofagents，themappingfromanlysismodelstodesignmodelsandthecreationofresourceontologymodel．Keywords：GridComputing，GridSoftware，Agent，GridAgent，GridService，AOMG，Object-Z，FormalAOMG，Ontology，OWL，Meta-ModelMapping，ModelSyntaxCheckingVIII 上海大学博十学位论文图目录图2．1开放式网格服务(OGSA)架构图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．14图2．2网格服务示意图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．15图23基于OGSA的软件体系结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．18圈2．4AOMG模型框架⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．⋯⋯⋯⋯⋯⋯⋯⋯⋯20图2．5AOMG组织模型中的元模型表示⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．22图2．6实例1系统组织模型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯23图2．7角色模型模板⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯，24图2．8实例1中ProductSeeker角色模型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯24图2．9实例1Agent交互模型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯25图2．10实例1Agent类模型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．28圈211实例1Agent通信模型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．28图2．12实例1中ProductSeekerAgent移动模型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．30图2．13Agent服务模型模板⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．3l图2．14实例1中ProductSeekerAgent服务模型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．32图3．1Object—Z元模型组织结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．34图3．2基于Object—Z的AOMG元模型语义结构图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．35图4．1基于语义Web本体的资源匹配过程⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯48图4．2“Skeletal”本体构造法流程图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．51图4．3基于UML的资源本体模型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯一54图5．1AOMGToolkits体系结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯59图5．2AOMGToolkits环境基本设计框架⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．59图5．3AOMG模型层次图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．60图5．4环境元模型概要设计类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯61图5．5AOMG概念元模型设计类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．62圈5．6AOMG语义元模型类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯63图5．7模型框图设计类图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．63图5．8抽象语义层类定义⋯⋯⋯⋯⋯⋯⋯⋯⋯．⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯64图5．9外部模型引入流程⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯65图5．10部分AOMG元模型附属-依赖关系⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯66图61依赖模型的语法约束⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．71图6．2基于KBeans软件包的自动检查机制⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．74訇6．3基于KBeans的语法检查主要类模型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．77羽6．4语法检查实例⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．78IX r海大学博士学位论文图7．1AOMG视图模型结构树⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．⋯⋯⋯⋯⋯．⋯⋯⋯⋯．⋯⋯⋯图7．2E．GovPortal系统结构图⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．⋯．．图7．3E。GovPoem系统组织模型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯图7．4NewsCollector角色模型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯图7．5E．GovPortal系统Agent交互模型⋯⋯⋯⋯⋯⋯⋯图7．6E．GovFoCal系统Agent类图(部分)⋯⋯⋯⋯⋯⋯图7，7E．GovPoem系统Agent通信模型⋯．⋯⋯⋯⋯⋯⋯图7．8Message内容结构⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．．图7．9CompanyRegistryAgent移动模型⋯⋯⋯⋯⋯⋯⋯图710WeatherAgent服务模型⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯图7．11E．GovPortal系统资源本体模型(Weather部分)⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯表目录表2．1AOMG元模型概念框架⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．⋯⋯⋯⋯⋯⋯表2．2扩展后的Agent类图元模型对照表⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯表23从AOMG组织模型到基于UML的Agent类模型的映射规则表⋯表2．4实例1中ProductSeekerAgent移动算法⋯⋯⋯⋯⋯⋯⋯．⋯⋯⋯⋯表4．1从UML到OWL的语义映射关系表⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．表6．1AOMG语法约束分类⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯．．表6．2K．Beans刻面类型⋯．⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯⋯X80⋯83⋯85⋯86．．．．87⋯．88．．．．89⋯．89．．．．90．．．．91⋯．92⋯20⋯27．．3l⋯55．．．73⋯75 原创性声明本人声明：所呈交的论文是本人在导师指导下进行的研究工作。除了文中特别加以标注和致谢的地方外，论文中不包含其他人已发表或撰写过的研究成果。参与同一工作的其他同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示了谓}意。签名：日期：p够3"-．厢本论文使用授权说明本人完全了解上海大学有关保留、使用学位论文的规定，即：学校有权保留论文及送交论文复印件，允许论文被查阅和借阅；学校可以公布论文的全部或部分内容。(保密的论文在解密后应遵守此规定)日期：抄于．r留 ￡海大学博士学位论文1．1网格计算与网格软件1。1．1网格概念及其特点第一章绪论1“网格”是构筑在Intemet上的一种新型的信息技术基础设施，它将高速互联网、高性能计算机、大型数据库、传感器、远程设备等融为一体，实现计算资源、存储资源、通信资源、软件资源、信息资源、知识资源的全面共享。1998年，IanFoster[1]首次对网格进行定义：计算网格是一种由硬件和软件构成的信息技术基础设施，它能提供可靠的、可协调的、可扩展的和廉价的高端计算能力的访问。2001年，IanFoster[2]等人进一步深化了网格计算和它的基础构件是作为支持动态的、分布式的虚拟组织(VirtualOrganizations)的不同资源的共享和协作的系统。网格概念的核心就是突破了以往强加在计算资源上的种种限制，使人们可以以一种全新的更自由、更方便的方式使用计算资源，解决更复杂的问题：首先，网格突破了了计算能力大小的限制；其次是突破了地理位置上的限制；最后就是网格打破了传统的共享或协作方面的限制，以前对资源的共享往往停留在数据文件传输的层次，而网格资源的共享允许对其它的资源进行直接的控制，而且共享资源的各方在协作时可以通过各种方式更广泛地交流信息，充分利用网格提供的各项功能。总之，网格技术的目标是基于Intemet、Web和高性能计算等技术，采用开放标准，实现网络虚拟环境上的资源共享和协同工作，消除信息孤岛和资源孤岛。网格计算环境是一种无缝、集成的计算和协作环境。它具有如下特点：(1)异构性：网格可以包含多种异构资源，包括跨越地理分布的多个管理域。构成网格计算系统的超级计算机有多种类型，不同类型的超级计算机在体系结构、操作系统及应用软件等多个层次上可能具有不同的结构。(2)可扩展性：元计算系统初期的规模较小，随着计算机系统的不断加入，系统的规模随之扩大。网格可以从最初包含少数的资源发展到具有成千上万资源的大网格。由此可能带来的一个问题是随着网格资源的增加而引起的性能下降以及网格延迟，网格必须能适应规模的变化。(3)动态自适应性：在网格计算中，某一资源出现故障或失败的可能性较高，资源管理必须能动态监视和管理网格资源，从可利用的资源中选取最佳资源服务。(4)不可预测性：动态和不可预测的系统行为。在传统的计算系统中，计算资源是独占的，因此系统的行为是可预测的。而在网格计算系统中，由于资源的共享造成系统行为和系统性能经常变化。(5)多级管理域：由于构成网格计算系统的超级计算机资源通常属于不同的机构或组织，奉论文由国家自然科学基金No．60275022提供资助 J．海大学博士学位论文并且使用不同的的安全机制，因此需要各个机构或组织共同参与于解决多级管理域的问题。1．1．2网格体系结构网格体系结构能LkIntemet更l有效地利用网上的所有资源。如何自动地把用户最需要的信息放在离用户“最近”的服务器上，如何让用户尽快得到所需信息而不管信息到底存放在什么地方，如何去自动平衡负载，如何使网格上的多台高性能计算机协同工作等，都是设计网格系统的体系结构所要考虑的问题。网格体系结构必须划分系统基本组件，指定系统组件的目的与功能，说明组件之间如何相互作用的技术。到目前为止，比较重要的网格体系结构有两个：一个是Foster等在1999'-年提出的五层沙漏结构[2]；然后就是在以ⅢM为代表的工业界的影响下，在考虑到w曲技术的发展与影响，Foster等结合WebService!提出的开放网格服务结构OGSA(IOpenGridServiceArchitecture)J3][4][5]。五层沙漏结构是一种影响十分广泛的结构，它的主要特点是简单。五层沙漏结构将网格分为五层：构造层(提供网格中可供共享的资源)、连接层(提供安全便利的通信)、资源层(提供对单个资源的共享)、汇集层(协调各种资源的共享)和应用层(对网格用户提供各种应用支持1。五层沙漏结构以“协议”为中心，强调协议在网格的资源共享和互操作中的地位，通过协议可以实现一种机制，使得虚拟组织的用户和资源之间可以进行资源使用的协商，建立共享关系，并且可以进一步管理和开发新的共享关系。同时，五层沙漏结构非常强调服务与API(ApplicationProgrammingInterfac妙和SDK(SoftwareDevelopmentKits)的重要性，在这种结构中提供了API和SDK，使得在建立网格应用时可以在抽象的基础上提高编程级别。这一标准化的开放结构对网格的扩展性、互操作性、一致性以及代码共享都很有好处。OGSA开放式网格服务体系OGSA是目前最新也最有影响力的一种网格体系结构，被称为是下一代的网格结构。这种结构结合了网格和WebService[6]技术，是对以资源为中心的五层沙漏结构的改进。OGSA是面向服务的结构，将所有事务都表示成一个网格服务，计算资源、存储资源、网络、程序、数据等都是服务，所有的服务都联系对应的接口，所以，OGSA；破称为是以服务为中心的“服务结构”，它通过标准的接口和协议支持创建、终止、管理和开发透明的服务。OGsA的发展象征着WebService的一个进步，结合目前的WebService!技术，支持透明安全的服务实例。因此，OGSA；有效地扩展了WebService架构的功能。五层沙漏结构与OGSA都相当重视互操作性，但OGSA更强调服务的观点，将互操作性问题转化为定义服务的接口和识别激活特定接口的协议。基于OGSA，网格计算的实施方案可以在任何基础平台上有效地协调使用全球各地的应用资源来加强web服务。依靠对网格计算和对web服务的支持，各组织不仅可以更加有效的利用自己的资源，同时还可以实现与合作伙伴及供应商业务流程的集成，从而解决复杂的业务问题。1．1．3基于网格体系结构的软件形态从软件的运行平台上来看，早期软件以面向单CPU／多CPU的集中封闭机器结构为基础，着重发展特定或局部环境下简单通讯协同的软件技术。随着网络技术的发展，出现了以网2 上海大学博士学佗论文并且使用不同的的安全机制，因此需要各个机构或组织共同参与于解决多级管理域的问题。1．1．2网格体系结构网格体系结构能1．EIntemet更有效地利用网上的所有资源。如何自动地把用户最需要的信息放在离用户“最近”的服务器上，如何让用户尽快得到所需信息而不管信息到底存放在什么地方，如何去自动平衡负载，如何使网格上的多台高性能计算机协同工作等，都是设计网格系统的体系结构所要考虑的问题。网格体系结构必须划分系统基本组件，指定系统组件的目的与功能，说明组件之间如何相互作用的技术。到目前为止，比较重要的网格体系结构有两个：一个是FosteC窨在1999年提出的五层沙漏结构[2]；然后就是在以ⅢM为代表的工业界的影响下，在考虑至4w曲技术的发展与影响，Foster等结合WebService提出的开放网格菔务结构OGSA(OpenGridServiceArchitecture)[3][4][5]。五层沙漏结构是～种影响十分广泛的结构，它的主要特点是简单。五层沙漏结构将网格分为五层：构造层(提供网格中可供共享的资源)、连接层(提供安全便利的通信)、资源层(提供对单个资源的共享)、汇集层(协调各种资源的共享)和应用层(对网格用户提供各种应用支持)。五层沙漏结构以“协议”为中心，强调协议在网格的资源共享和互操作中的地位，通过协议可以实现一种机制，使得虚拟组织的用户和资源之间可以进行资源使用的协商，建立共享关系，并且可以进一步管理和开发新的共享关系。同时．五层沙漏结构非常强调服务与API(ApplicationProgrammingInterface)和SDK(Sotb,vareDevelopmentKits)的重要性，在这种结构中提供了API和SDK，使得在建立网格应用时可以在抽象的基础上提高编程级别。这一标准化的开放结构对网格的扩展性、互操作性、一致性以及代码共享都很有好处。OGSA开放式网格服务体系OGSA是目前最新也最有影响力的一种网格体系结构，被称为是下～代的网格结构。这种结构结合了网格和WebService[6]技术，是对以资源为中心的五层沙漏结构的改进。OGSA是面向服务的结构，将所有事务都表示成一个网格服务，计算资源、存储资源、网络、程序、数据等都是服务，所有的服务都联系对应的接口，所以，OGSA被称为是以服务为中心的“服务结构”，它通过标准的接口和掷议支持创建、终止、管理和开发透明的服务。OGSA的发展象征着WebService的一个进步，结合目前的WebService技术，支持透明安全的服务实例。因此，OGSA有效地扩展了WebService架构的功能。五层沙漏结构与OGSA都相当重视互操作性，但OGSA更强调服务的观点，将互操作性问题转化为定义服务的接口和识别激活特定接口的协议。基于OGSA．网格计算的实施方案可以在任何基础平台上有效地协调使用全球各地的应用资源来加强web服务。依靠对网格计算和对Vqeb服务的支持，各组织不仅可以更加有效的利用自己的资源，同时还可以实现与合作伙伴及供应商业务流程的集成，从而解决复杂的业务问题。1．1．3基于网格体系结构的软件形态从软件的运行平台上来看，早期软件以面向单CPU／多CPU的集中封闭机器结构为基础，着重发展特定或局部环境下简单通讯协同的软件技术。随着网络技术的发展，出现了以网2 J．海大学博士学位论文并且使用不同的的安全机制，因此需要各个机构或组织共同参与于解决多级管理域的问题。1．1．2网格体系结构网格体系结构能LkIntemet更l有效地利用网上的所有资源。如何自动地把用户最需要的信息放在离用户“最近”的服务器上，如何让用户尽快得到所需信息而不管信息到底存放在什么地方，如何去自动平衡负载，如何使网格上的多台高性能计算机协同工作等，都是设计网格系统的体系结构所要考虑的问题。网格体系结构必须划分系统基本组件，指定系统组件的目的与功能，说明组件之间如何相互作用的技术。到目前为止，比较重要的网格体系结构有两个：一个是Foster等在1999'-年提出的五层沙漏结构[2]；然后就是在以ⅢM为代表的工业界的影响下，在考虑到w曲技术的发展与影响，Foster等结合WebService!提出的开放网格服务结构OGSA(IOpenGridServiceArchitecture)J3][4][5]。五层沙漏结构是一种影响十分广泛的结构，它的主要特点是简单。五层沙漏结构将网格分为五层：构造层(提供网格中可供共享的资源)、连接层(提供安全便利的通信)、资源层(提供对单个资源的共享)、汇集层(协调各种资源的共享)和应用层(对网格用户提供各种应用支持1。五层沙漏结构以“协议”为中心，强调协议在网格的资源共享和互操作中的地位，通过协议可以实现一种机制，使得虚拟组织的用户和资源之间可以进行资源使用的协商，建立共享关系，并且可以进一步管理和开发新的共享关系。同时，五层沙漏结构非常强调服务与API(ApplicationProgrammingInterfac妙和SDK(SoftwareDevelopmentKits)的重要性，在这种结构中提供了API和SDK，使得在建立网格应用时可以在抽象的基础上提高编程级别。这一标准化的开放结构对网格的扩展性、互操作性、一致性以及代码共享都很有好处。OGSA开放式网格服务体系OGSA是目前最新也最有影响力的一种网格体系结构，被称为是下一代的网格结构。这种结构结合了网格和WebService[6]技术，是对以资源为中心的五层沙漏结构的改进。OGSA是面向服务的结构，将所有事务都表示成一个网格服务，计算资源、存储资源、网络、程序、数据等都是服务，所有的服务都联系对应的接口，所以，OGSA；破称为是以服务为中心的“服务结构”，它通过标准的接口和协议支持创建、终止、管理和开发透明的服务。OGsA的发展象征着WebService的一个进步，结合目前的WebService!技术，支持透明安全的服务实例。因此，OGSA；有效地扩展了WebService架构的功能。五层沙漏结构与OGSA都相当重视互操作性，但OGSA更强调服务的观点，将互操作性问题转化为定义服务的接口和识别激活特定接口的协议。基于OGSA，网格计算的实施方案可以在任何基础平台上有效地协调使用全球各地的应用资源来加强web服务。依靠对网格计算和对web服务的支持，各组织不仅可以更加有效的利用自己的资源，同时还可以实现与合作伙伴及供应商业务流程的集成，从而解决复杂的业务问题。1．1．3基于网格体系结构的软件形态从软件的运行平台上来看，早期软件以面向单CPU／多CPU的集中封闭机器结构为基础，着重发展特定或局部环境下简单通讯协同的软件技术。随着网络技术的发展，出现了以网2 上海人学博士学位论文络环境为核心的分布式系统结构。而新一代软件运行平台将建立在广泛连通的网格Intemet基础上，基于Internet的网格平台成为软件运行的环境。软件本身既强调自治性、又强调协作性[7]。结合文献[7】对Intemet的描述，从软件运行平台角度，我们认为，网格做为下一代Intemet，它不同于传统计算机的硬件平台，具有如下主要特征：·无统一控制的“真”分布性。·网格节点的高度自治性。·网格节点链接的开放性和动态性。·人、设备和软件的多重异构性。●实体行为的不可预测性。·运行环境的潜在不安全性。·使用方式的个性化和灵活性。●软件应用的高度“服务化”。由于软件系统所基于的计算机硬件平台正经历从集中封闭的计算平台向开放的网格平台的转变，软件系统作为计算机系统的灵魂，随着其运行环境的演变也经历了一系列的变革。目前，面向网络的计算环境正1扫Client／Server发展为CfienffCluster，并正朝着Client／Network年[1Client／VirtualEnvironment的方向发展【8]。那么，未来的基于网格Intemet平台的软件系统又将会呈现出一个什么形态昵?在文献[7]中，杨芙清、梅宏等人这样描述未来基于Intemet的软件形态：“以软件构件等技术支持的软件实体将以开放、自主的方式存在于Intemet的各个节点之上，任何一个软件实体可在开放的环境下通过某种方式加以发布，并以各种协同方式与其它软件实体进行跨网络的互连、互通、协作和联盟，从而形成一种与当前的信息Web类似的SoftwareWeb。这种SoftwareWeb不再仅仅是信息的提供者，而是各种服务(功能)的提供者。它应能感知外部网络环境的动态变化，并随着这种变化按照功能指标、性能指标和可信性指标等进行静态的调整和动态的演化，以使系统具有尽可能高的用户满意度”。他们将这种新的软件形态称为网构软件(Intemetware)。网构软件具备了自主性、协同性、反应性、演化性和多态性等基本特征。网构软件是对未来软件形态的一种广义定义，它代表了未来软件发展的一种趋势。本论文我们所研究的对象——网格软件(或称作网格分布式系统)，也属于网构软件的一种，它具各了网构软件的一些特征，但更多的是基于现有的开放式网格体系结构(OGsA)所定义的一种软件形态，应该说网格软件是网构软件的一个子集。网格软件是在基于网格的Intemet开放、动态的环境下软件系统基本形态的～种抽象，它既是传统软件结构的自然延伸，又具有区别于在集中封闭环境下发展起来的传统软件形态的独有的基本特征：(1)自主性：指网格软件系统中的软件实体具有相对独立性、主动性和自适应性。自主性使其区别于传统软件系统中软件实体的依赖性和被动性： 上海大学博上学位论文(21开放性：开放性表现在网格软件系统中软件实体可以互相提供资源共享，共享的资源包括数据资源、程序模块等。开放性使其区别于传统软件中对象实体的封闭性和集中性；(31互操作性：不同的网格软件中的软件实体具有一定的互操作性，通过定义统一的服务接口来达到不同软件实体之间的互操作。f4)协同性：指网格软件系统中软件实体与软件实体之间可按多种静态连接和动态合作方式在开放的网络环境下加以互连、互通、协作和联盟。协同性使其区别于传统软件系统在封闭集中环境下单一静态的连接模式；1．2基于网格的软件建模与Agent抽象机制软件建模技术的发展是通过不断提出更具表达能力、更符合人类思维模式的抽象机制来为复杂系统建立模型。过程抽象、抽象数据类型、以及目前比较常用的“对象”和“组件”都属于这样的抽象机制。目前在软件领域占主导地位的软件方法是面向对象方法，但是面向对象软件技术体系其本质上是一种静态和封闭的框架体系，难以适应网格环境开放、动态和多变的特点，主要表现在以下三个方面：(1)系统目标和结构确定性的限制：一般说来，在构建系统的过程中，系统的基本功能和基本结构是按照系统所要解决的问题和问题领域的特性通过系统分析与设计逐步确定的，未能兼顾Intemet开放、多变和动态的特性。因此，它难以适虚网格软件系统的动态协同、逐步适应和不断演化的需求。(2)实体单元自主性的欠缺：面向对象方法中的对象概念通常是静止和被动的，它难以在Intemet开放、动态和多变环境下调整自己的目标和行为，以适应网络环境的变化和用户的个性化要求。(3)协同方式的单一性：程序实体间传统的协同方式是过程调用和对象允I(Reference)。一般说来，由于其时间和空间耦合的特征，过程调用和对象允引通常只适合于程序实体功能固定、位置固定、以及协同逻辑固定的静态和封闭世界，难以满足开放、动态和多变的Intemet环境对时间或空间的紧耦合或松散耦合等多种协同方式的需要。可以说，网格软件这种新型的软件形态对传统的软件模型理论、开发方法、开发技术和平台提出了一系列挑战。软件工程的发展是通过不断提出更强大、更自然的抽象机制来建模与开发复杂系统。这使得软件建模与开发不断远离面向机器的观点，而面向人们理解的方法靠近。Agent是近年来出现的一种新的软件抽象机制，它是现有软件抽象思想的进一步发展，反映了人们对客观世界认识的深入，使得开发人员更自然地理解复杂分布式软件系统，并对其进行建模和开发[9】。从分布式人工智能观点[101考虑，网格计算和多Agent系统具有很强的相似性，最明显表现在Agent系统中的实体和网格实体都具有自治性。Agent还具有其他一些和网格实体相关的特性，如社会能力、自适应性和自发性等。同时，Agent和网格实体一样具有异构性，不同的Agent可以由不同的程序设计语言、体系结构和技术实现[11】。Agent的这些特点使之成为研究网格实体的一种重要的抽象机制。4 L海大学博士学位论文随着Agent技术的发展，并逐步成为指导软件开发的主流方法，面l句Agent软件工程已经成为Agent技术研究中的一个非常活跃的领域。这一领域涉及软件工程问题的所有内容，如需求、设计、构造、确认和认证、发布、重用等。需求分析作为软件工程的一个重要阶段不可避免地也引入了这一概念。抛开Agent的具体类型和实现，单从概念来看(由于Agent还没有一个明确的定义，Agent的概念只能采用特定属性的描述来限定)，它不同于传统的对象或过程组件概念，更符合人们对事物的分类习惯以及事物相互交互关系的描述习惯。Agent是一个比对象和类更加抽象的概念[12】，适合作为需求分析的描述对象：即在一个相对抽象的概念层次上对系统进行描述，而不涉及系统实现的具体设计细节。这就象定义一栋房子，在一个建筑工程人员的眼中，一栋房子可以被描述为由许多块砖被精确地放置到固定的位置上而构造出的特定建筑物。但对于大多数普通居民来说，更加符合其描述习惯的方法是在一个相对抽象的层次上描述出～栋房子的结构，如起居室、厨房、卫生间和卧室等。虽然由于Agent概念处于较为抽象的描述层次，使面l句Agent的需求分析不再过多地关注系统实现的细节问题，但仍然需要花费精力精确分析构成系统需求的抽象单元及其组织结构。同样，虽然在一个更加抽象的层次上分析和描述系统组件和组织形式，但自然语言的描述语义还不足以胜任，必须采用严格的形式化描述语言作为建立需求模型的基础。因此可以说，从一般语义描述的需求到分解出满足该需求的一个一个相互交互的抽象Agent及其相关协同模型，同时形成能够满足传统方法进行编程需要的模型，仍然需要进行许多复杂的理解分析工作，必须采用工程的概念，使用工程语言进行精确地描述。目前已经有一些研究人员将网格和Agent这两种范型(Paradigm)相结合应用到商业或非商业领域：CoABS[13]是DARPA资助的一个关于建立面向AgeIlt网格计算环境的项目，它涉及到对Agent强壮性、组群计算以及服务描述语言等多方面的研究；JFIPA[14]是AroundTveit等人采用JAVA语言开发的一种基：]=Agent的网格计算体系结构，它支持在网格环境下节点之间的基于F姒ACL消息的路由和处理；M．Alien和A．Taleb-Bendiab[15]则建议将网格中的Agent做为服务的提供者和消费者进行建模。但目前这些技术都不足以成为能够指导网格软件建模的软件工程方法。1．3主要的面向Agent软件工程方法和建模工具1．3．1面向Agent软件工程方法随着Agent技术研究的不断深化，许多软件工程方法都将Agent概念结合到相关的研究领域中。这种结合主要体现为三种方式：第一：纯面向Agent的软件工程方法。这类方法将Agent概念作为软件工程研究的核心概念，以设计一个以Agent为基本组件的软件系统为最终目标。如Gaia方法和i+框架等[16][17][18]：第二：通过扩展现有的面向对象软件工程方法实现面向Agent软件工程方法。这种方 L海大学博：仁学位论文法希望充分利用现有的面向对象软件工程技术，通过寻找对象和Agent概念之间的共同点，并弥补现有面向对象方法描述面向Agent应用的不足之处，实现面向Agent软件工程的扩展。如AUML和MESSAGE方法等【19][20】；第三：在原有软件工程方法中引入新的Agent概念，辅助软件工程分析的方法。如KAOS方法[21][22】；这一节我们简要介绍当前几种主要的面向Agent软件工程方法。1)Gala方法Gala方法[161是最早提出的纯面向Agent的软件工程方法之一，其主要思想是将分析和设计MAS的过程看作是构建一个计算组织的过程。该方法将MAS看作是由大量自治、交互的实体组成的一个有组织的社会。在分析阶段，该方法建立角色模型和交互模型。角色模型由一组使用Fusion表示法表示的“角色模式”(roleschema)构成【23】，描述每个角色的责任(即角色的功能)和权限(在执行该角色时能使用的资源类型及数量和限制)。交互模型由一组协议定义组成。Gala方法的协议定义着重于交互的本质特性和交互的目的，面不是具体的消息交换序列。协议定义的内容包括：目的、发起者、响应者、协议的输入／输出、以及处理过程等。在Gaia的设计阶段，其任务是建立Agent模型、服务模型和熟人模型。Agent模型描述在系统中所使用的Agent的类型。Agent的类型可看作是一组角色的集合。服务模型识别和每个Agent承担的角色相关的服务，并描述这些服务的属性，包括服务的输入和输出、前置条件和后置条件。熟人模型定义Agent的类型之间的通信关联关系。2li·建模框架和Tropos方法it是一个描述不同战略角色之间的意念关系的框架[17】[24】[25]。开发i+框架的目的主要是支持早期阶段的需求分析建模。战略角色是该框架的核心概念。每个战略角色都带有意图属性，如目标、信念、能力和承诺等。框架的研究焦点是从每个角色的视角上分析需求战略上的含义，并且通过探索和判别可选择的操作过程更好地满足该角色的战略利益。为了在这样的一个抽象层次上建模和推理。该方法描述的关系是在意念层次上的关系，而不是通常的输入和输出的数据关系。角色通过彼此的相互依赖关系实现目标，执行任务以及提供资源。i·框架为早期需求获取提供了两种模型：策略依赖模型和策略原理模型。其中策略依赖模型用于描述组织背景中行为角色之间的彼此依赖关系；丽策略原理模型用于对行为角色意图进行推理以及角色目标进行Means．End分析。Tropos方法是依据i‘框架开发的一个软件工程环境f26]。除了i，框架以外，Tropos方法还结合利用了其他的一些重要软件工程方法，如KAOS方法和AUML方法等。该方法力图吸取其他各类方法的长处，比较全面地覆盖了软件工程所涉及的所有分析领域。Tropos方法支持面向Agent软件开发的五个阶段：早期需求获取、后期需求分析、结构设计、详细设计和实现。3)面向UML的扩展方法UML语言在面向对象的软件工程领域得到了广泛的应用。为了应对新的Agent技术的 上海大学博士学位论文研究热潮，一些UML语言的倡导者希望通过对UML进行扩展实现其面向Agent应用类型的转换。如即将推出的UML2．0标准就是一个新的面向Agent应用的版本。基于UML方法扩展的面向Agent方法具有很多优点[271。首先，UML采用的面向对象范型和面向Agent范型有类似之处。Shoham【281认为，Agent可看作是主动对象，即带精神状态的对象。Odell[191认为，Agent和对象之间的关系可以表示为：Agent=舜]象++。此外，两种范型都强调封装的概念，都采用消息传递方式的通信。其次，UML方法及其所针对的面向对象的技术得到广泛地流行，其正确性和完备性已得到了验证。第三，一些UML模型的表示方法可以直接用于描述面向Agent的系统，如用例图，顺序图，活动图等。但因为Agent和对象本质上存在极大的不同，在使用UML方法对面向Agent系统进行建模时存在许多问题。首先。UML方法提供的基本抽象和基本概念不适合面向Agent系统的分析和设计。Agent和对象提供了不同的抽象级：对象在状态(属性)和行为(方法)级别抽象一个实体；而Agent在对象基础上进一步封装了对行为的控制，这使Agent概念可以从任务和目标级别来抽象一个实体。其次，UML的分析和设计策略不能直接用于面向Agent系统的分析和设计过程。UML方法将具体的事物、组织、事件、行为、甚至交互都作为侯选的对象，并将这些不同质的东西统一地以对象．类形式表示。但对于一个面向Agent的方法来说，一般需要明确地区分它们，并以不同的模型抽象它们。第三，面向Agent模型通常强调社会属性的体现，因此要求对Agent的社会／组织关系进行建模。UML方法无法描述面向Agent系统的社会性交互模型。第四，我们认为对于面向Agent系统，需求模型的重要性大于设计模型的重要性。在需求分析方面，虽然UML标准也提供了针对需求的表示模型，但由于面向对象理论自身的轻需求重设计的特点，对于非常复杂的存在多种特性的MAS系统来说，其用于需求描述的用例驱动模型过于简单，即UML解决的是“How”问题而忽略了“What”和“Whieh”问题。MESSAGE是由欧洲电信组织P907项目提出的一种面向Agent的旨在支持整个软件生命周期的软件工程方法[291。在扩展面向对象的UML模型的同时，该方法在很多方面借鉴了MAS．CommomKADS方法中的内容[301。目前的第一个发行版的MESSAGE方法主要提供了分析阶段的建模方法，还没有涉及到设计、实现阶段。MESSAGE分析阶段的模型包括5部分：Agent模型，组织模型，目标，任务模型、领域模型和交互模型。该方法还具体地定义了如何构造这些分析模型的工作流，以及不同模型之间相互关联的方式。4)KAOS：一种合成系统设计方法所谓合成系统设计(ComposeSystemDesign，CSD)是指由组件或Agent组成的系统，通过它们彼此之间的相互协作完成系统的处理行为。CSD方法的一个重要前提是在设计一个自主系统时，必须将该系统和其所处的环境作为一个整体看待，并将整个扩展了的系统特性作为我们需要实现的目标。KAOS方法是一个基于目标获取需求的框架，采用的是合成系统设计观点『211。KAOS方法认为分析用户需求的最有效的方法应该从整个系统的实现目标开始，逐步分解目标直到它们的责任能够被分配到构成系统的基本组件单元(如Agent组件或对象组件) 上海大学博士学位论文完成。5)F3框架F3框架[311是一种涉及整个需求工程过程的建模框架。该框架的一个重要部分是“企业模型”。企业模型包含有五个子模型：目标模型、概念模型、活动模型(或使用模型)、角色模型和信息系统需求模型。F3框架基于目标驱动．强调理解系统需求背后的商业目标。其中目标模型包含有目标、问题、机会、原因和规则等节点，这些节点通过动机和影响连接在～起。相互之间的影响又可以分为正面的、负面的和未知的等类型。这些节点的内容采用自然语言描述。角色模型以组织单元或角色作为节点单元，这些节点之间的相关性通过连接实现．如Reports—To、Belongs—To、Supplies·Software—To，和Develops·System-For等。角色模型通过“动机”连接目标模型，通过“执行行为”连接活动(或使用)模型，通过“涉及类型”连接信息系统模型。信息系统模型提供更加形式化表示的系统描述模型。通过以上内容，我们可以看出，基于不同的设计理念，这些面向Agent的软件工程方法各有特点，如KAOS方法侧重在依据系统冒标的需求分析方面，p框架侧重于Agent交互关系的描述。而Gaia则重点放在Agent系统的设计建模阶段，认为分析MAS系统的需求和分析其它类型系统的需求没有区别，忽略了面向Agent软件工程中非常关键的需求建模阶段的分析研究。通过详细的比较分析，对当前主要面向Agent软件工程方法的特点总结如下：面向Agent软件工程方法根据出发点的不同大致分为两类：一类方法被称为“基于组织”的方法。这类方法从组织的观点出发，以组织概念作为“第一类”实体，将MAS视为一个计算组织。首先根据组织、角色、交互模式等抽象概念，从独立于Agent酌方面分析一个MAS应用的组织构成、组织内的约束规则，角色的任务、责任和约束，角色间交互等。在开发了组织模型规约之后，就可按此开发MAS，引入Agent承担这些抽象的角色。这些Agent按规定的角色模型行动，并相互交互。这类方法包括有一框架、Gaia方法、元模型ALAADDIN方法[32]等。另一类方法可以称为“基于Agent”的方法。这类方法以Agent作为“第一类”实体，将MAS定义为交互Agent的集合。Agent作为自治的实体，独立地、甚至自私地运行，它的行为是精神状态或交互的结果。设计者只关心Agent的个体行为，丽假定组织结构来自于Agent行为的模式，是交互的结果。诸如MESSAGE方法、MAS．CommonKADS方法等都属于这一类。1．3．2面向Agent软件开发环境为了更好的研究智能Agent和多Agent系统，研究人员开发了很多工具软件，帮助设计人员和工程师去建-}r面NAgent的应用系统。这些工具大致分为两类：商用的和研究使用的。商用的包括AgentBuilder[33]、Jack[341等；研究使用的包括ZEUS[35]、Jade[36]、AOSDE[37]等。它们各自提出了自己的Agent构架，用不同的机制构成整个多Agent系统。部分还提供了可视化的编程工具、帮助文档和可复用的软件库以简化开发。下面介绍两种 海大学博十学位论文典型的面向Agent开发环境：1)ZEUSZeus是由英国电信实验室开发的一个MAS框架[381。ZeusMAS框架定义了一种通用的ZeusAgent结构，这种ZeusAgent通常包括了消息处理器、协调引擎、熟人数据库、计划调度器、资源数据库、本体数据库、任务／计划数据库和执行监视器。其中消息处理器用于处理Agent和其它Agent之间的通信；协调引擎用于根据Agent的目标进行行为决策；熟人数据库用于描述该Agent与其它Agent之间的关系，以及关于其它Agent能力的信息；计划调度器用于根据协调引擎所做出的决策来计划Agent的任务；资源数据库用于维护该Agent所具有的或者可获取的资源列表；本体数据库保存了各种事实类型的逻辑定义；任务／计划数据库提供了对Agent所知的计划操作者的逻辑描述；执行监视器则是用于维护Agent的内部时钟，以及开始、停止或监视任务的执行。基于ZeusM．AS的多Agent开发环境包含了一套API、Java代码生成器、Agent监视工具和编程文档[3s1。21JACKIntelligentAgents(简称JACK)[391是AgentOrientedSoftwarePty．Ltd．研制的一个基于组件技术的，开发、运行商业级别的多Agent系统的平台。JACK完整的集成了Java编程语言，它包含了Java开发环境的所有组件，并且提供了特殊的Java扩展以实现对Agent行为的编程。在JACK平台可以有效的开发可扩展的多Agent系统。用户可以在一个集成的开发环境按照系统内置的元模型建立应用的实体模型，并定义他们之间的交互关系，建立模型视图，并进行详细设计实现其内部功能和交互机制，最终生成可运行的应用系统。JACKIntelligentAgents遵循BDI[40]模型，因此它们是具有明确目标并且能够根据目标进行事件处理的自主软件组件。每个Agent都包含了：·对客观世界的信念集合：·Agent将要响应的事件集合；·Agent需要完成的目标集合：·描述如何完成目标的计划集合。JACK工具包包括了用于描述多Agent系统的JackAgentLanguage、JackAgent编译器和用于运行多Agent系统的JackAgent内核。3)AOSDEAOSDE是由中国科学院计算机技术研究所研制的多Agent系统开发工具[371。系统采用Java编写以保证Agent的可移植性和异构环境下的互操作性，并支持Intemet上的基于Agent的分布式计算。AOSDE由四部分组成：Agent通信语言SACLtAgent描述语言ADL，通用Agent模板和Agent服务器。第一，Agent通信语言SACL。基于言语动作理论，SACL定义了AOSDE中Agent之间信息交换的语法和语义规范。为了保证系统的开放性和充分利用现有资源，SACL同 j一海火学博土学位论文KQML标准语言在语法上保持兼容。第二，主体描述语言ADL。ADL通过地址、目标、能力、资源来定义一个Agent。Agent在运行时动态地读入一个Agent描述文件，配置地址和资源，并实现通用Agent模板和功能模块的连接。第三，通用Agent模板。通用Agent模板提供了Agent的一些通用能力，如Agent通信机制，元知识表示，执行模块以及同功能模块的接口等。连接上功能模块的通用Agent模板就构成了一个独立的Agent。第四，Agent服务器。Agent服务器(facilitator)是一类特殊而重要的Agent。它内部维护着一个系统中所有Agent能力、状态和地址信息的数据库。利用这一数据库，它向系统中的其它Agent提供多种必要服务，比如名字服务、查询服务、定购服务和Agent生存期服务等。1．4研究意义和内容面向Agent软件工程作为一个新兴的正在蓬勃发展的研究领域，已经引起了世界上许多著名的软件工程专家的兴趣。在每年的国际性软件工程会议上都有大量的高水平学术论文发表。然而。从网格软件开发的角度考察现有的面向Agent的方法，它们普遍存在以下几点不足：(1)已有的面向Agent软件工程方法主要是针对传统的封闭式系统或者一些专业领域系统(如电信系统)进行系统建模。无法为以整个网格环境为领域背景的分布式系统建立模型。比如Gala方法是以静态的组织背景做为问题分析域，因此它所描述得Agent之间的交互是静态的；而i幸框架则是针对传统的封闭式软件形态提出的需求分析框架。而像MAS—CommonKADS、AUML、MESSAGE这类方法虽然是针对复杂的MAS系统，但是对于基于网格计算的软件形态，仍然缺乏有效的概念抽象机制和直观的模型描述。(2)在需求分析过程中，无法提供精确有效的Agent抽取机制。从需求中提取Agent一直是面向Agent需求分析的一个难点，目前也没有公认的比较有效的Agent抽取方法。(3)虽然采用Agent抽象机制建立系统需求模型，但在设计和实现过程中，大多数面向Agent方法仍然采用面向对象方法，因此在两种不同的抽象机制之间不可避免地存在鸿沟，这使得模型在逐步精化的过程中偏离系统需求。(4)无法对基于网格的Interact环境中软件Agent移动属性和共享等属性进行建模。以上原因导致了现有面向Agent软件工程方法难以在网格软件的开发过程中对系统复杂性进行有效的控制和管理。因此研究基于网格计算的软件体系结构模型及其性质，建立适合网格计算环境的面向Agent软件分析和设计建模方法有重要的理论意义和实用价值。基于对现有网格技术和主要面向Agent软件工程方法的分析和研究，我们选择基于0 上海大学博士学位论文0GSA开放式网格体系结构的Interact做为建模对象(网格软件)的应用背景(或称运行平台)，部分汲取it框架在早期需求获取和UML在系统接述方面的优势，依照面向Agent软件工程的要求，提出以Agent概念作为主要分析对象的分析策略，实现一个能够有效描述基于网格Intemet的新型分布式系统模型的工程方法，AOMG(Agent-OrientedModelingbasedonGrid)软件建模方法。整个研究工作按照“建模方法：概念+建模框架和模型+模型语义+支撑工具+工程实践”的思路进行：做为建立网格软件系统建模方法的前提，首先应该对架构在基于网格计算的Internet之上的软件体系结构进行定义和描述。AOMG从Agent抽象角度出发，明确了基于OGSA的多Agent软件系统结构。AOMG方法在传统Agent定义的基础上，结合网格软件形态的一些特征和OGSA结构的以服务为核心的基本思想，对Agent概念重新定义，并引入虚拟组织、开放式组织、网格Agent(GridAgent)和Agent服务等新的抽象概念，为网格软件的分析和设计建模提供概念抽象机制；AOMG建模方法涵盖了面向Agent需求分析建模和面向Agent设计建模。在众多面向Agent需求建模方法中，一框架是一种相对较为成熟的纯面向Agent早期需求获取方法，它通过对组织背景中不同行为角色之间交互关系的准确直观的图形描述来获得对系统风险承担者(Stakeholders)的兴趣、意图的理解，从而帮助软件开发者理解系统角色的动机和基本原理(既“Why”)。目前，i·方法已经成为其他许多软件工程方法在设计前期获取、分析用户需求的手段。然而依据网格软件建模的需求，当前i·框架在抽象概念和建模元模型方面都有明显不足。因此，在AOMG需求分析建模过程中，我们在借鉴i+需求获取策略和策略模型的部分元模型基础上，加入了和网格计算环境相关的一些概念元模型，同时增加了对系统内部角色与网格环境之间交互关系的描述，从而形成适合开放式网格应用需求获取的组织模型和角色模型。建立网格应用的组织背景模型只是AOMG需求分析建模的前奏，抽象出软件系统中的各类Agent并建立它们之间的交互关系是面向Agent需求分析的最终目的，AOMG方法在组织模型基础上提供了一种有效的Agent抽取手段来建立系统的Agent交互视图。在设计建模阶段，AOMG方法主要解决Agent的细化和分解问题，从而获得可以采用传统的面向对象编程技术进行实现的设计模型。我们的思路建立一种介于Agent抽象层次和对象抽象层次之间的中间模型，这种模型既可以从需求阶段所建立的Agent抽象模型中轻松映射得到，也可以很容易地分解成对象层次上的类模型。同时在设计阶段，还要针对网格环境下Agent的社会性、移动性以及服务共享属性对其进行建模。在AOMG分析与设计建模过程中，包括象Agent抽取、中间模型的建立等过程，其实都是一个模型变换过程，AOMG方法在这些过程中都提出了基于元模型层次的模型映射规则。任何一种系统化的软件建模方法，都不能缺少对其基本模型的语义定义，AOMG方法 上海大学博士学位论文通过扩充现有的Object．Z语言框架，实现了对所有概念和元模型的语法和语义描述，配台相应的基于形式化语义的模型映射规则，形成了一套独立的面向Agent形式化建模框架，FormalAOMG框架。做为一种专门针对网格平台上的软件建模技术，网格服务的查找技术是需要解决的一个关键问题。为此，AOMG方法采用了基于资源本体的服务匹配方法来解决网格软件之间进行服务匹配的问题。而在资源本体的构造过程中，我们提出了一种基于扩展UML类图的本体模型，同时还解决了从UML模型到面向机器的OWL本体的快速构造问题。任何建模思想的体现以及实际模型的建立都离不开相应的建模支撑工具，为此，我们开发了基于AOMG方法的建模工具——AOMGToolldts。该工具实现了模型可视化编辑，并解决了建模过程中的模型语法验证和模型之间的一致性检查等问题。为了演示AOMG方法，特别是建立系统模型的主要过程，本论文给出两个具体分析实例：在线商品订购系统和电子政务网格门户系统。其中在线商品订购系统用于介绍AOMG方法的各种模型定义。电子政务网格门户系统用于完整阐述AOMG方法和建模环境所支持的网格软件建模过程。1．5论文组织结构本论文各章节的详细设置情况如下：论文第二章讨论了AOMG建模方法的重要组成部分：AOMG可视化建模框架。首先讨论了与AOMG建模框架相关的研究工作和技术，包括0GSA网格体系结构、i+策略建模技术和UML建模语言。然后重点讨论构成AOMG建模框架的基本概念、分析与设计模型。中间还穿插介绍了基于元模型层次的模型映射规则。论文第三章讨论了AOMG建模方法的核心内容：FormalAOMG形式化框架。包括对AOMG方法中四种核心模型的形式化定义，以及基于形式化语义的模型映射规则，并通过一个系统实例验证了AOMG形式化框架对网格软件系统进行建模的实用性和有效性。论文第四章讨论了基于扩展UML的网格资源本体建模。论文第五章介绍了AOMGToolkits建模环境的体系结构和设计模式，详述基本AOMG元模型的表示、描述方法、模型存储机制，以及如何设计多种类型的模型框图展示系统原型：论文第六章分别介绍了AOMG模型语法检查机制。论文第七章从工程实践的需求应用出发，通过一个电子政务网格门户系统完整地阐述了有关运用AOMG方法和AOMGToolkits环境建立系统模型的过程。论文第八章评价和总结了论文的工作，并提出一些有待于进一步研究的问题。 E海大学博士学位论文第二章AOMG：一种基于网格计算的面向Agent建模方法为了满足面向Agent软件工程描述基于网格的分布式软件的要求，我们结合网格软件的特点，利用组织学观点【41]和Agent抽象机制，提出一种新的面向Agent软件分析与设计建模方法--AOMG方法[421。本章围绕AOMG方法的基本建模理论，首先定义了基于OGSA的软件体系结构，然后重点介绍面向Agent需求获取、软件Agent的提取以及AOMG分析和设计过程中的一些主要的元模型概念，此外还将介绍我们提出的基于元模型映射的模型变换方法。2．1与AOMG相关的研究与技术本节讨论和AOMG建模方法相关的一些研究背景和建模技术。包括AOMG方法的应用背景——OGSA网格体系结构，以及i·框架技术和U'ML建模语言。2．1_1OGSA网格体系结构相比其它网格体系结构，OGSA是目前最新也最有影响力的一种网格体系结构。因此，在AOMG方法中，我们选用OGSA结构做为所建模软件的应用背景(运行平台)，并提出了基于OGSA的软件体系结构。GGF(GlobalGridForum，全球网格论坛)于2002年6月公布了开放网格架构。这是一组基于现有开放标准的技术规格和标准，旨在为世界各地的网格提供一个公共的技术基础。OGSA以服务为中心，它的服务概念很广，包括各种计算资源、存储资源、网络、程序、数据库等。简而言之，一切都是服务。OGSA符合标准的Web服务框架。Web服务解决了发现和激发永久服务的问题，但在网格系统中，大量的是临时服务，因此OGSA对Web服务进行了扩展，提出了网格服务(GridService)的概念，使得它可以支持临时服务，并且能够动态创建和删除。开放网格服务基础(OpenGridServiceInfrastructure，OGSI)[43]是OGSA关于网格概念的正式规范。OGSI规定了一组服务要素。用于定义对所有网格服务都通用的核心行为。2．I．1．1OGSA架构OGSA有四个主要层次：物理与逻辑资源、Web服务与定义网格服务的OGSI扩展、基于OGSA架构的服务，以及网格应用程序。其具体层次结构如图2．1所示。(1)物理和逻辑资源层，资源的概念是OGSA以及通常意义上的网格计算的中心部分。构成网格能力的资源并不仅限于处理器。物理资源包括服务器、存储器和网络。物理资源之上是逻辑资源。它们通过虚拟化和聚合物理层的资源来提供额外的功能。通用的中间件，比如文件系统、数据库管理员、目录和工作流管理人员，在物理网格之上提供这些抽象服 上海大学博士学位论文务。(2)Web服务层，OGSA架构中的第二层是Web服务。这里有一条重要的OGSA原则：所有网格资源(逻辑的与物理的)都被建模为服务。OGSI规范定义了网格服务并建立在标准Web服务技术之上。OGSI利用诸如XML与Web服务描述语言(WebServicesDescriptionLanguage，WSDL)[441这样的Web服务机制，为所有网格资源指定标准的接13、行为与交互。OGSI进一步扩展了Web服务的定义，提供了动态的、有状态的和可管理的Web服务的能力，这在对网格资源进行建模时都是必需的。本文稍后将讨论这些扩展。(3)基于OGSA架构的网格服务层，Web服务层及其OGSI扩展为下一层提供了基础设施：基于架构的网格服务。GGF目前正在致力于在诸如程序执行、数据服务和核心服务等领域中定义基于网格架构的服务。随着这些新架构的服务开始出现，OGSA将变成更加有用的面向服务的架构(SOA)。(4)网格应用程序层，随着时间的推移，一组丰富的基于网格架构的服务不断被开发出来，使用一个或多个基于网格架构的服务的新网格应用程序亦将出现。这些应用程序构成了OGSA架构的第四个主要的层。图2．1开放式网格服务(OGSA)架构图2．1．1．2网格服务网格服务属于一种特殊的WebService，该服务提供了一组接13，这些接13的定义明确并且遵守特定的惯例，解决服务发现、动态服务创建、生命周期管理、通知等问题。在OGSA中，将一切都看作是网格服务，因此网格就是可扩展的网格服务的集合，即网格=f网格服务}。网格服务可以以不同的方式聚集起来满足虚拟组织的需要，虚拟组织自身也可以部分地根据他们操作和共享的服务定义。网格服务通过定义接13来完成不同的功能，服务数据是关于网格服务实例的信息，因此网格服务可以简单地表示为“网格服务=接121，行为+服务数据”。图2．2是对网格服务的简单描述。其中只有GridService接13是必需的，而其它的接口都是可选的。网格服务是由他们提供的能力来刻画的。一个网格服务实现一个或多个接13，每个接口定义了一些操作，这些操作通过交换定义好的一系列消息来激活。网格服务接口和WSDL的portTypes相对应网格服务提供portTypes的集合。而包括一些与版本有关的附加信息，在网格服务中用4 t海大学博七学位论文serviceType来描述，serviceType是OGSA定义的WSDL的扩展元素。详细的OGSA接口描述见参考文献【4]。●——■服务数据的访问GridServiee(必需的1标准接口其它接口(可选)●l一通知一授权图2．2网格服务示意图2．1．1．3OGSA结构的优点一服务创建一服务注册一管理一并发+面向特别应用的接口以网格服务为中心的OGSA体系结构具有如下优点【4]：·由于网格环境中所有的组建都是虚拟的(指对相同接口不同实现的封装)，因此，通过提供一组相对统一的核心接口，所有的网格服务都是基于这些接口实现，就可以很容易地构造出具有层次结构的、更高级别的服务，这些服务可以跨越不同的抽象层次，以一种统一的方式来看待。·虚拟化使得将多个逻辑资源实例映射到相同的物理资源上成为可能，在对服务进行组合时不必考虑具体的实现，可以以低层资源组成为基础，在虚拟组织中进行资源管理。通过网格服务的虚拟化，可以将通用的服务语义和行为，无缝地映射到本地平台的基础设施之上。·OGSA通过定义网格服务的语义，给出了与任何主机环境无关的服务交互方式。OGSA对服务做什么以及该服务该如何执行并不关心，即它并不解决关于如何实现编程模型、编程语言、实现工具、执行环境等问题。正是基于对OGSA以上特点的考虑，我们选择OGSA做为我们研究网格软件建模方法的基础。OGSA对底层透明的特性，使得我们在建立网格软件模型时不必过多地考虑网格技术本身，从而使建模的复杂度得以有效的管理和控制。2．1．2i+策略建模框架当前对需求工程的研究提出了一个新的观点，即把需求工程的活动划分为早期需求分析和后期需求分析两个阶段·早期需求分析阶段主要特点是非形式化的和对组织性和非功能性需求的描述，侧重于描述系统所作用的领域背景信息以及理解系统的动机和基本原理； 上海大学博士学位论文后期需求分析通常是对系统功能进行较精确的形式化描述，形成需求规格，并且对需求规格进行文档化以及完整性、一致性检查[18]。为了提供一种直观的早期需求获取技术，ErieYu提出了著名的面向Agent的需求建模框架Di*框架[17]。i+框架侧重为系统风险承担者(Stakeholders)的兴趣、意图以及系统所作用的背景环境进行分析和建模，因此可以帮助软件开发者理解系统角色的动机和基本原理。具体的建模策略就是通过把各种不同的可选择目标系统做为组织背景中的角色进行分析和推理，从而理解目标系统的动机，即回答在应用领域中为什么需要开发目标系统。对系统动机和原理这些高层次概念的理解程度往往可以决定系统最终是否能够成功。在p框架中，各种不同的风险承担者被抽象为具有意图属性的战略角色(StrategicActor)，而i+就是一个描述不同战略角色之间的意念关系的框架。战略角色是该框架的核心概念。每个战略角色都代有意图属性，如目标、信念、能力和承诺等。框架的研究焦点是从每个角色的视角上分析需求战略上的含义，并且通过探索和判别可选择的操作过程更好地满足该角色的战略利益。为了在这样的一个抽象层次上建模和推理，该方法描述的关系是在意念层次上的关系，而不是通常的输入和输出的数据关系。i-框架为早期需求获取提供了两种模型：策略依赖模型(StrategicDependencyModel，简称SD模型)，和策略原理模型(StrategicRationaleModel，简称sR模型)。策略依赖模型是一种表示组织背景中stakeholder之间彼此依赖关系的模型图。在i·策略模型中，存在依赖关系的两个战略角色分别称作依赖者(Depender)$n被依赖者(Dependee)，二着之间的依赖关系称作依赖体(Dependum)。i·框架在策略依赖模型中定义了四种依赖关系，分别是：目标依赖(GoalDependency)，表示一个战略角色依赖另一个角色来完成某一个目标：资源依赖(ResourceDependenc”，表示一个角色依赖另一个角色为它提供物理资源和信息：任务依赖(TaskDependency)，表示一个角色依赖另一个角色来完成某个任务；和非功能需求有关的软目标依赖(SoftGoalDependency)，类似于目标依赖，但没有精确的定义。这四种依赖关系中的依赖体也被称为是策略依赖模型中的意图元素，也就是角色的意图属性。策略依赖模型提供了一个描述组织背景的抽象层次，展现了组织背景中stakeholder之间的外部关系。然而在早期需求获取阶段，还需要提供对角色意图更详细的表示，并且能够对角色意图进行推理。在i·框架中，策略原理模型可以用于更详细地描述角色内部的意图关系。策略原理模型包含了策略依赖模型中的四种意图元素，这四种意图元素通过两种新的连接关系在角色外部以及内部进行连接。两种新的连接关系分别是：方法一结果关系(Means—EndRelationship，表示并存的实现目标的方法)、任务分解关系(Task．DecompositionRelationship，表示实现某个目标必须完成哪些任务)。做为一种早期需求获取技术，目前这种建模框架已经广泛应用到商业过程建模和软件过程建模，i+策略建模框架具有以下优点：●i+策略建模可以帮助用户明白他们到底需要什么以及他们所需系统能做什么。这对于准确获取系统需求非常关键。 上海火学博士学位论文●通过两种策略模型可以更好地理解应用领域中各种系统风险承担者(Stakeholders)的兴趣、能力等，从而更准确地识别应用领域的各种概念和事实。●统一的早期需求模型描述能够很好地控制需求变更。·组织良好的模型描述语言可以达到不同领域对需求模型的共享。因此，我们在AOMG方法中汲取了它在早期需求过程中的组织建模思想和组织建模过程中的部分元模型，由于i-框架主要是针对封闭式系统进行组织建模，因此要把它用在网格分布式系统这种开放式软件的建模过程中，必须进行改进和扩展。2．1．3UML建模语言UML是面向对象建模领域中通用、统一、图形化的标准建模语言[451。UML所提供的视见元素构件可以设计、表达复杂的面向对象软件的体系结构。UML模型元素的扩展机制支持建立在域分析基础上的模型元素到视见元素的映射关系。I．rML类图做为UML提供的一种最重要的模型，用于描述相同属性和行为的对象。UML类图描述了应用领域中各种对象之间的静态关系以及每个对象内部的静态属性和行为。同时，UML提供形式化语言OCL(ObjectCommitmentLanguage，对象约束语言)并以一阶谓词逻辑辅助模型的描述，但其能准确刻画模型的静态语义。随着UML的不断完善和人们对Agent本质认识的加深，很多研究人员都将UML语言应用到面向Agent领域。比如Odell建议通过扩展UML来支持对Agent的各个方面进行描述和表示，他的建议也成为UML自身发展的一种趋势[20][461；Bergenti和Poggi等人则直接应用UML的四种模型在Agent抽象层次上进行多Agent系统的设计[47】。类似的工作还有[48][49]等以及在1．3．1所介绍的部分面向Agent的方法。可以看到目前UML主要还是被应用在面向Agent的系统设计阶段，建立的模型本质上属于对象层次上的系统模型，这就不可避免地使得这些UML模型和需求分析阶段所建立的Agent层次上的需求模型存在鸿沟。因此我们的建议是建立一种介于Agent抽象层次和对象抽象层次之间的中间模型，这种模型既可以从需求阶段所建立的Agent抽象模型中轻松映射得到，也可以很容易地分解成对象层次上的类模型。在AOMG方法中，我们通过扩展UML类图来建立这种中间模型。2．2基于OGSA的面向Agent可视化建模框架2_2-1基于OGSA的软件体系结构在建立基于OGSA的软件建模框架之前，必须定义OGSA体系结构下的软件框架。图2．3是我们提出的一种基于OGSA体系结构的软件结构。从Agent抽象角度出发，任何建立在OGsA之上的网格软件系统都是一个多Agent系，它由各种不同的Agent、资N(resource) j二海大学博十学位论文组成，Agent之间存在着交互和协作。不同网格应用系统中可以通过内部的资源本体库(resourceontology)i句网格资源管理器发布自己的资源(包括数据资源或者程序资源)。同样，网格应用也可以从资源管理器检索到自己所需要的服务，通过这种机制，使不同网格应用的Agent之问实现资源的共享。另外，网格应用中的部分Agent具有移动能力，为了完成系统目标可以在不同网格节点移动。由于所有的应用都是直接架构在OGSA之上，因此网格应用系统对底层的基础设施完全透明。2．2．2基本概念图2．3基于OGSA的软件体系结构网格基础设施为了准确的建立系统的抽象模型，我们结合网格计算平台的基本特性对分析和设计过程中的一些基本概念进行定义：定义2．1虚拟组织(Hrtua／Organization)，在OGSA中，IanFoster将虚拟组织定义为由一些个体或组织通过特定的共享规则组成的集合[3】，这种共享不仅仅是以文件交换为主，而是对计算机系统、软件、数据以及其他资源的直接访问，从而解决出现在工业、科学、工程上的协作式问题求解、资源代理策略等问题。而在软件建模领域，从组织学观点出发，我们把虚拟组织定义为由开放式组织(见定义2．2)节点和资源管理节点组成的集合，其中开放式组织节点也就是网格软件节点，它属于网格计算环境中的资源节点的一种，而资源管理节点则用于协调网格软{孛之间的服务共享与合作。VO：。_蚵，OOs={00l，002，．．，oQ) E海大学博士学位论文定义2．2㈣qCOp删Organization)，对于任何一个基于网格计算的分布式应用(或称网格软件)，我们可以把它抽象成一个开放式计算组织，这种组织和人类社会的组织相符合，有一组明确的组织目标，组织中包含各种存在交互关系的角色，我们对开放式组织的形式化定义如下：00：：=d“<00—11)，Roles，R—Relations，Goals，Rules>其中00_ID是开放组织的标识，Roles是非空的角色集合，RRelations是角色关系集合，Goals是非空的组织目标集合，Rules是一个组织形成的规则。定义2．3Agent，Agent是具有一定能力的智能实体，在组织中可以承担一个或多个的角色去完成相应的组织目标，在我们的方法中把Agent分为两类：一种是一般Agent，属于系统内部Agent：一种是网格Agent(Grid_Agent)，可以在网格环境中移动，和网格中的资源和其他网格Agent进行交互一+一般Agent的形式化定义如下：Agent：：=耐上D是Agent的标识。Capabilities是Agent的能力集合。Goals表示Agent个体的目标集合。Knowledge是Agent的内部知识库，它和BDIAgent[40]的信念是一致的。定义2．4网格Agent(GridAgenO，网格Agent是我们定义的～种特殊Agent，形式化定义如下：GridAgent：：=“GUID表示该Agent在网格中注册的唯一标识。Services表示该Agent能向网格环境中其他Agent所能提供的网格服务。Mobility表示该网格Agent是否具有可移动性。Adaptability表示网格Agent的自适应能力。定义2．5角色(Role)，角色是描述组织中Agent的一些外部特征，比如它担负哪些职责以及享有哪些权利。一个角色可以由多个Agent来担任，一个Agent也gNN时扮演多个角色。其形式化定义如下：Role：：=d盯其中Responsibilities表示角色承担的职责集合，Permissions是角色享有的行为许可(权利)集合，Collaborators表示角色的合作者，Protocols是角色承担职责需要具备的一些前提条件(必要的社会协议)。定义2．6网格节点(Node)，网格节点是指分布在网格中的资源，这些资源是开放式的，可以被其他的应用使用和访问。其形式化定义如下：Node：：=d盯其中Interface是资源的访问接口，database、gridagent和component表示三种网格节点。database即可以表示是数据库资源节点，也可以是基于html、xml等文件格式的数据资源节点。19 上蹲大学博士学位论文2．2．3模型框架AOMG能够帮助系统分析员通过系统化的分析，把零散的需求说明(RequirementStatement)变成足以用于编程实现的设计模型。在AOMG需求获取和分析建模过程，是一个获取系统抽象模型的过程，而在AOMG设计过程则是一个从抽象概念到具体概念的过程，后续的模型在逐渐向实现靠拢。因此AOMG分析与设计建模是一个建立目标系统模型和逐步细化模型的过程。AOMG中的主要模型如图2．4所示，在AOMG需求获取和分析阶段建立的模型包括组织模型、角色模型和Agent交互模型，设计阶段将完成Agent移动模型、通信模型、网格Agent服务模型、Agent类模型和资源本体模型的建立。图2．4AOMG模型框架2．2．4AOMG元模型的分层结构设计元模型是描述模型的语言。它能对模型的语法和语义提供简单、通用、明确的描述，为AOMG模型元素的语法和语义作出简单、一致的定义性说明，而它本身则是元递归的方式定义的(类似于编译器作自编译的方式来自行扩展)。AOMG元模型的概念框架基于一个四层的体系结构：元元模型(Meta—Metamodel)、元模型(Metamodel)、模型(Model)和实例(Instance)。见表2．1。表2．1AOMG元模型概念框架层次阻evel)描述OOescription)实甥J(Example)元元模型层结构化元素的基本语言如Attribute．Operation，Belief,Capability等元模型层知识层概念如Role。Goal，Task，Dependency等模型层描述应用领域中的风险承担如Customer，Market·OrderSystem等者(stakeholders)实例层领域模型的实例如Cuslomer的实例：小明析分与取获求需、IlIL＼．1l_、 上海大学博士学位论文(1)元元模型层(Meta．Metamodeling)构成了元建模(Metamodeling)体系结构的基础结构。这一层的主要责任是定义描述元模型的语言。它比元模型具有更高的抽象级，而且更加简洁。它为元模型的扩展提供了基础。(2)元模型是元元模型的实例。元模型层的主要责任是定义描述模型的语言，它为定义基于知识层的实体和概念提供基础。元模型比定义自身的元元模型更加精细，尤其是当它们定义动态语言时。(3)模型是元模型的实例。模型层为不同应用领域中的实体和概念提供描述语言。(4)实例层包含了应用领域中各种模型的实例。2．2．5面向Agent分析建模面向Agent分析的目的是理解系统的需求，建立系统抽象模型。复杂的软件往往包含复杂的组织关系。在分析过程中，AOMG方法首先将以角色、组织目标、任务等概念抽象出系统的组织背景模型，并通过对组织中的角色的责任、权利进行分析来建立详细的角色描述模型，最后通过相应的Agent抽取规则抽取出Agent交互模型。本节将通过一个网上订购系统实例阐述AOMG分析和设计建模过程。所有模型都是采用我们自行开发的AOMGToolkits集成建模环境建立的，关于AOMGToolkits的介绍见第五章。实例1：网上订购系统(EOrder)。背景：用户想通过基于网格的Internet进行网上订购，在系统界面输入对商品的一些基本要求，系统将搜索整个基于网格的Internet中条件最匹配的商品，然后显示搜索结果并提供相应的预定界面，用户则在上面完成整个商品预定流程。2．2．5．1组织模型(OrganizationModeOAOMG组织模型(OrganizationModel)是通过扩展和改进i·框架中的策略依赖模型而建立的一种新模型。在i+策略模型中，描述的是系统内部和现实世界中具体行为者'(actor，在i+策略模型中stakeholder表示为actor)之间的彼此依赖关系，它的组织背景局限于传统的封闭式软件分析范畴[171。AOMG方法在以下几个方面对i+策略模型进行了扩展和改进：(1)将系统的组织背景扩展到整个基于网格的Intemet环境。将i+策略模型中的战略角色元模型(StrategicActor)抽象为更具有一般性的角色(Role)元模型。在i+策略模型中，一个战略角色表示的是组织背景中一个具体的stakeholder，而AOMG组织模型中的角色表示的是具有*NN属性的一类stakeholder，因此具有更强的可扩展性。它们之间的关系就像是社会组织中一个具体的“工作人员”和一个“职位”之间的关系。(2)提出了网格节点(Node)和服务依赖关系(ServiceDependency)等新的元模型，从而使21 上海大学博士学位论文其支持对基于网格的分布式系统进行组织建模。(3)网格Agent做为服务依赖者(depender)和被依赖者(dependee)进行建模。(4)在i+框架的策略原理模型中，主要是通过一个方法．结果(Means．End)关系来分析出可能存在其他能够完成目标的方法，从而达到对角色意图的推理。同时采用任务分解(Task-Decomposition)关系来对某个任务进行细化。但这样往往会造成建立的策略模型不断增大，使角色之间的关系变得非常复杂，大大降低了模型的可读性。因此，在AOMG组织模型中，我们弱化了角色意图的推理，因为这个过程完全可以在设计者的大脑里完成，我们所需要呈现给用户或开发人员的只是一个确定的组织背景模型。同样，任务分解也没有出现在AOMG组织模型，我们把任务分解模型做为了组织模型的一个附属模型。经过扩展和改进后的AOMG组织模型包括以下一些基本的元模型：图2．5AOMG组织模型中的元模型表示在AOMG组织模型中，通过类似于网状的“虚拟组织”元模型表示软件系统之外的网格环境，通常一个这样的元模型表示一个予网(比如教育网)；“虚拟组织”元模型中通常包含了若干和目标系统相关的“网格节点”，组织模型中的外部网格资源节点用一个带圈的“N”图形表示；具有一定意图属性的意图角色用一个圆圈表示：服务依赖体(ServiceDependum)用一个五边形表示：其他元模型沿用了i幸策略模型中的表示法。采用以上元模型，AOMG组织模型从两个方面对基于网格应用系统进行描述：(1)描述组织背景中角色之间彼此依赖关系，既包括系统内部角色之间的关系，也包括系统内部角色与领域背景中的用户、stakeholders、资源之间的依赖关系。(2)描述组织内部的角色和外部网格环境之间(资源节点)的交互关系。在实例1的需求获取阶段中，通过对系统stakeholders意图进行分析，抽取出系统中的五个主要角色：Customer(客户)、InternetOrder([网上预定处理角色)、ProductSeeker(商品搜索角色)，Coordinator(协调者)和Financial(网上支付处理角色)。这五个角色之间存在相互依赖关系：如Customer依赖InternetOrder来完成商品搜索和商品预定两个任务(任务依赖)，并希望在进行预定的时候保证客户信息的安全性(软目标依赖)；InternetOrder依赖ProductSeeker来达到搜索最佳商品的目标(目标依赖)：InternetOrder还需依赖Financi口f来帮助客 E海大学博士学位论文户完成网上支付：ProductSeeker从本地数据库查询商品(资源依赖)；ProductSeeker依赖Coordinator来协调网格服务的访问以及Agent的移动，Coordinator则是通过在网格中查询服务接口从而获得Agent的服务地址(通常是通过资源管理获得服务位置)，同时确定ProductSeeker是否需要移动来访问该服务，一般情况下如果不需要和外部网格节点之间发生大量的数据通信，ProductSeeker则可以直接访问Coordinator查询到的服务接口，如果存在大量的通信ProductSeeker则可以根据Coordinator提供的服务地址移动到目标节点进行查询，再把结果发回来，这样就可以减少网络上传输的数据量。做为网格分布式应用，系统内角色和网格环境中注册的节点之间(LL立N其他连锁店的订购系统)也可能存在依赖关系，如ProductSeeker角色在本地数据库中查询不到合适的商品时可以请求网格环境中相应的节点提供商品搜索服务(服务依赖)，同样ProductSeeker可以向其他网格节点提供相同的服务，因此服务依赖是对等的。由以上五个角色以及它们之间存在的依赖关系，形成了整个系统的组织背景，见图2．6。图2．6实例1系统组织模型2．2．5．2角色模型(RoleModel)组织模型主要描述角色之间的交互关系，接下来需要对组织中的一些主要角色进行更23 l海大学博士学位论文详细的描述。为完成组织的目标，组织中的每种角色都关联了特定的责任和权利等属性。·角色的责任职B甲D月s渤fff协)，在组织模型中，每个角色都是为了完成某件事而建立的，也就是说每个角色都承担了某些特定的责任。我们把这些特定的责任定义为该角色的“责任”属性。·角色的许可(Permissions)，组织模型中的每个角色为了履行它承担的责任，都具备了一些权利，我们把这些权利定义为该角色的“行为许可”。·角色的协议(Protoc01)，角色为了完成它的职责必需具备一些前提条件，或者说必要的能力。我们把这些前提条件定义为角色的协议。通过分析组织中各种角色的责任、权利以及承担职责所需要的一些前提条件(社会协议)，综合起来就形成了角色模型。图2．7是AOMG定义的角色模板。RoleSchema：R0lenalYleDescriptionAwrittendescriptionofthisrole’Scharacteristics，abilities，responsibifitiesere．ResponsibilitiesslloftE1191ishdescriptionoftherole’S∞∞onsibilities．Permissions‘'ri曲ts”associatedwiththerole．Collaborator=’DependerRoletDependeeRoleProtocolTheabilitiesnecessarytofulfilitsresponsibilities图2．7角色模型模板图2．8是我们为实例中ProductSeeker角色建立的角色模型，在AOMG建模环境中，角色模型可以在每个角色元模型的属性页中设置，见图7．4。RoleSchema：ProductSeekerDescriptionThisrolelnvolesqueryinglocalproductsdatabase，reauestingexternal2'ridserviceforproductswhlieneedResponsibilitiesSearchoptimalproductsforcustomerPermissions【1]queryproductsdatabase[2]migration[3]queryexternaldatabase【4]requestexternalgridagentl"orseekingproductsCollaborator=，Coordinator．eInternetOrderProtoeolArithmetic如rselectoptimalproducts图2．8实例1中ProductSeeker角色模型通过图2．8的角色模型可以看出，角色ProductSeeker的主要职责就是搜索最符合客户要求的商品。为了完成搜索商品这个职责，ProductSeeker具有查询本地数据库、查询网格环境中的数据库资源、移动以及和其他网格Agent进行通信的“权利”。为了达到搜索最佳商品，ProductSeeker还配备了查找最佳商品的搜索算法。在组织模型中和ProductSeeker关联的角色有两个：Coordinator(被依赖角色)和InternetOrder(依赖角色)。2．2．5．3Agent交互模型(AgentInteractionModel)Agent的抽取一直是面向Agent软件工程领域关注的～个问题。AOMG方法在早期需 上海人学博士学位论文求分析阶段借鉴了i+建模框架，很注重角色的意图建模，其中的角色和Agent概念具有很强的一致性，因此很易于Agent的抽取。为了方便从组织模型中抽取出Agent，我们提出了基于元模型层次的Agent抽取规则，抽取原则是判断组织模型中的角色能否变换成Agenta在抽取出Agent的同时，组织模型中角色的意图属性转换成Agent的基本属性，如角色的责任转换成Agent的目标，角色的权利转换成Agent的能力，而角色的社会协议转换成Agent的信念。Agent交互模型中的Agent与AgentBDI模型是一致的。具体抽取规则如下：规则1：组织模型中的角色(RDle)如果和其他角色存在目标依赖关系(GoalDependency)、任务依赖关系(TaskDependency)或者软目标依赖关系(SoflgoalDependency)，并且该角色属于被依赖者(dependee)，则该角色可以抽取为Agent。规则2：组织模型中的角色如果和其他角色存在服务依赖关系(ServiceDependency)，并且该角色属于被依赖者(dependee)，则该角色可以抽取为网格Agent。规91II3：组织模型中的角色的责任(Responsibilities)映射为该角色映射得到的Agent的目标(Goal)。规则4：组织模型中的角色的权利fPermissions)映射为该角色映射得到的Agent的能力(Capabilities)。规则5：组织模型中的角色的社会协议(Protocols)映射为该角色映射得到的Agent的内部知识库(Knowledge)。利用以上的Agent抽取规则，实例l可以抽取出InternetOrder、Financial、ProductSeeker和Coordinator四个Agem(其中ProductSeeker是网格Agent)。并且为四个Agent建立目标、内部知识库和能力等Agent属性，四个Agent之间的交互构成Agent交互模型，见图2．9。皇广—丽丽丽而丙丽一I+GOAL：process—producLorderl+KNOWLEDOE：ordeLworⅫOWl+CAPABILITY：requesLproducLinfo|+CAPABILITY：display_search—reeu—ProductSeekerAgent+GOAL：seek_optimal—producl+KNOWLEDOE：producl_matchrule+KNOWLEDGE：search．ar№me啦c+CAPABILITY：query_local—database+CAPABILITY：migration+CAPABILITY：query_grid—resource+CAPABILITY：communication^—————一+GOAL：process—payment|+KNOWLEDGE：secudto_strategyOil>endemyl+C．,NoABILITY：validate—credit—cardI+CAPABILITY：finish—paymentACoordinatorAgentI+GOAL：coordinate—requesting—grid—service：I+KNOWLEDGE：arithmeUc—decisionmeldncOmpendenovl+CAPABILITY：query_grld—service————、—一+CAPABILITY：get_resource—node—addressI+图2．9实例1Agent交互模型 上海大学博士学位论文2．2．5．4分析建模过程AOMG分析建模过程可以归纳如下：(1)从分析软件风险承担者(stakeholders)的意图出发，将组织背景中各种stakeholder(包括目标系统1抽象为不同的意图角色，然后建立它们之间的战略依赖关系，从而获得网格分布式系统的组织模型。f21分析组织模型中角色的责任、权利以及角色之间的关联关系，建立角色模型。(31从组织模型和角色模型中抽取出系统中的Agent，并建立Agent交互模型。这个过程可以直接利用我们提出的Agent提取规则。2。2．6面向Agent设计建模面向Agent设计的目的是将分析阶段的抽象模型变换成抽象级足够低、易于实现的模型，使得传统设计技术(如面向对象技术)可用来实现系统。前面的分析阶段我们已经抽取出系统中的Agent以及它们的一些高级属性和行为。在设计阶段则需要定义每个Agent的底层功能，以执行高层次的动作。还要把Agent层次(或Role层次)的交互转变成特定的交互协议。在本文我们通过Agent类模型对Agent进行细化。作为基于网格环境的分布式应用的分析和设计方法，还必须解决网格软件系统的共享和互操作等问题，这些特点将体现在Agent的设计中，包括：(1)Agent支持携带明确语义信息的消息的传递和理解；(2)支持Agent在网格环境中的自主移动；(3)Agent应用不是孤立存在的，Agent之间可以互相提供标准的服务接口，从而达到资源和服务的共享；(4)支持网格Agent在网格环境中查找匹配资源。为此AOMG建模框架提供了Agent通信模型、Agent移动模型和Agent服务模型对网格环境中的Agent进行设计。在AOMG分析过程我们注重的是Agent之间的交互关系和Agent的一些高级属性。在设计过程中，我们更注重Agent的内部建模，即对Agent进行细化。在面向Agent的软件设计过程，如何将需求分析阶段抽取出的Agent分解为对象层次的对象一直都是研究人员关注的问题，目前也缺少一种直接和比较精确的分解方法。在AOMG方法中，我们试图建立--900介于Agent抽象层次和对象抽象层次的中间模型，这种模型既可以从需求阶段所建立的Agent抽象模型中轻松映射得到，也可以较容易地分解成对象层次上的类模型。为此，我们提出了基于扩展UML的Agent类模型。在Agent类模型中，Agent的一些高级特性和行为将分解为类似于对象层次上的属性和方法。Agent类模型扩展了UML类模型中的部分元模型和元元模型，表2．2是部分扩展后的元模型和元元模型，扩展的原则是通过对类及其属性和操作进行范型(stereotype)约束来表示不同类型的Agent和Agent属性。例如stereotype为<>的类表示该类描述的26 上海大学博士学位论文是一个网格Agent类，Agent类中stereotype为<勺印口6m妒》的操作表示该类的能力aUML类图元模型／扩展后的Agent类图元模型，元元模型元元模型名称stereotype类型描述Class空表示普通的对象实体类ClassAgentClass“agent>>表示Agent类ClassGridAgentClass<>表示网格Agent类ClassResoufceClass<>表示资源实体类OperationCapabilityOperation<>表示Agent的能力0nerationServiceOperation·c表示网格Agent能提供的服务AttributeGoalAttdbute<>Boolean表示Agent的目标是否实现AttributeSoftGoalAttribute<>Enumerated表示Agent软目标的实现程度Agent类图的最大特点就是易于从Agent抽象模型影射得到。在AOMG设计过程中，开发人员通过对需求分析过程中建立的组织模型、角色模型和Agent交互模型进行分析，并且借助AOMG提供的模型映射规则[50]，可以很容易获得系统的Agent类模型。需要说明的是由于在分析过程中，角色模型和Agent交互模型都是来源于组织模型，因此初始的映射源模型是组织模型。具体的模型映射规则见表2．3。AOMG元梗到兀7嚯型Agent类图元模型R1组织模型中的角色(gole)，如果和其他角色存在目AgentClass标依赖关系(GoatDel∞ndeney)，并且该角色属于被依赖者(dependen)·R2组织模型中的角色(Role)，如果和其他角色存在任AgentClass务依赖关系(TaskDependency)，并且该角色属于被依赖者(dependee)·R3组织模型中的角色(Role)．如果和其他角色存在软Agent．Class目标依赖关系(SoRgoalDependency)．并且该角色属于被依赖者(dependee)-R4组织模型中的角色(Role)，如果和其他角色存在服GridAgentClass务依赖关系(ServiceDependency)，并且该角色属于被依赖者(dependee)。R5角色之间的任务依赖体(TaskDependum)被依赖角色映射所得Agent类的CapabilityOperationR6角色之间的目标依赖体(goaldependum)被依赖角色映射所得Agent类的GoalAttributeR7角色之间的软目标依赖体(sottgoaldependum)被依赖角色映射所得Agent类的SoftGoalAttributeR8角色间的资源依赖体(resourcedependum)依赖角色映射所得Agent类的CapabilityOperationR9角色问的服务依赖体(servicedependum)被依赖角色映射所得Agent类的ServiceOperationR10角色之间的依赖关系(dependency)依赖关系两端角色映射所得Agent类之问的依赖关联关系借助以上的映射规则，我们可以从图2．6的组织模型映射得到图2．10的Agent类模型。 h海大学博士学位论文{<&gent}’‘《Gdd向em>'Produ吐S●ekerInte[rlet0rder+mob溉Y{t—口em"+《《fO竹aO圳>’security：备+product_13ame。deipendenoyCoord{nator+iJSer-nalTleenpendenc!+pnce+pmdu啦_name4-‘‘。oal’’gn-。ptimalj>roduct一一》+pr；ce4-resultj)mdu眦5+interfBoes+OOUnt：+quew_ser口ice0++<>Piques"[』dservioe0+<>seamh_product0+<>#eek_product0：g．e．rom。6“。·。44。’5‘。：i我们用一个三元组表示网格Agent的移动背景，其中WKNode是一个对所有节点都透明的节点，它记录了所有网格节点最近的访问地址。SNode．是--个包含所有能够提供Agent虚拟机(网格Agent的运行环境)的节点集合，其成员既可能是资源节点(见定义2．8)，也可能是Agent节点。Ncom表示节点之间的通信协议，比如现在比较主流的Globus网格协议。定义2．g资源节点(ResoumeNo如RN)lljAgent节点(AgentNode,AN)RN／AN=用一个四元组表示移P)JAgent的宿主节点，其中ServiceType表示该节点所提供的服务类型，如果ServiceType为’'Database”表示该节点可提供数据资源访问服务，该节点我们称之为资源节点(RⅣ)。如果为”GridAgent'’则表示该节点能提供网格Agent服务，即能够请求该节点的网格Agent完成某个任务，该节点我们称之为AgeIlt节点似Ⅳ)；服务爿聊j是一个Agent虚拟机集合：ACom是Agent虚拟机之间的通信协议； 上海大学博士学位论文定义2．9Agent虚拟机(AgentVirtualMachine,AVlVOAVM=Agent虚拟机是每个节点提供的网格Agent的运行环境，尉是虚拟机中的通信服务器(FacilitatorAgent)，它记录了运行在该虚拟机上的移动Agent一些基本信息，比如Agent的名称、能力、状态等信心；MAs是表示一个移动Agent集合，MCom表示移动Agent$口静态Agent的通信协议，比如基于FIPAACL的通信方式；NodeIP表示该Agent虚拟机所运行节点的口地址；上D表示该虚拟机在网格计算环境中的唯一标识。定义2．10静态Agent(StaticAgent,SA)和移动Agent(MobileAgent,MA)SA／MA=Agent用一个三元组表示，HomelP是一个Agent源节点的P地址，即在该节点建立的Agent；CurlP表示Agent所运行虚拟机的宿主节点的口地址；AON表示Agent实体，它是我们在2．2．2所定义的Agent实例。任何时候如果HemB，P等于CurlP，则该Agent为静态Agent。反之，我们称之为移动Agent。Agent移动模型描述的是网格Agent为了完成某个任务如何在网格环境中进行移动。同时描述了网格Agent在移动过程中目标地点的选择机制，因此网格Agent在网格环境中并不是漫无目的的移动。B囤FacilitatorAgent⑨GridAgent‘。q““⋯．．卜M0bilePath圜lAgentNodeI：墨型IIResourceNode图2．12实例1中ProductSeekerAgent移动模型图2．12是实例l中网格Agent(ProductSeeker)的移动模型。图中的每一个垂直单元代表一个网格节点(可以是资源节点或者网格Agent节点)。ProductSeekerAgent最初在本地数据库进行商品查询。如果没有查询到最优结果，ProductSeekerl甸CoordinatorAgent发网格服务请求，CoordinatorJl砬过查询网格资源服务器来获得服务接口，同时根据不同接口来判定是直接访问服务接口还是需要移动到该服务节点进行相应的服务调用，因此Coordinator具备7"N务查询和充当通信服务器(facilitator)的功能。我们为ProductSeeker提供了移动算法，该算法具有～定的普遍性，适用于大多数网格Agent的移动，算法如表2．4。 I=海大学博士学位论文表2．4实例1ProductSeekerAgent移动算法1alobalcoordinator，product_seeker，service，result，flag；2盥婴美出发agenLmigrata(task)3result=nil；，‘初始化查询结果吖4service=coordinator．queryGridServices(task)：rcoordinator从资源服务器查询法务吖5／*coordinator根据得到的服务判断对其进行访问是否需要移动．『6flag=coordinator．getMigrationStatus(service)；7if(flag)P如果需要移动吖8丛逝9竣擅缝《serviceI=nil)do10beoin11product_seeker．migrate(service．address)；，’移动到服务节点’，12￡县殴垡service．type13。database”：14IDatabase=service．retumInterface0；15result=add(result，perform(query．IDatabase))；16‘'grid_agent'：17IGrid_Agent=service．retumInterface0；18result=add(result．pe60mn(seek．IGrid_Agent))；19曼ndcase20service=coordinator．queryGridServices(task)；21．e．．．．n—d—22end23returnresult；丝篁叵盥篮幽2．2．6．4Agent服务模型(AgentServiceModel)为了实现网格环境中网格Agent之间服务的共享，使网格Agent可以检索到所需的服务，网格Agent必须提供规范的服务接口来接受服务请求者的查询服务。建立Agent服务模型的目的就是标识系统中网格Agent关联的服务以及这些服务的属性。我们可以把“服务”看成是Agent的一个“函数”，可以被其他网格Agent调用。每一个“服务”都可以被Agent执行，因此有必要定义“服务”的一些属性。在AOMG服务模型中，我们还定义了一个网格服务被“执行”的过程，执行过程通过“输入”、“输出”、“前置条件”和“后置条件”四个属性来定义，这四个属性通常是采用基于一阶谓词逻辑的OCL进行描述。图2．13是AGridServiceSchema：ServicepaineDescdpfionAwrittendescriptionofthefunctionsofthisgridservice．H叠ndleURLIntedacesInterfacesthe鲥dserviceprovidIngfuracessing．PerformServiceInputTasks(parameter)OutputTheresultofperformingorthestatusofbeingperformedPre．conditionsconstraintsPost-conditionsconstraints图2．13Agent服务模型模板 上海大学博士学位论文在需求分析过程中，我们通过Agent交互模型可以识别出实例1系统中包含的所有Agent，其中的ProductSeeker是属于网格Agent，因此需要为ProductSeekerAgent建立服务模型。如图2．14。GridServiee：SeekProductDescriptionProvideproduct-seekingserviceforexternalagentHandle^印：／／127．0．0l／EOrder／ogsa／service$／base／registry／ProductSeekerFactoryServicesInterfaeesIReg括try,1GridServicePerformServieeInputSeek(name(。'computer’)，priceC10000。1，brandI。lenov”11Outr，utoptimalproductlistPre-conditionsInput奔ilandisvalid(name(‘'computer’，，priceC10000’，，brand{“lenovo”))Post-conditionsproductlist衲ilormsg(‘"noproducts’，图2．14实例l中ProductSeekerAgent服务模型2．2．6．5设计建模过程AOMG设计建模过程可以归纳如下：(1)对Agent进行分解和细化，建立Agent类模型。这个过程可以借助相应的元模型映射规则。(2)针对Agent的互操作性和共享等特性，分别建立通信模型、移动模型和服务模型。2。3小结本章以电子商务系统为例介绍了AOMG可视化建模框架。和传统的面向Agent方法比较，AOMG主要有如下特点：(1)在传统Agent定义的基础上，结合网格软件形态的一些特征和OGSA结构的以服务为核心的基本思想，对Agent概念重新定义，并引入虚拟组织、开放式组织、网格Agent和Agent服务等新的抽象概念。为基于网格计算环境的软件系统的分析和设计建模提供了概念机制，降低了系统分析和设计的复杂性。(2)在分析和设计过程中，提供了基于元模型层次的模型映射机制，实现了Agent的快速有效抽取，以及从分析模型到设计模型的平滑过渡。(3)AOMG设计建模过程中最后形成的Agent类模型易于采用传统的编程方法实现。因此能够很好地驱动系统的详细设计和实现。(4)在设计建模过程中，充分考虑了基于网格计算背景下Agent的移动性、互操作性和共享性。(5)AOMG建模方法同样适用于传统的基于Interact的分布式应用。 上海大学博士学位论文第三章FormalAOMG：基于网格计算的面向Agent形式化建模框架3．1面向Agent形式化方法可视化建模语言在软件开发过程中有着非常重要的作用，它为软件开发过程中不同的风险承担者提供一个有效的通信框架，比如通过UseCase模型讨论系统开发中的用户需求[52]。然而，可视化建模语言缺乏对模型语言的精确定义，尤其是不能为模型提供有效的推理机制，因此可能导致建立太多主观模型，而无法驱动系统的详细设计。此外，在使用可视化语言建立概念模型时，常常碰到这样的问题：“何时能停止精化模型?”[53]。形式规格语言很好地解决了可视化建模语言的这些缺点，首先形式规格语言允许为模型定义精确的语义，有利于模型之间的转换；其次，基于形式化的模型表示，为模型的完备性和一致性检查提供了语义基础。应用于Agent领域的形式化理论非常多，如模态逻辑[54]、Ⅱ演算[55】等广泛应用到Agent数学模型的研究，但这些形式理论不能为软件系统的规格说明提供指导性的方法学。另～种面向Agent的形式化理论则结合了传统的形式化软件工程方法，比如Luck和d’Invero提出的基于z语言的形式化Agent框架[561,A．Pemi在Tropos方法基础上提出的FormalTropos框架[53]：VincentHilaire[57]等人提出的结合Object-z[58]和状态图[59]的多Agent原型化方法，该方法侧重于对系统进行简单的模拟和原型描述，难以应用到实际的复杂系统开发中：类似的研究还有HaipingXu[60]基于Petri网提出的Agent设计模型。以上的形式化方法基于的Agent建模理论都不是建立在网格计算环境之上，因此有必要以网格环境为应用背景对面向Agent的形式化建模方法进一步研究。在本章中，我们在AOMG建模方法基础上，基于Object-Z语言，提出了一种形式化建模框架—一FonnalAOMG[61]。作为面向Agent软件建模方法的一部分，FormalAOMG可以满足以下几点需要：(1)FormalAOMG通过一种可读性较好和易于理解的方式为建模方法中的基本概念和术语提供精确无二义性的定义。(2)可以为系统中一些需要精确描述、比较和评价的模型提供一种备选的模型语言，即采用FocalAOMG可以为网格应用建立完全基于形式化描述的系统规格说明。(3)可以为日后开发新的或者日益精化的模型提供良构基础，同时还能为模型之间的转换以及开发可视化建模工具提供形式化基础。3．2Object-Z形式规格语言在众多的形式规格语言中，Object．z[58]是一种定义良好的面向对象形式化规格说明语33 上海大学博士学位论文言，它不仅支持类、对象、实体等一些面向对象的基本概念，而且支持继承、对象引用、多态等这些对象的基本属性。这使得Objcct-Z能够提供更强的模块化能力并支持规格说明的重用。在Object—z语言中，一个基本的类封装了状态变量(或称属性)、变量约束、变量初始值约束和可能影响这些变量的所有操作，其中属性和操作的描述都是基于集合理论和一阶谓词逻辑。随着对Object．Z研究的不断加深，针对Object．Z推理的研究也有了很大的进展，包括形式化推理规则【62]的建立和推理工具[6311拘开发，其中推理工具支持模型检查和公理证明等[64】[65】[66]。图3．1是采用UML描述的Object．z的元模型结构。OZType是最高层次的元类，Object．z中所有的类型都是继承OZType得到。Classes也是类型的一种，因此它也继承了OZType。其它的一些类型(比如笛卡尔类型、schema类型)被抽象为一个名为OtherTypes的元类。图3．1Object．Z元模型组织结构类：在Object．z中，类是用来对系统规格化说明的主要建模结构，一个类就是一个具有相同行为对象集合的模版。一个类有一个属性集合和一个操作集合：每个类有名称(name)，类型(type)，可视性(visibility)以及一些特性：每个操作有名称，可视性和一个参数集合(每个参数包含名称和类型)。继承性和实例化：Object-Z@的类可以通过继承来定义其它的类。一个类也可以继承多个类(多重继承)。一个类的实例可以做为其他类的属性。而其中属性的类型也可以是某一个类，在这种情况下，属性的值就是对该属性类对象的一个引用(reference)。在Object．z中，实例化作为建立对象间关系的一种机制，而在UML中这种关系做为一种独立的模型结构——关联关系(Assocation)。object-Z规格说明：在Object-Z语言中，通常采用从下自上的方法建立系统规格说明。只要系统中对象个体的行为都通过类结构进行描述了，整个系统的规格说明就可以通过组台不同的类描述来建立。 J：海大学博．L学位论文我们选择Object-Z语言做为AOMG形式化框架的元模型描述语言主要是基于以下几点考虑：首先，目前Agent在很大程度上可以认为是一种特殊的对象，它在具各自主性和社会性等Agent特性的同时也具备了对象的大多数特性，因此我们觉得采用Object．z来描述Agent实体是可行的；其次，在AOMG设计建模阶段，我们通过扩展UML对Agent实体进行描述，和UML一样，Object．Z语义定义良好，它们之间存在比较精确的形式化映射关系，因此Object-Z既能够支持扩展UML模型的描述，也能够很好地支持不同抽象层次上的模型映射；最后，通过使用基于object．z的推理规则，使得我们定义的Agent具备一定的推理能力。3．3FormalAOMG形式化建模框架在本节我们首先给出了整个FormalAOMG框架下的元模型语义结构。然后按照从分析到设计的过程，逐一介绍了FormalAOMO中的几种核心模型(组织模型、Agent交互模型、Agent类模型和网格Agent服务模型)，同时针对第二章我们所提出的模型映射规则，我们同样给出了基于Object．z语言的更为精确的描述。最后采用FormalAOMG建模语言对第二章的系统实例进行了规格化说明。3．3．1AOMG元模型语义结构Object．Z形式化规格说明的指导思想主要来自于面向对象建模技术，只提供了类和多种关系做为系统规格说明的元模型，这对于面向Agent的建模语言是不全面的，因此需要对Object-Z元模型进行扩充。图3．2基于Object-Z的AOMG元模型语义结构图35 上海大学博士学位论文在FormalAOMG中，我们借鉴Objecl-Z规格说明的基本框架和原则，将AOMG方法中的一些元模型补充进来，从而使其能够采用面向Agent的系统建模思想对网格软件进行形式化规格说明。图3．2是扩充后的是基于Object-Z的AOMG元模型语义结构图。3．3．2形式化组织模型及其元模型在AOMG组织模型中，包含的元模型包括：网格节点、角色、角色间的五种依赖关系。3．3．2．1基本元模型在定义所有元模型之前，先定义一个特定的集合：[Namel，该集合为所有的元模型和模型提供模型名称。同时还定义了一个元类型聊e，后面所有的类型如Agent类型、对象类型以及一些基本的数据类型都是继承type得到。不管是自然世界还是软件范畴，都是由实体构成的，Agent也可以称为智能实体，因此在框架中，还先给出了最基本元模型entity的定义。实体包含了属性集和操作集，其中属性集不为空。r—吨n矗加～name?Nameattributes：FAttri6ute229翌92堂：里￡垄!翌g业Iattributes≠O同时给出了属性似船f6“把)和操作(GIpemrfon)的形式化定义。在Attribute定义中，mutt彬city变量表示该属性实例化后值的数量范围，visibility表示该属性的可视性(包括private，protected-public),在Operation中，其参数名是唯一的。3．3．2．2角色僻口姊和节点(Node)基于以上基本定义，分别对组织模型的元模型进行定义，角色僻D瑚和节点(ⅣD如)定义如下：角色继承了Entity，由于角色也是一种基本类型，因此还继承了Type，responsibiliti酷表示角色承担的职责集合apermissions是角色所具有的行为许可，即角色能执行的一些行为和动作，也称作角色所具有的能力(c印口6f枷b)。dependencies表示该角色与其他角色或 L海大学博士学位论文节点之间存在的依赖关系(在依赖关系中，该角色为依赖者)。在AOMG组织模型中，Node表示网格环境中的节点，AOMG定义了三种网格节点：网格Agent服务节点、组件服务节点和数据库服务节点。3．3．2．3依赖关系(Dependency)在组织模型中，实体之间存在五种依赖关系，这五种依赖关系中的依赖体(dependum)也被称为组织模型中的意图元素，表示角色的意图属性。dependency_name：Namedependum：{GoalTasklSoflGoalResourceIService)depender．"{FRole,FNode}dependee：fFRole．FResource,FNodelV正：depender，d2：dependee；drname≠d2．nameVd3：dependee·d3．dependum=Servicej(以EFNode^dl∈FRole)v(dIEFRole^d3∈FNode)Vd4：dependee·或．dependum=Resourcejd4eFReource^dIEFRoleconvAction．"Tajt>--》FAcKon一一pHnnDp————～⋯⋯q_7⋯“p×V‘，：，‘，)§仨‘．^5r2．________。，。——p×V‘，‘：：，吒，)§，丘，__。，_。^_●，__——p×V‘：1：j：，n．，s)§，．，)______。●。_。，_●●__——l}D×)V‘，t：：，，2，)铮(|．g)‘．^‘，)旺)一。叫⋯u“7q7(，“‘‘，I‘，一％nr：nn，n⋯"，b⋯·P(×)V‘，■：，‘，)§(|‘．)曼^_．)旺^． 上海大学博上学位论文Dependency模式是对组织模型中依赖关系的语义描述，它包含了以下几层意思：(1)五种依赖关系的依赖体分别是：目标依赖、任务依赖、软目标依赖、资源依赖和服务依赖。其中前四种是组织内部的依赖关系，服务依赖是组织内部角色与外部网格环境之间的依赖关系。(2)依赖关系一般由角色僻D功或节点(Node)发起，而被依赖者可以是角色、资源或者网格节点。当依赖关系为服务依赖时，发起者可以是节点，其它依赖关系发起者都是角色。(3)在组织模型中，依赖者和被依赖者不同名。当依赖体为服务(Service)时，依赖者和被依赖者必须其中之一为网格节点(Node)，而另一个为角色僻ole)；当依赖体为资源(Resource)时，被依赖者为资源实体。(4)任务依赖、服务依赖以及目标依赖经过推理最终都是驱动某个角色完成一些具体的任务，通过模式中定义的convAc“on函数可以把任务分解为若干基本动作(action)，即变换成角色之间或者角色和节点之间的行为依赖口ctionDependency)。行为依赖是所有依赖关系的一个原子依赖，假如RJ和岛之间是行为依赖(RJ依赖R2)，则表示m具备了某些能力，而R』不具备。(5)5R，和飓之间存在目标依赖G时俾J依赖恐)，则完成目标G所必须的行为集合是如能力集合的子集，对于RJ则反之。(6)5R1和飓之间存在软目标依赖SG时俾』依赖R2)，则实现软目标SG所必须的行为集合是飓能力集合的子集，对于R，则反之。3．3．2．4组织模型(OrganizatinModel)将实体(Entities)、角色僻ores)、节点(Nodes)以及它们之间的依赖关系(Dependencies)组合在一起便可以得到组织模型。一个基于网格的分布式组织一般包含了角色、资源、请求服务的网格节点以及它们之间存在的依赖关系集合，见Organization模式定义。3．3．3形式化Agent交互模型及其元模型3．3．3．1Agent首先定义基于Object—z的Agent概念模型，见Agent模式。Agent继承了Entity，也属于一种基本类型，因此还继承了聊gacapabilities表示Agent的能力，goal表示Agent个体的目标集合，knowledge是Agent的内部知识库。任意一个Agent的能力、目标和内部知识库都不能为空。38 上海大学博士学位论文capability：FCapabilitygo以FGoalknOWledee：FBellefcapability≠≯^goal≠庐^knowledge≠砂3．3·3·2Grid．Agent网格Agent(GridAgent)是AOMG定义的一种特殊Agent，它除了具备Agent的一些基本特性外，还具有移动能力，最重要的是网格Agent做为网格环境中的一个节点能够为网格中其他节点提供服务。在下面的描述中，耐表示该Agent在网格中注册的唯一标识，service表示该Agent向网格环境中其他Agent所能提供的服务集合，mobility表示该网格Agent是否具有可移动性。在Agent交互模型中，交互关系表示两个Agent之间所存在的二元关联关系。每个交互关系包含一个关联名称口啪豳如H弛w磅和两个关联端翟船。c矧扬，lEnd)。每个关联端包含一个附着的Agent、多样性(multiplicity)约束、导航属性性。见Associati。nEnd模式，一个关联端的多样性必须大于0，导航属性值为True或False。联端组成 l海大学博士学位论文任何一个交互关联关系的两个关联端不同名，两个关联端的导航属性是异或关系，同时两个关联端的Agent之间只存在唯一的交互关系。3．3．3．4Agent抽取规则为了方便从组织模型中抽取出Agent，在FormalAOMG框架中同样给出了基于Object—z的Agent抽取函数，抽取原则是判断组织模型中的角色能否变换成Agent。见elicitAgent模式的函数定义。在组织模型中，如果某个角色属于被依赖者，而且依赖体属于目标、任务或者软目标的一种，则该角色可以抽取为Agent。通过相应的转换函数，角色的意图属性转换成Agent的基本属性，如角色的责任(responsibilities)转换成Agent的目标(goals)，角色的行为许可(permissions)转换成Agent的能力(capabilities)。convGoal：Role．Responsibilf匀一GD口』convCapability：RolePe朋i肼f。州}—》CapabilityconvKnowley；e．"Role．Protocop—》KnowledgeelicitInteraction：Dependency_PInteractionAssociat_I'onVom：OrganizationModel；3d：om．dependencies(j‘，r2：om．roles·(d．depender=‘Ad．dependee=吃))^(3agl，a92：Agent·agI=elicitAgent(r1)^a92=elicitAgent(r2))≥elicitInteraction(d)={a：InteractionAssociationl口．name=”dependency”^(a．et．attached^gent=agt^a．e2,attached,Agent=a92))3．3．3．5Agent交互模型从组织模型中抽取出Agent以及它们之间的交互关系后便可以建立Agent交互模型，见dgentInteractionModel模式。AgentInteractionModelname．"№meagent．"Agent,FGrid^gentinteraction．·FInteractionAssociationVagl。a92：agent·a91．name=a92．namejagl=a92 上海大学博士学位论文3．3．4形式化Agent类模型及其元模型Agent类模型是一种介于Agent抽象层次和对象抽象层次的模型。在建立Agent类模型之前首先定义一个新的概念：Agent类(AgentClass)，它是通过对面向对象领域中的UML类(Class)定义【67】进行扩展得到。AgentClass继承了对象领域中的Class。在AgentClass模式中，定义四种类的构造类型：<>、<>、<>和<>，<>表示Agent实体、<>表示网格Agent，<>表示资源类。AgentClass具有和对象Class一样的可继承特性。同时AgentClass中的属性和操作也对Class原有的属性和操作定义进行了扩展，使其具有一定的Agent属性。alrectouperclass：Agentulass—÷世^gen|乙lassallSuperclass：AgentClass斗PAgentClassVac：AgentClass·directSuperclass(ac)=aczuperclassallSuperclass(ac)=directSuperclass(ac)u(u{sac：directSuperclass(ac)·allSuperclass(sac)})为了实现从分析模型到设计模型的平滑过渡，达到模型语义上的一致。AOMG方法提供了一组从组织模型到Agent类模型的形式化语义映射规则，目前这种模型之间映射还不是完整的和完全精确的，角色模型和Agent交互模型都是建立Agent类模型的重要基础。尽管如此，这种映射规则对提高建模的效率和准确性都是非常有益的。在这些映射规则中，核心部分的是从角色元模型到Agent类元模型的映射，见模式mapRoleToAgentClass。mapRoleToAgentClass只是映射函数的一部分，描述的是从角色元模型到类元模型的映射：(1)在组织模型中，如果某个角色属于被依赖角色，而且该依赖关系的依赖体属于目标、任务或者软目标的一种，该角色映射为一个同名的Agent类，其构造类型为<。(2)角色之间的任务依赖体映射为被依赖角色映射所得Agent类的一个公有操作，其构造类型<>，表示Agent的能力。(3)角色之间的目标依赖体映射为被依赖角色映射所得Agent类的一个布尔型公有属性，41 L海大学博_：学位论文其构造类型为<>，表示软目标的实现程度。(5)当角色和节点之间存在服务依赖时有两种情况：角色为依赖者，节点为被依赖者，则服务依赖体映射为依赖角色映射所得Agent类的一个公有操作，其构造类型为<>，操作名为request．．grid．service，表示Agent有请求网格服务的能力：相反，服务依赖体映射为被依赖角色映射所得Agent类的一个公有操作，其构造类型为<>，表示该Agent提供的服务。在建立Agent类模型的过程中，需要说明的是Agent类模型并不是可以为编程所用的晟终类模型，在详细设计过程中，可以根据编程需要对Agent类模型进一步的分解和细化。convAttribute,"Dependum)_啼Attributecony@eration：DependumOperaaonmapRoleToAgentCtass：Role--}PAgentClassVom：0，{浮H洳疵州泐捌；Vr：om．rolesl3d：r．dependency·d．dependum∈{Goal，Task，SoftGoal}^d，dependee=rjmapRoleToAgentClass(r、={ac：AgentClasslr月ame=ac．name^ac．stereotype=,《agent》A3td：r．dependency‘td．dependum=Task．td．dependee=rj(30p：ac,operations·op=convOperation(td,dependum)·op．visibility=public‘op-stereotype=《capability：¨^39d：r．dependency*鲥．dependum=Goal*gd．dependee=rj旧attr：ac．attributes·attr=convAttribute(gd．dependum)。attri．visibility=public．attr．type=Boolean·attr．stereotype=《goal》^^j昭汀：rdependency*sgd．dependum=SoftGoat·sgd．dependee=rj(3attrl：韶．attributes·attrl=convAttribute(sgd．dependum)·attril-visibility=public,attraype=Enumerated·attrl．itereotype='《soflgoal：秘1^3sd：r．dependency*sd．dependum=Service·sd．depender=，j(30pl：口c．operations·opl=convOperation(sd．aependum)oopl．visibility=public·opl．stereotype=《capability‘opl．name=’r叼uest—gridservice'^3sdl：，．dependency*sdl．deperldlIm=Service,,sdldependee=rj(30p2：dc．operations*op2=convOperation(sdldependum)·opl．visibili妒=public·op2．stereotype=《service：》)}3．3。5形式化Agent服务模型AOMG方法是以OGSA网格体系结构做系统的应用背景，因此在AOMG方法中，网格服务(函f拯wfcB)是一个重要的概念。网格服务服务模型同样可以采用基于Object—Z的形式化方法描述。每个GridService都有一个全局唯一的访问句柄(通常是～个URL地址)，以方便其他节点的访问。每个网格服务实现了两个接口：一个是1Registry接口，用于完成服务在网格中 上海大学博士学位论文的注册，该接口定义了两个操作，分别是注册操作(RegisterService)和取消注册操作(UnRegisterService)；另一个接口是IGridService接口，该接口定义了三个操作，分别用于查询网格服务实例的各种信息(FindServiceData)、设置网格服务实例的终止时间(SetTerminationTime)和终止网格服务实例(Destroy)。在GridService模式eel_描述了一个服务的执行过程。3．3．6建模实例本节采用FormalAOMG形式化框架对第二章所例举的实例1进行分析与设计建模。3．3．6．1建立分析视图分析视图主要包含每个角色的定义，以及它们组成的系统组织模型，然后在组织模型的基础上抽取出系统Agent，形成Agent交互模型。采用与实例l同样的需求获取策略，可以抽取出组织背景中的几个主要角色：Customer(客户)、InternetOrder(N["预定处理角色)、ProductSeeker(商品搜索角色)，Coordinator(协调者)，Financial(网上支付处理者)。这些角色都是FormalAOMG中Role模型的实例，在它们的角色模式中给出了它们的责任、能力等属性定义，同时还定义了其做为依赖者时与其它角色之间存在的依赖关系。 上海大学博士学位论文以上我们列出了五个主要角色模式，结合组织背景中和角色关联的网格节点以及资源可以得到系统的组织模型。 上海大学博士学位论文在组织模型的基础上，使用elicitAgent模式中定义的Agent抽取规则，可以抽取出四个主要的系统Agent：InternetOrderAgent、ProductSeekerAgent、CoordinatorAgent和FinancialAgent。其中ProductSeeker为网格Agent，具有移动和访问网格服务的能力。通过对Agent的能力、目标和知识库以及它们之间交互关系的描述，形成Agent交互图。 上海大学博士学位论文3．3．6．2建立设计视图在AOMG形式化框架中．Agent类模型和服务模型是系统规格说明的最终模型。建立Agent类模型可以借助mapRoleToAgentClass模型映射函数来提高建模效率。在3．I中InternetOrder、ProductSeeker和Coordinator三个角色可以抽取为Agent，因此在设计过程中可采用映射函数将这三个主要角色映射为同名的Agent类，以下给出InternetOrder、ProductSeeker两个主要Agent类描述。在InternetOrder和ProductSeeker两个Agent类模式中，大多数属性和操作都是通过映射函数得到。如InternetOrder类中的security属性和SearchProduct、OrderProduct两个操作都是由组织模型中相关依赖关系映射得到的。可以看出，Agent类模型和标准UML语言保持了较好的一致性。ProductSeeker是系统中唯一的网格Agent，它可以向其它网格节点提供SeekProduct服务。因此为ProductSeeker建立基于Objeet-Z的服务描述，见SeekProduct服务模式。 上海大学博士学位论文3．4小结本章在AOMG建模方法的基础上提出了一种以网格Agent(GridAgent)希l网格服务(GridService)为核心概念的面向Agent软件形式化建模框架—FomalAOMG框架。该框架既可以做为独立的系统建模语言，也可以做为AOMG建模方法在后续设计、实现和模型验证过程中的一种补充。采用FormalAOMG形式化框架最终生成的类模型和标准UML语言保持了较好的一致性，Agent服务模型也符合OGSA中定义的网格服务，因此可以较好地驱动后续设计和实现，而其基于Object．z的模型语言也为模型的验证和推理提供了良好的形式化基础。4' -海大学博士学位论文第四章网格分布式系统的领域资源本体建模4．1基于本体的资源匹配网格能够将各种地理位置上分离的计算和数据资源联在一起，并将这些资源分配给各种异构的用户群。网格中的资源属于不同的机构(institutions)，因此这些资源存在不同的使用规则以及必须满足特定的需求才能接受其它结点的资源请求。对于网格应用软件也是一样，它们有不同的约束机制，只有某些具有特定能力的资源才会被用作服务共享。当运行的一个网格应用需要被分配某种资源的时候，用户或者Agent必,须在网格环境中选择与该网格应用需求相匹配的资源[681。我们把这种基于应用需求的资源选择过程称作“资源匹配”。在网格环境中，资源的“来”和“去”非常的重要，因为它决定了网格中的资源是否能够满足各种不同应用的资源需求。现有的基于网格的资源匹配方法都是基于完全对称的属性比较原则，比如CondorMatchmaker[69】和PortableBatch系统[70】。采用这种基于属性比较的方法，必须使服务提供者和服务访问者都具有相同的属性名和属性值，因此很不灵活，并且扩展性较差。在AOMG建模方法中，我们建议采用基于本体的资源匹配。和传统的基于扁平属性比较(当属性的数量逐渐增多时，就会变得难以管理)不同。资源本体的建立支持采用声明方式描述网格资源和资源请求信息。传统的属性比较属于精确的语法匹配，而资源本体匹配机制则属于基于本体术语的语义匹配。采用基于本体的资源匹配方式，具有很好的可扩展性以及支持一定的语义推理。比如在这样一个领域背景下，某台Linux主机可以响应“请求Unix主机”这样的资源请求，原因就是基于本体的资源描述中蕴含了“Linux主机属于Unix主机”的语义。可以看出，基于本体的资源匹配大大降低了资源提供描述和资源请求描述之间的耦合。AOMGGridApplicatiofi，图4．1基于语义Web本体的资源匹配过程48 上海大学博士学位论文在AOMG软件架构中，所有的共享资源采用本体语言描述，并做为资源本体库存在于AOMG软件架构中。因此，建立系统的资源本体模型也成为面向Agent设计建模的一个重要部分。4．2本体(Ontology)4．2．1本体概念“Ontology”最早是一个源于哲学的概念，是一种对“存在”的系统化解释，用于描述事物的本质，在计算机科学和人工智能领域则译为“本体”。1993年美国Stanford大学知识系统实验室的Gruber博士在文献[7l】中定义：本体是用来帮助程序和人共享知识的概念的规范描述(Anontologyisthespecificationofconceptualizations，usedtohe玲programsandhumansshareknowledge)，后来该定义得到了进一步发展和完善[72】。一般来说，本体的概念包含了四层含义：·概念化，通过抽象出客观世界中一些现象的相关概念而得到的模型，其含义独立于具体的环境状态；·明确，所使用的概念及使用这些概念的约束都有明确(显式)的定义；·形式化，知识本体是计算机可读的；●共享，知识本体中体现的是共同认可的知识，反映的是相关领域中公认的概念集，它所针对的是团体而不是个体。本体的目标是捕获相关的领域的知识，提供对该领域知识的共同理解，确定该领域内共同认可的词汇，并从不同层次的形式化模式上给出这些词汇(术语)和词汇之间相互关系的明确定义。本体的概念和方法被领域采用，用于知识表示，知识共享和重用。某个领域的本体就是关于该领域的一个公认的概念集，其中的概念含有公认的语义，这些语义通过概念之间的各种关联来体现。本体通过它的概念集及其所处的上下文来刻画概念的内涵。总之，本体强调相关领域的本质概念，同时也强调这些本质概念之间的关联。4．2．2本体表示和本体构造4．2．2J本体的六元组表示本体的定义如今在计算机科学领域已比较统一，但在具体的知识本体系统中如何规范化描述本体至今还缺乏统一的标准。目前有两种本体表示方法应用比较广泛，第一是传统的四元组表示方法[73]、第二是较新的六元组表示法。前者源于Gruber博士的观点，后者则是2002年由新加坡南洋理工大学的MyoMyoNaing博士在一篇国际会议论文中提出【74]。前者在世界范围内得到了比较高的认同，但是形式过于灵活，不易掌握。后者则定义 上海大学博士学位论文规范，可操作性强。本节我们介绍六元组表示法：AnOntology={C，A‘，R，A“，H，x)其中C表示概念的集合。彳。表示多个属性集合组成的集合，其中每个属性集合对应于一个概念。R是一个关系集合。∥是由多个属性集合组成的集合，其中每个属性集合对应于R中的一个关系。臆示概念之间的层次结构关系，臃示公理集合。C中的每个元素cj表示同质、并且能够用相同属性集爿。(c1)描述的对象。关系集R中的每个元素ri(cp，Cq)是-个二元组，表示概念白与cq之间的二元关系。关系n的属性可以用A8(cd来表示。序494(cp，Cq)是肿的元素，它表示勺与勺是父子关系或者超集一予集的关系。肿的元素实际上是概念、关系属性之间的一些约束条件。为了深入描述本体的表示方法，以下列出了实例1系统本体描述。Order—Ontology={cD女，厶☆，‰，，如，，也m，．‰，)‰，={Customer，InternetOrder，ProductSeeker，Financial，Product，．)‰，={一j☆(Customer)，再妇(InternetOrder)，如，(ProductSeeker)，‰(Product)，⋯}Aom,(Customer)={Name，IDCard，Address，TelNum，．．．)爿孟(ProductSeeker)={Name，ID，Version，Capabilities，ProvideServices，．．)磊m(P阳妇cf)={Name，Availability，Price，Count，¨．}RDm={OrderProduct(Customer，InternetOrder)，Search(InternetOrder，ProductSeeker)，Pay(InternetOrder，Financial)，Query(ProductSeeker，Product)⋯}‰，={‰(OrderProduct)，‰(Search),‰(Pay)，如(Query)，．}‰，(OrderProduct)={OrderDate，Count，Discount，．)‰，(Search)={Speicification，．}《☆(Pay)={CreditCardNum，Price，OrderCount，．．．)可以看出以上的领域本体都是基于Agent抽象层次，在实例系统中有Customer、InternetOrder、ProductSeeker等不同身份的角色，把这些关于角色的身份的名次归纳起来就得到了概念集合CD咖中的元素。领域中的每一类事物都包含各种属性，把这些属性都列出来就是彳。中的内容，从上例中不难看出一。是一个关于集合的集合。根据实际领域中的客观事实，可以找出两个不同的概念之间的相互关系，从而生成R。其它三个元素的生成也很类似。领域本体的建立通常要依赖领域专家的观点，而不是由开发人员主观建立的。4．2．2．2本体构造近几年来，本体和本体工程(OntologicalEngineering)在知识工程及其相关的应用领域获得广泛的关注。在国外已有很多研究机构和组织在许多领域研究本体的应用，取得了很多重要的研究成果，一提出了很多梅造本体的工程方法，．如MikeUschold和King的“Skeletal”50 上海大学博士学位论文法[75]、Gruninger和Fox的“评价法”(RNTOVE)[76]、Bemeras等人提出的KACTUS工程方法[77】、以及Methontology方法[78】等等。在AOMG设计建模过程中，我们采用“Skeletal”法建立资源本体模型，其流程如图4．2。因为在AOMG需求获取和分析过程中足以使开发人员获取网格应用中资源本体，因此我们重点讨论资源本体的描述。4．2．2．3本体描述语言图4．2“Skeletal”本体构造法流程图传统的本体表示采用人工智能领域开发的形式化描述语言，比如基于KIF(KnowledgeInterchangeFormat)的本体语言[79]、框架语言和描述逻辑(DescriptionLogic)[80]等。其中ⅪF提供一种类4NLisp的语法来表示一阶谓词语句，是一种对本体具有很强表达能力的低级语言。框架语言将每个类的信息捆绑成一个框架，包括该类的名字、该类的泛化类和一系列槽(slot)，每个槽由一对“属性．值”组成，允许对槽值进行某种限制描述，属性也有框架，可以描述其定义域和值域，或是声明该属性具有传递性或对称性等。这种结构使得本体易读易理解，在许多本体知识表示模型中被采用，如Protege[81]，OKBC[82]等。描述逻辑是建立在概念(concept)年[1角色(role)之上的，由构词(constructor)从简单概念和角色中构造出复杂概念和角色。概念对应于经典逻辑学中的一元谓词，角色对应于二元谓词，构词决定着语言的表达能力。知识库主要由TBox和ABox组成，前者是描述概念关系的术语公理集，后者是描述个体实例的断言公理集。最近几年，随着语义Web[831184]的不断发展，结合知识表示系统和Web规范，本体描述语言才有了顺势的不断进展[85】，出现了很多结合语义Web的本体语言，包括SimpleHTMLOntologyExtension(SHOE)[86]、OntologyMarkupLanguage(OML)[87]、ResourceDescriptionFramework(RDF)[88】和RDFSchema[89]，以及OntologyInterchangeLanguage(OIL)[90]、DARPAAgentMarkupLanguage(DAML)+OIL【91151]WebOntologyLanguage(OWL)[92]等，其中由W3C提出的OWL则是最新的本体语言。采用语义Web本体语言，信息被赋予明确的含义，使得机器自动处理和集成Web上的信息更为容易。语义Web将构建于XML自定义标签模式的能力以及RDF灵活的描述数据的方式上。在语义Web使用RDF之前，语义Web需要在RDF之上增加的第一个层次是一种能够对Web文档中的术语含义进行形式化描述的本体语言。如果希望机器能够对这些Web文档进行有效的推理工作，这一本体语言必须超越RDFSchema的基本语义。OWL通过提供更多具有形式语义的51 L海大学博士学位论文词汇，使之在Web内容的机器可理解性方面要强于XML、RDF和RDFS等所能达到的程／室[921。因此，我们建议采用OWL构造网格分布式应用系统的领域资源本体。4．2．2．4OWLOWL的开发目标不是针对人来描述Web信息内容、而是为了解决面向应用程序和环境之间的的语义互操作的描述语言，它通过本体来显式的表达词汇、术语的意义以及他们相互之间的关系。OWL沿袭RDF的基本事实陈述方式以及RDFSchema(RDF．S)的类和属性分层结构，并以描述逻辑为基础理论构建语言系统。OWL有三个表达能力递增的子语言：OWLLite，OWLDL，和OWLFull。·OWLLite用于提供给那些只需要一个分类层次和简单约束的用户。例如，虽然OWLLite支持基数限制，但只允许基数为0或l。·OWLDL用于支持那些需要最强表达能力而需要保持计算完备性(computationalcompleteness，即所有的结论都能够确保被计算出来)和可判定性(decidability，即所有的计算都能在有限的时间内完成)的用户所用。OWLDL包括TOWL语言的所有的构词，但使用时必须符合一定的约束，例如，当一个类是多个类的子类时，则它不能同时是另外一个类的实例。OWLDL这么命名是因为它与描述逻辑一致。这个领域所研究的是构成OWL主要基础的逻辑。·OWLFull支持那些需要最强的表达能力和完全自由的RDF语法(尽管没有可计算性保证)的用户。例如，在OWLFull中，一个类可以同时被当成是许多个体的集合并且自己也是其中的一个个体。它允许在一个本体增加预定义的(RDF、OWL)词汇的含义。这样，不太可能有推理软件能支持对OWLFULL的所有成分的完全推理。关于0wL三个子语言的详细描述可参考OWL指南[921。和Ⅺ)F(S)一样，OWL可声明类和属性，并由类包含子类(subClass)和属性包含子属性(subProperty)公理来划分各自的等级层次。但OWL的类是能通过逻辑组合算子(合取，析取，补)在其他类的基础上得以描述，也能视为多个对象的枚举类；同时OWL还可声明某个属性具有传递性、对称性、函数性，或是某个属性的逆属性。显然这些都超越了RDF(S)的能力。更为重要的是，OWL允许通过属性限定词(restriction)，并结合对属性的描述和对类的归属来自定义新的类。OWLLite，OWLDL以及OWLFULL作为OWL提出的三种子语言，其表达能力依次增强，且推理能力逐个向下兼容。不过前两者基于比较抽象的框架式句法，采用经典逻辑学中的解释，即：(1)要求个体、类、属性是三个不相交的集合：(2)所有的个体视为资源，而将类直接视为资源的集合，属性则直接视为<资源>的集合；(3)禁止递归的出现，从而避免上述RDF(S)*的问题。而OWLFULL则可视为不受限制的RDF(S)的扩展，句法仍使用RDF三元组，并基于非经典的模型论对RDF语义做OWL的语义扩展。 L海大学博士学位论文4．3基于UML的资源本体模型(ResourceOntologyModel)OWL本质上是一种以描述逻辑为基础理论而构建的语言系统，因此构造基于OWL的资源本体本体对开发人员的要求非常高，开发人员必须懂得一定的形式化语言。UML做为面向对象建模领域中的标准建模语言，可以为应用领域的概念建模提供有效的和可度量的方法。使用uM酹日OCL进行本体建模有以下几个特点：·和形式化的描述逻辑不同，UML为提供了标准的图形表示来建立本体模型。这种图形表示方法能够方便开发人员浏览一个本体并从中找到他想要了解的概念。相反，描述逻辑包含线性语法但没有图形表示。·由于UML是抽象的模型语言，用UML建立的本体模型和系统的编程语言无关。·UML包含了关系约束语言一OcL，OCL功能很强，可以任意的定义模型实例的约束，这是描述逻辑所做不到的。·虽然目前有很多形式化的知识表示语言也提供了图形化工具，但uML是唯一具有严密、高层次和标准化图形符号和强大的商业支撑工具的表示语言。·在AOMG设计建模过程中，我们已经使用扩展的UML类图对系统Agent进行描述，因此很容易在Agaat类图基础上获得资源本体模型。因此，我们在AOMG建模框架中通过扩展UML类图来对网格应用中的资源本体进行建模[93】，在这里我们称这个模型为资源本体模型(ResourceOntologyModel)，也就是说本体模型中的元素和该本体的语义相关联。我们对基于UML的本体模型做如下的约定：·网格分布式系统的资源通过一个本体来表示，其中主要描述数据资源(包括关系数据库和基于ⅪⅥ啦式的数据)和网格Agent这两种可以做为服务共享的资源，以及它们之间的关系。·本体模型框图和uML的类图相似，采用不同范型(stereotype)的类来表示不同类型的网格资源：其中范型为<>表示数据库资源类；范型为<<幽打护》表示数据库资源类所包含的实体类(它们的关系就像是数据库和表的关系)；范型为<>时表示网格Agent资源：范型为<>贝ll表示网格AgentPfi提供的网格服务。我们把这些不同范型的类统称为本体类(OntologyClass)。·本体类通过公有属性来描述，不包含私有和保护型属性。本体框图中的类和系统的具体实现没有直接的关系，因此实体类不包含操作。·在本体模型框图中定义了三种关系：关联关系(Associations)、累计关系(Aggregations)和泛化关系(Generalizations)，都是从U】ⅥL的类框图继承下来的。本体类之间的关联可以看作用来建立领域资源的谓词。·为了达到对本体类更精确的表示(比如对属性之间依赖关系的描述)，采用OCL对实体加以约束，OCL通过注释加到本体框图中。 t海大学博士学位论文genP,<>SeekerProduct0rder：OUlD+id：OUID：Char+COmment：cn8r：Char+varsl013：Char：AgentClass+Connsctionstrina：Char；一eetLisl+preyideentity：．SetListet：Usl+reseurcs_set：char：char1’＼，＼、＼Pmv““＼1＼＼弋＼．。(,cGrldSewlce’，ttEnti～''0trierServ|ce+id：0U1DProduct+COmments：char+availability：int+version：cher+price：int+execution—modeI：Cher+name：Int+negotiable：boolean+一：Int+type：char+AAA：char+taSkIist：Task图4．3基于1mⅡ，的资源本体模型根据上面的原则，我们为实例1系统建立资源本体模型。在图4．3的本体模型中，我们定义了两种共享资源，一种是系统的数据库资源类(ProductOrder<>)，在该资源类中我们定义了该资源的访问句柄(奶、资源的基本描述(comment)、版本信息(w船foH)以及数据库的连接字(connection_string)等，同时还定义了该资源类包含的表信息。在实例系统中真正和系统相关的数据库包含的表有很多，包括用户信息、定购信息等，但是只有Product表做为共享资源定义在资源本体中；另一种是网格他ent资源(ProductSeeker<>)，在网格Agent资源类中，定义了该网格Agent的访问句柄、版本信息、实现该网格Agent的类(class_deft网格Agent通过Java类实现)等，同时定义了该Agent提供了哪些网格服务(provide_service_set)及使用了哪些网格服务(use__service。每个网格资源类都能提供相应的网格服务，比如就能提供搜索商_．se品t)的服务，这些A服gen务tProductSeeker通过网格服务类来表示，在．毙如Product网格服务类中定义了该服务的访问句柄、执行模式(execution—model，比如顺序执行、并发执行等)、以及该服务能完成的任务列表(task4．4从UML到OWL的映射采用UML建立资源本体模型对于开发人员来说很容易掌握，因为UML是面向用户的，但是在网格应用中，基于OWL的本体是可以直接被机器处理的，即面向机器的。如何快速地从基于UML的可视化本体模型获得能够真正在网格环境中被访问的领域资源语义本体成为我们构造网格应用资源本体的关键问题。UML可以序列化成基于XMI格式的文件， }：海大学博士学位论文而OWL本身就是根据RDF(标准的XML表示格式)定义的，同时，UML和OWL都是基于“类”的模型语言。UML和OWL的这些特点为它们之间的映射提供了可能性，通过对UML元模型和OWL构词的分析，并参考现有的一些关于UML与本体语言比较研究的工作[94][951，我们建立了这两种模型语言之间的映射关系表，见表4．1。由于建立映射关系的目的是为了获得基于OWL的本体描述，因此这种映射关系是单向的，不可逆的。表4．1从UML到OwL的语义映射关系表UML0WLclassowl：ClassinstanceOfrdf：typetypeofModelElemeotrdf：typoattributeowl：ObjeetPmpefty或owl：DatatypoPropertybinaryassociationowl：ObjeetPmpertygeneralizationrdfs：subClassOf<>stereotypeddependencybetween2rdfs：subPropenyOfassociationsgeneralizationbetweenstereotypedclassesrdfs：subFropertyOfnOterdfs：uotrm'P．mtfd矗：l曲elNaloeofclassrdf：lDclasscontainingtheattribute‘'rdfs：subClassOf，’oilapropertyrestrictionsourceclassof锄association‘'rdfs：subClassOf'’oriaproponyrestrictionattributetype‘'owl：toClass”onapropertyrestrictiontargetclassofanassociation“owl：toClass”oilapropertyrestriction<>stereotypeddependencyowl：equivalentClass<>stcreotypoddependencybetweentwoowl：equivaleotClassclasses<>stereotypeddependencybetweenowl：equivalentProportytwoassociations<>stereotypedpackageowl：Ontology“versionlnfo'’taggedvalueona础agcowkvcrsinn[rtfoimport(dependencystereotype)owl：importsmultiplicityowl：cardinalitymultiplicityrangeYZY=owl：minCardinality，Z=owl：maxCardinalityassociationtargetwithendmultiplicity=0“1or1UniquePropertyassociationsourcewithendmultiplicity=0．．1orlUnambiguousProperty<>stereotypeddependencybetweentwoowl：inverseOfassociations<>stereotypo0nallassociationOwl：TransitivePropeny以上映射规则我们都集成在AOMG建模环境中，而且在AOMG建模环境中，所有模型都是采用基于OWL格式的文件存储方式(实现过程见第五章)。例如以下是对图4．3资源本体中的ProductSeeker类进行序列化得到的OWL描述。 ：兰塑查兰堡!：堂堡笙兰一一——GridAgentformaclass．<／rdfs：eorament><／owl：Class>GddServiceformaclass．<／rdfs：comment><／owl；C’lass>(rdfs：comnlent>databaseformaclassdisjointfromgridagem-(／rdfs：comment>anagentperformproduet-sceking<／rdfs：eomment>http：／／aomg．shu．edu．on／baseaomg_model／ProduetOrder／<／rdfs：comment><／rdfs：subClassO争,Cow}-Classrdf：about=”parallel”卢<／owl：oneOf><／owl：Class><／owl：allValuesFrom><／owl：onProperty>56 p海大学博士学位论文<／owl：ObjcctProperty><／owl：Class><／owl：allValuasFrom><／owl：ObjectProperty><／owl：oneOf><／owl：ObjectPropcrty><／rdf：subClassO伽<／owl：Class><／owl：Ontology>刮rdf：RDF>4．5小结为了实现网格系统之间的基于本体的服务查找和匹配，在本章我们提出了一种基于扩展UML的资源本体建模方法。该方法通过扩展UML类图来建立资源本体模型，而在本体构造过程中则通过一个从UML类图到OWL本体语言的映射关系表来建立资源本体，陕射关系在我们开发的建模工具中表现为基于OWL的模型存储，因此模型的有效性也验证了映射关系表的有效性。但是，由于UML和OWL两种语言之间所存在的语义差异，目前的这种映射关系不是完全精确和完整的。在实际的领域本体构造过程中，可以在使用映射关系表的基础上根据系统实际情况做少量的修改。 上海大学博士学位论文第五章AOMGToolkits：面向Agent分析与设计建模环境5．1引言面向对象方法(例如OMT[96]、Booth[97]和Fusion[98])的深入发展，很大程度上归于其引入了直观的建模语言(如UML)以及相关的可视化分析工具(如RationalRose[99])。大多数的时候，在“非常规的”情况下(即当我们不是创建一个将要建立的软件应用的分析或者设计模型时)，我们会使用画图工具(比如Ⅵsio、CorelDRAW等)。然而，这些工具对软件的建模来说是不适合的。它们只适于创建单个的图画，如果我们想要创建几个图，我们必须可以手工的保证在多个维护点上的一致性。同时，如果尝试着通过一个大图来描述系统，将发现在视图中添加甚至一个元素都将是“不可能完成的任务”，将需要找到自由的空间来画新的元素要避免交叉关系连线。最终，将得到一个非常复杂的圈，这个图是让人难以理解的，不是真正有用的和几乎不可能仅在一张纸中打印的下的。建模工具能够比画图工具更好的支持这种复杂的建模工作。它提供了创建系统不同视图、视图之间的依赖关系和环境的方法。开发适当的建模工具具有以下好处：(1)可以通过以下的方式管理复杂的模型：·创建几个仅仅显示少量元素的图。·仅定义一个元素一次，就可以使它在几个图中显示(建模工具确保一致性；如果在一个模型或者任何显示了这个元素的图中修改了一个元素，在其他多处引用了这个元素的图将被提示修正)。·在某个图中显示或者隐藏元素的细节／属性。(2)查询模型以得到指定的信息并了解元素内部和元素之间的依赖。例如，可以让建模工具创建一个图，图中的所有元素与其他元素存在着特定类型的关系。也可以用匹配的搜索标准来得到所有显示了元素的图，然后浏览他们中的每一个。·检查并确保图的元素符合概念模型的规范。·添加原型和相应的图标。自定义的图标能够很大程度的改进易读性并能够可视化的表达意图。●在团队中使用相同的模型工作。鉴于此，我们采用Java语言开发了AOMGToolkits环境以支持采用AOMG方法的分析与设计建模过程，辅助用户进行网格软件的系统建模AOMGToolkits是支持AOMG建模方法一个工具集。它的核心包括了图形化模型编辑器、模型检查和分析工具以及模型转换工具[100]。本章我们重点讨论AOMGToolkits建模环境的设计实现问题。 上海大学博士学位论文5．2AOMGToolkits基本设计框架理。图5．1是AOMGToolkits建模环境的体系结构图，它描述了AOMG建模环境的运行原图5．1AOMGToolkits体系结构用户通过界面请求总控机启动一个新建模型的过程，总控机再请求模型管理器MM通过XML文本或数据库加载模型数据，MM则会请求分析视图管理器AVM依照数据建立对应的视图窗口，并在窗口中显示各种模型图元。总控机会应用户的请求启动模型语法检查器，监视正在设计的单个模型，对不符合AOMG元概念模型规范的操作发出警告。而模型一致性检查器通常是在模型设计完毕的时候，被用户用来检测现有的整个设计是否符合所有的AOMG模型约束。用户还可以请求总控机建立一个Djava脚本控制台DC[1011，运行自己设计的脚本程序。基于概念模型的分层描述框架，AOMGToolkits相应地采用了多层类封装的设计形式。多层类封装框架为各类建模视图的绘制提供了方便，体系结构中的各个功能模块被包含到六个包里。基本设计框架如图5．2所示：图5．2AOMGToolkits环境基本设计框架其中AomgPackage是整个系统的主体包，包含环境的设计主函数，协调其他模块完成建模过程，建立各种模型框图，如角色组织模型框图(OrgaIlizationModelDiagram)、Agent59 上晦大学博士学位论文交互框[](AgentInteractionDiagram)、Agent类框[](AgentClassDiagram)，以及其他的信息窗口(如模型冲突窗口)，负责集成Djava脚本控制台，高级用户可以创建能在建模工具内直接访问对象模型的脚本来添加其它增强功能。EnvironmentPackage定义各类环境变量，和一些本地环境相关处理模块以及基本元模型的加载等，如根据区域环境显示中文、英文或者其他语言。ImagePackage包含所有使用到的图示信息，例如各类概念模型和关系模型的图形显示信息。其他模块通过对该包的调用来获取图形元素的显示信息以及其封装的概念模型。ModelPackage包含所有的概念模型类，代表AOMG元概念模型以及其他的分析模型。10Package主要完成模型数据的文件或数据库存储。负责保存用户需求分析过程的各种设计结果，重建用户定制的环境设置，并使用OWL用来记录模型的各种逻辑信息，用以分析和推理。AnalysisPackage负责并提供模型设计的检查与分析。它由一个模型语法检查模块(SyntaxCheckingModule)科l--个模型语义一致性检查模块(SemanticConsistencyCheckingModule)组成。它们相互重叠，但又互为补充，分别实现动态模型的语法和静态一致性约束。5．3AOMGToolkits设计模型5．3．1模型分层机制建模环境的核心设计任务是围绕着基本模型的表示、描述和分析等内容进行，因此元模型怎样在环境中描述和使用是非常关键的问题。在AOMG建模环境中，所有模型的定义都是通过模型处理包(ModelPackage)来实现的。PrcscncalionMaaagaScm自ctticlayerLayer；黜黪叠}；I囊；馨霹黪黪fk／／＼＼／图5-3AOMG模型层次图如图5，3，AOMG环境基本模型设计采用了三层结构：第一层为GUI显示层，主要是通过视图模型为用户提供一个图形用户接口，并对模型进行展示；第二层为操作层，主要是表示AOMG元模型逻辑，并响应来自GU'I层的请求来对基于XML(OWL)的模型信息进行操作和保存：第三层为抽象语义层，凸现建模环境中元模型的逻辑信息，主要是用来实现60 上海大学博士学位论文基于OWL的模型描述，为抽象系统模型的分析，乃至模型语义冲突检查奠定基础。5．3。2AOMG元模型设计本节将就在实际的AOMGToolkits环境设计过程中怎样封装、表示元模型等问题进行简要的说明。AOMG建模环境的核心设计任务是围绕基本元模型的表示、描述和分析等内容进行，因此元模型怎样在AOMG建模环境中描述和使用是非常关键的问题。以下我们采用UML对不同层次上的元模型包进行设计。5．3．2．1环境元模型概要设计为了实现元模型的多层表示，我们利用LrML建立了环境元模型概要类图(图5．4)，图5．4描述了我们在进行元模型设计过程中使用的抽象和封装机制以及一些设计模式。其中Aomgltem类是一个定义元模型的基类。给出一些通用的方法(如在分析和保存模型时，递归获得它所有涉及到的Aomgltem对象)。其他的模型描述类ModelDiagram、AomgModel和Diagramltem等都是该类的子类。AomgModel是所有AOMG概念模型定义类的基类，提供它们的熬性定义。如模型名称以及添加属性的方法等。AbstractModelDiagram抽象基类提供概念模型似omgModel)和它的图形表示(DiagramRem)l售-]的影射，是连接其逻辑和图形表示的桥梁。Diagramltem是所有描述概念模型图形标识的处理类的基类。这个类通过对AomgItem的封装，为AomgModel定义的概念模型绑定一个供其在分析视图中显示的图形元素(如边、节点或图)。此时，可以从ModelDiagram获取到这两个类之间的映射关系。如果要将该概念模型元素显示出来并反映其变化，则需要调用Displayltem类。它们之间使用设计模式Observerdesignpattem[102]来连接。该类通过对DiagramDisplayPanel的调用，将作为其子类的各类元模型的图形显示类(如RoleDisplayltem和AgentDisplayltem等)绘制在屏幕上。它同时还定义了图形调整和移动的处理方法，供用户在屏幕上修改和移动图形使用。图5．4环境元模型概要设计类图6l 上海大学博士学位论文为了更好的组织和分析视图，AOMG的元模型中定义了分析视图的逻辑模型类Ana抽isModel和设计视图的逻辑模型刿DesignModel。每种具体的视图都将内部逻辑结构存储在逻辑模型类Ana抽isModel或DesignModelr}】，且用它来保存和重构自身。AnalysisModel类和DesginModel类继承TAomgModel，依赖于D￡向ultModelDiagram从而获得视图中元模型的逻辑和图形表示对象。另外，在各种具体的框图(如AgentInteractionDiagram)里需要定义概念模型类型与它的图形表示类型的影射关系(如组织模型框图中意图角色表示为内嵌名称的椭圆)，这样可方便地改换分析视图里各类元概念模型元素和元关系模型的图形表示。5．3．2．2AOMG概念元模型设计为了在建模环境里表示和操作AOMG元模型，我们参照其定义基于AomgModel类型环境声明了GridNode、Agent、Grid_Agent、Dependence等概念(见图5．5)。其中ElementModel抽象了系统的实体元模型对象，如Role、Agent等；而MediumModel则抽象了系统中的角色或Agent与外界的关系，如组织模型中的依赖关系(D肇en如"q力、Agent交互模型中的交互消．g(AgentMessage)等。图5．5AOMG概念元模型设计类图5,3．2．3AOMG语义元模型设计环境元模型中的AOMG需求模型仅仅包含那些在系统建模过程中需要显示和操作的部分，而从模型分析的角度来讲还是不够的，应当补充缺失的AOMG概念元模型并按照其语义关系重新组织模型结构。在设计时通过在ModelPackage中建立一个专门应用于AaMG概念元模型处理的包semanticPackage来实现其定义(见图5．6)。 【：海大学博士学位论文has图5．6AOMG语义元模型类图我们在AOMG元模型的基础上提出了抽象语义层，仅仅暴露AOMG元模型的逻辑信息，并为模型属性提供了规整的的访问接口，简化模型的OWL描述的生成过程，为模型冲突检测提供方便。5．3．3模型框图设计框图是各类元概念模型元素通过元关系模型连接在一起形成的一个演示系统某一方面设计特性的表示模型。框图的设计是以元概念模型及其关系的展示为根本任务，重点在于将框图模型作为一个攘体的操作行为。对应于AOMG建模方法，环境设计了多种类型的分析与设计框图来建立基本元模型及其之间的复杂关系，以之辅助用户表现、分析系统模型。例如分析建模过程建立的框[]；苜OrganizationModel、RoleModeKAgentInteractionModel等。图5．7模型框图设计类图63 J一海人学博士学位论文如图5．7，AbstractView抽象类是环境窗口框图的基本类，提供了显示框图窗口，调整窗口布局的处理方法。View是不直接进行模型操作的普通窗口(例如，信息统计窗口、帮助窗口)的基类。AbstractModeltqew抽象类提供了创建新模型框图并在其中建立、选择、删除模型节点等多种操作。Analysisl,々ew是各种分析模型框图的基类，它的逻辑结构是基于元模型中定义的AnalysisModel类。CustomizerHew是概念模型编辑框图的基类，侦听框图窗口中当前选中的AomgModel模型对象，并为用户提供图形接口对模型对象的各种属性进行改动。5．4基于OWL的模型存储机制5。4。1模型抽象语义层这罩我们主要实现基于OWL的系统逻辑模型的文件存储。用户使用需求建模环境提供的各种元模型建立起应用系统的组织模型和Agent交互模型，反映出组织背景中角色之间彼此依赖关系、组织内部的角色和外界网格环境之间的交互关系和承担角色完成组织目标的Agem间的协作关系。然而，承载这些信息的AomgModel对象里还含有其他的与上述系统逻辑无关的信息，如其显示所用Disp】ayltem对象，令模型属性组织缺乏条理性、层次性；另外，我们还将要对模型进行自动的语法检查，需要我们进一步规范模型的属性访问接口。如将各种聚集类型(如树，链表)归为数组这一简单类型。因此，我们在元概念模型的基础上提出了抽象语义层(semanticsurface)。它关联于元概念模型，仅仅暴露出模型的逻辑信息。并提供了规整模型的访问接口(例如将聚集类型属性Tree、HashMap序列化到数组中)，返回使用简单结构的模型属性，简化各种模型操作(如OWL描述)和分析(如自动语法约束)。图5．g抽象语义层类定义 上海大学博士学位论文如图5．8所示，接口类semanticSu咖ce定义模型的通用操作。其中toXML0、toOWLO分别提供生成模型XivIL、OWL的描述。每个抽象语义层模型类(Ji[IAomgSEntity)对象通过构造函数(如pulicAomgSEntity阻omgModel一)令theBase属性指向其原型模型类(如AomgEntity)对象，从而建立影射关联。任何模型语义属性访问都将通过规整的接口。例如，角色模型的语义层将提供访问其GOAL、C爿尉8，上。册等属性接I]getGOALO、getCAPABILITY0、setGOALO、setCAPABILITY0。除此以外，这样做还有一个好处：例如对于外部引入的新模型FO，我们可以方便的将它集成到建模环境，却不必为之开发其相关的模块如AomgFO、AomgFODisplayltem等。具体做法如图5．9：1外部模型Fo的-I调用AsccM进行lFo在语义上归属。{按{|ll最近语义蘸1模型库—1雨C捂珏1归类分析r—葡夏要型—1略筛选【．．．．．．．．．．．．．．．．．．．．一、、、．．．—．．．．．．．．．．．．．．√、、、．．．．．．．．．．．．．．．J最近语义父类I餍籍*!吓甄图—庙＼地蔓垫型塑墨／L垡熊整叁／＼／图5．9外部模型引入流程(1)利用AOMGToolkits提供的OWL推理机ASCCM[103]在现有模型库中对FO的定义进行归类分析，发现其在语义上“直接归属”模型NAO，既FO满足NAO的所有规格约束且与之最为相似。(2)实现抽象语义类SFO。抽象语义类SFO从SNAO派生，按照FO定义属性访问接口。在环境中使用这个新的模型FO时则需要初始化新aomg,model．NAOmodel以其相关功能对象，然后使用它作为参数，建立SFO实例对象。由上面的论述可知，这实际上是对建模环境的一种灵活调整，适于将一些通用的、与AOMG概念模型相近似的模型纳入到建模过程中，增强模型视图的表达能力。5．4．2模型序列化存储机制AOMG总体OWL描述框架所体现的模型间的各种关系，要求我们按照～定的顺序去保存才不会出现冲突。例如，ServiceDependency的hasdependenee会指向同一OrganizationMj如，的Role，所以我们应当在ServiceDependency之前保存Role等其相关联的模型。下图给出了部分AOMG基本元模型的附属．依赖关系。 圭查查!!型：兰笙堕苎图5．10部分AOMG元模型附属一依赖关系如图5．10所显示，上层模型在语义上“包含”了自己的下层模型，而同一层的模型会依赖于自己左边的模型。于是，每个上层模型对象都应当负责保存自己的下层附属模型对象，然后保存自己；在同～层中则要先保存左边类型的模型对象。附属关系(cR)和依赖关系(DR)都是可传递的、反子反、反对称的，而且逆向的附属关系(—cR)隐含了依赖关系。例如，在上图中，组织模型要先依次保存其包含的各个角色模型、节点模型、依赖模型，然后才保存自己的各种属性。为了保证建模环境的可扩展性，我们采用visitor设计模式i1021，灵活的实现上面的存储顺序。即是，在定义模型类时，都要实现在SemanticSurface中定义的booleanseralizedbyO接口和booleanafter阻omgSemanticModel州接口，分别声明层次图中的附属关系和依赖关系，并调用modeIRegister(classd在全局visitor类对象中注册自己。表5．1模型顺序存储的实现代码1ClassAomgSTaskDenpndencyextendsAomgSDependencyimplementssemanticSurface{2publicstaticbooleana#er(AomgSamanticModelm)t3．．．．．4if(minstanceofAomgSRo哟5returntrue；6)78publicstaticbooleanseratizedby(AomgSernanticModelm)t910if(minstanceofAomgSOrganization)"retumtrue；12)13)14)表5．1的代码说明任务依赖模型应当为组织模型包含，并依赖于角色模型。为了保汪不会出现循环的依赖和附属关系，每次环境初始化的时候都会通过visitor类66 上海大学博上学位论文的西ec幻姚feD甲{=)方法首先检查是否存在循环的附属关系，然后将存在的附属关系反向归为依赖关系，再检查循环依赖。visitor类的orderfilter(classc,AomgSemanticModel[]圳将会在m中过滤出与C存在附属关系的类对象，并按照依赖关系排序后返回。5．4．3AOMG模型的文件存储5．4．3．1Jena软件包简介Jena2．1[104]软件包提供了一系列的OntologyAPI用以构建和操作基于RDFS、DAML和OWL语言的本体模型信息。它定义了OntModel类用来保存和操作所有的声明(stat锄ent)，OntClass代表类型，ObjectProperty和DatatypeProperty分别代表对象属性和数据属性，Individual代表个体也就是类的实例。语言中定义的模型属性被影射成方法调用。例如对于subClassof属性，OntClass有一个listSuperClasses0方法负责返回相应模型类型的所有父类型。在Jena的早先的版本中，所有的API被绑定到特定的语言(如DAMLClass，DAMLProperty)，而在Jena2．1则所有API的使用是语言无关的(如OntClass，ObjectProper幼，而每种语言都相应得定义了一个映射文件(profile)，列出了自身允许的所有类和属性的结构和URI。例如，在DAML的影射文件DAMLprofileeP，对象属性的URI为daml：ObjectProperty，而在OWL的影射文件OWLprofile@，对象属性的URI为owl：ObjectProperty，但在RDFS的影射文件RDFSprofileqb则不存在对象属性的映射。我们在定义OntModel都被绑定了一个profile，标识出该模型所使用的语言。Jena2．1中提供7"DocumentManagerV具类用以处理本体模型的导,入(ontologyimport)。我们可以通过DDc“棚e”t^缸n口班rPD矗掣类用来定制具有特定导入策噼h63DocumentManager；通过访Ih]OntDocumentSpec类的属性或者修改策略文件(ont．policy．rdf)调整各种导入选项。例如，禁止导入指定URI的模型文档，以及uRJ的重定向。5．4．3．2模型存储的实现过程下面我们通过代码片段举例介绍AOMG模型存储的实现过程。首先介绍新建一个基于OWL语言的模型(owlmodel)的过程。它分三个步骤：步骤1：初始化过程，代码如下。OntModelowlmodel=ModelFactory．createOntologyModel(OntModeISpec．OWLMEM．null)：，‘获得DocumentManager‘／mgr=owlmodel．getDocumentManager0；／．重定向数据类型定义URI。／mgr．addAItEntryf”http：Uaomg．shu．edu．cn／base_aomg—modet／base-ex·dr"．”file：D：lascm／base．ex-dt．xsd”)／．重定向AOMG基本概念模型URI*／mgraddAItEntry(“http：／／aomg．shu．edu．cn／base_aomg—model”。"file：D：／ascm／aomg_basemodel．daml”1：／+添加AOMG基本概念模型前缀‘／ 圭塑盔兰堡主生垡丝奎owlmodel．setNsPrefix(。aomg",aomgbaseUd+'#'’)：mgr．addPrefixMapping(aomgbaseUri+"#”，”aomg”)：r添,自lXMLSchema和自定义数据类型URI前缀吖mgr．addPrefixMapping(“http：／／www．w3．org／2000／10／XMLSchemaUHxsd”)：mgr．addP阳nxMapping(”http：／／aomg．shu．edu．cn／aorng_base_model／base-ex-dt","exd”)：P设置模型根路径和前缀。／this．baseUri=”http：／／aomg．shu．edu．cn／designs／'‘+theModelgetNameO；owlmodel．seINsP怕们xoheModeI．getName0，baseUd+"#'’)：mgr．addPm日xMapping(ba8eU—r#",theModel．getName0)；步骤2：处理AOMG基本概念模型等导入模型文档，代码如下。mgr-setProcesslmports(true)；mgr．IoadJmpo^(damImodeI．aomgbaseUri)；Stringexduri=mgr．getURIForPrefix("exd”)：Stringexdfilename=“D：lascnVbase．ex-dt．xsd’’：TypeMappertypemapper=TypeMapper．getlnstance0；Listtypenames=nulJ；l州typ。“8⋯es2XSDDatatype-loadUserOefined(exduri．newFileReader(exdfilename)，null．typemapper)；}caIch《E×cepI|oneXSystem．out．print(e)；)，’注册取出白定义的数据类型．，System．out．println(”Definedtypesare：”)：for(Iteratorj=typenames．Iterator0；i．hasNext0；)(RDFDatatypestring_type2typemapper．getTypeByName(mgr．getURIForPrefix(”exd”)+W+i．next())：typemapper．registerDatatype(stdng_type)；System．out．println(”-。+1．ne)cI())．)——-：：了—■：=工●=：_==●_=—●———●●————————————————————一一其次，我们举例说明如何在owL模型(owlrnodel)中建立组织模型(organization而：：：而模型定义，代码如下。—————————————————————————————————————————一_Stringname2”aomg_Organizatlon”：OntClassc2basem．createClass(baseURl+'#'‘+name)；AIIValuesFmmRestrictionqcl=basem．createAIIValuesFromRestfiction(nuII．b83。m·getProperty(baseURl+’妒+¨hasrolepmperty'’)，basem．getOntClass(baseURl+”扑”aomgro∽)：AIIValuesFromRestrictionqc2=basem．createAIIValuesFromRestdction(nuII．——basem．getProperty(baseUR—l+"#"+"hasnodepmpert3P),basem．ge—tOntClass(baseURl+．#．,+,,aomg_node,’))： 上海大学博士学位论文AI]ValuesFmmRastrictionqc3=basem．createAIIValueaFromRestdction(null，basem．getProperty(baseURl+"／#'+”hasresourcepmpe竹”)，basem．getOntClass(baseURl+’甲Peomg_entity”))：AIIValuesFmmRestrictionqc4=basem．createAIIValuesFmmRestfiction(null．basem．getPrope时[baseURl+!／f'+”hasdependencypmperty”)．basem．getOntClass(baseURI+'#”+”dependency"))；IntersectionClassinstric=basem．createIntersectionClass(null，basem．createList(newRDFNodell{qcl。qc2．qc3，qc4))kc．setSuperClass(instTiC)；最后，我们利用组织模型语义层类0D峙坍D如^j硎口nffc．D曙佣拓dffo”)的幻D耽O方法在owlmodel中建立组织模型实例，代码如下。r保存其附属模型吖List[teratorli。org．getlterator0；whlle(1i．haaNext0)fAomgltemitem=(AomgItem)li．next[)；if((iteminstanceofAomgModel)&&0item．Sedalizedby(org))，‘保存角色、依赖等附属模型～item．toOWLO；)Individualinst2owlmodel．createlndividual(baseUd+W‘+org．getGUlD0，owlmodel．getOntClass(aomgbaseUd+'／f'+"aomg_Organization”)：，．设定组织模型的guid、名称等属性¨RDFDatatypeGUIDType2typemappeLgetSaf；eTypeByName(mgr．getURIForPrefix(”exd“)+"#GUIDType”)：OatatypePmpertyccid=m．getDatatypePropefq(mgr．getURIForPrefix(。aomg’)+"#GUlDTproperty'‘)；inst．addPmperty(ccid．owlmodel．createTypedLiteral((String)grole．getGUID0．GUIDType)．getValueO)；RDFDatatypeGUIDType=typamapper．XSDName；DatatypePmperlqccid=m．getDatatypeProperty(mgr．getURIForPrefix(”aomg。’)+”#namepmperty。’)：inst．addPmperty(ccld．owlmodel．createTypedLiteral((Stdng)grole．getGUID0，GUlOType)．getValue0)；5．5小结本章讨论了AOMGToolkits建模环境的基本功能框架，以及元模型设计与模型数据存储技术，系统在Eclipse平台[105]上以Java得以实现。目前AOMGToolkits达到了以下效果：1)在环境中提供模型导航功能，允许开发者全盘浏览已经建立的所有视图和模型，并指导设计人员正确使用各种元模型，搭建可视化、直观的系统抽象原型(如系统组织模型、角色模型和Agent交互模型)，实现不同级别的细节显示或隐藏。环境同时还提供图表输出 上海大学博士学位论文功能，以便将需求分析结果引入到文字处理文档或Web页面中。2)实现了系统模型数据的基于OWL文件的存储，模型文件作为设计成果实现了网络共享、分析和转换等服务功能。3)提供了基于元模型层次的模型变换工具，提高了建模的效率和准确性；同时还提供了基于OWL的模型分析工具。4)提供相应的模型语法正确性检测机制，保证所得到的AOMG图形模型符合其语法定义，见第六章；5)采用基于OWL推理的模型一致性检查方法003]，AOMG建模环境实现了三种保证模型一致性的策略：●强制约束：对用户实施的编辑操作在某种程度上进行限制，使建模者只能在系统规定的范围内有选择的进行编辑，从而避免了不一致编辑操作的出现。·自动维护：当用户实施了可能引起模型不一致的编辑操作后，系统可以自动修正。·动态检查：实时地捕获引起模型不一致的编辑操作，给出错误原因和修改建议。6)系统采用Java语言设计开发，由于Java语言是一种与平台无关的编程语言，因此建模环境可以运行于包括MSWindows、Unix、Linux等目前流行的大多数平台。 f．海犬学博士学位论文第六章AOMG模型语法检测机制在软件开发过程中，概念模型的正确性是软件产品质量的基本保障，唯有正确的概念模型才能真实反映客观世界。概念模型的正确性有三方面的含义：语法的、语义的和语用的。为保证所在建模环境中得到的AOMG图形模型符合其语法定义，为模型的语义一致性检查奠定良好基础，环境应当建立语法正确性检测机制。一种方法是提供语法制导，在模型的建造过程中提供动态的语法提示；另一种方法是提供元模型语法检测功能，及时对用户建立的模型施加验证。这样既可方便用户学习和使用，也可保证所建造的模型在语法结构上的正确性。本章介绍了AOMG元模型的语法检查机制，详细论述了如何将模型语法约束影射为模型描述类的刻面约束，从而使用KBeans[106]软件包来完成自动检验功能。6．1概念模型的语法检查机制实现软件过程自动化的动因是需要改进工作质量、提高生产效率。当把一项任务简化成固定的程序并使之机械化时，我们不仅节省了人力，而且从根本上避免了人为的错误，这正是提高生产率的最佳途径。卡内基梅隆大学的软件工程研究所对各种软件工具的潜在作用进行过研究，他们发现，清除错误原因能使生产率得到最大的提高。这是一条普遍适用的规则：极大的生产率改进来自于避免错误，而不仅是有效的执行任务。在AOMGToolkits建模环境中，我们采用模型语法约束机制来避免建立错误的模型。6．1．1概念模型语法约束概要FormalAOMG形式化建模框架精准的给出了元模型的语法约束，而用来描述用户系统的层次模型在语义上则是AOMG元模型的实例，因此语法检查的主要目的是要检查用户模型是否遵守元模型的规格描述。图6．1依赖模型的语法约束 上海大学博士学位论文从形式化建模框架中，可以析出AOMG各种概念模型语法规则(如图6．1是AOMG依赖模型的语法约束)。其大致可分为以下几类：(11有效值或有效类型约束：例如，operation、attribute元模型的visibility属性的有效值必为private、public和protected，而node元模型的type属性的有效类型为gridagent、component、datebase这三种。(21数量约束：例如，实体(entity)模型至少要有一个attribute属性。(3)属性关系约束：例如，在依赖模型中依赖者属性和被依赖者属性不能相同；在行为依赖(actiondependency)中则要求依赖行为应包含在被依赖者而非依赖者的能力fcapabilities)集合属性中。(4)集合类型约束：例如，实体模型的“name”属性、网格Agent的“GUID”属性在系统内应当是唯一的。Operation元模型的‘'parameters”属性要求各个“parameter”是有续的。(5)默认值约束：用来自动设定属性的初始值，或者修复属性无效值。例如网格GridAgent的mobility属性默认值为庙厶P。(6)文字格式约束：指出特定属性的文字描述方式。例如GridAgent的GUID属性是由最小长度为8的数字串组构成。对于第一种约束，我们当然可以提供动态的语法制导，在模型的建造过程中提示用户选择有效值或有效类型的对象，保证所建造的模型在语法结构上的正确性。但是，如果要保证角色模型的capabilities属性其对象为action类型，用户输入的属性对象类型可能还未定义过，这样就无法通过简单的语法导航给用户提供有效的选项，如果仅仅提供指导信息，则很难保证用户输入的正确性；而且，语法制导的方式需要涉及模型逻辑、显示等模块，如果都为之开发相应的检查方法，工作量相当巨大的；最后，考虑到AOMG方法还处在研究阶段，建模环境必须能够引入新的模型(如，为node的type属性添加新的有效值)，允许动态改换模型的语法约束(capabilities属性引用对象改为task类型1，这就要求该语法检查机制具有良好的扩展性。6．1．2语法约束的细化通过进一步的分析，我们可以将上述样式的语法约束总结为表6．1所列出的几种模式，或称为刻面(facet)，每个刻面被赋予一个名称和事先定义的意义。通过刻面可规整的对模型信息进行约束，并以之作为描述元语，覆盖所有的语法约束。描述模型的一组刻面称为刻面描述子(facetdescriptor)。我们可以用有限维信息空间的术语组合，从若干个刻面的综合角度来规约一个模型，每个刻面针对其某一模式的语法约束。 上海大学博士学位论文表6．1AOMG语法约束分类分类刻面类型刻面约柬类型说明例子catal02Facettv鼬FacetvaluetyDeDefaultValueDEFAULT-VALUE给出属性的默GndAgent：：mobilityDEFAULT-VALRestriction认值UE--falseCardinalityCARDINAUTYin“斗=o)数量约柬Dependency：：dependumRestrictionCARDINALITY=1限制每个依赖模型只有一个依赖体MINIMUM-int(>暑0)最小数量约束Agent：：capabilityMINlMUM-CARDINALrrYARDINALITY=I限制每个agent至少有一种行为能力TypeRestrictionVALUE．T1忡ECLASS约束模型属性Dependency=depender的类型V^UJE-TYPE=role；Dependenay：：dependeeVALUE-TYPE=rolellresoureellnode依赖横型的依赖者必须为role,对应被依赖者为role、ref,ource或nodePropertiesNOT-SAME-VAUJSlotchain指定的两个属Dependency：：dependeeRestrictionES性取值不相同NOT-SAME-VALUES=depender依赖模型的依赖者和被依赖者必须相异SUBSET-OF-VALUSlotchain被约柬属性在Servicel)ependeney：：dependumSUBSES指定属性取值ET-OF—VALUES={dependee，services范围中}服务依赖的依赖体应当包含在被依赖者的服务集台中ORT阿OGONAL-OFSlotehain被约束属性不AetionDependency：：dependumORTH．VALUBS在指定屑性取OGONAL·OF-VALUES={depender，值范围中capabilities}ValHeRestrictionVALID．VALUES[】属性的取值范Node：：typeVALID-VALUES=Egrida围gent。component。database]节点的类型属性有效值为gridagent，component，databaseCollection·伽8DUPLIcATE．FREEBool指定属性的每Orgnazation：：rolesRes打iction个引用对象均DUPLICATE-FREE=true组织模型不相同含有的角色各不相同ORDEREDEool指定届性的所Operation：parametersORDERED=tru有％I用对象是e方法模型的参数是有序排列的有序排列的LexcialPa仕emPatternString指出特定属性GridAgent：GUIDPattem=Restdction的文字描述方‘、t、l⋯【-o-91{8，}＼}这里使用perl字符串模式描述了GridAgent的GUID属性是由最小长度为8的数字串组构成6。1。3自动检查机制的实现我们提出的检查机制实现方案是：将AOMG元模型实体影射为相对应的可执行JavaBean类，实体的各种信息映射为Java类的属性，而元模型实体享有的语法约束则可以映射为承载其信息的JavaBean类的属性说明。因此，只需针对每种类型(即刻面)的约束说明分别设计程序，自动检查元模型类实例的属性值是否真正符合上面的说明，汇总甚至修复所有冲突，这样就可以达到保持模型语法约束的目的。J-avaReflectionAPI允许在运行态识别类属性和方法的名称与类型，可以此为基础实现 L海大学博士学位论文统一的算法；JavaBean技术提供了统一接口的可重用类，可用来规范AOMG概念元模型接口，所以JavaBean和Reflection技术是实现刻面约束(facetsrestriction)的关键。另外，KBeans软件包则提供了这样一种搜索、自动检查JavaBean属性的功能，我们可以将其集成到AOMG建模环境中来完成元模型的语法检查功能(如图6．2)。蓄争圄唐等-q国确一；圣图6．2基于KBeans软件包的自动检查机制注：KBeans【106】是由Holger7s等人采用Java语言开发的支持刻面约束的软件包。它通过扩展JavaBeans对对象属性进行刻面声明和处理，提供了描述对象属性的语义元数据。刘面通过采用统一命名规则预定义的字段和方法来实现，并采用面向对象的Reflection技术在运行态来访问这些字段和方法。由刻面提供的元数据可以用来避免、监测和修复无效的对象状态．KBeans支持一系列的刻面类型，可以包含xMLSchema和OKBC等数据格式．因此，KBeans常用于语义归挡、模型约束检查和知识数据的交换，主要应用在本体共享、软件测试和知识获取等领域。关于KBeans更多的介绍以及使用技术可参考[107】。6．2概念模型语法的可执行验证如何在Java程序里实现和访问刻面?一种方法是通过引入外部格式文档(如XMLSchema和OKBC文档)在软件框架里，通过相应的解析器和功能组件提供刻面服务。这样一种程序和外部文档的混合方式，增加了软件维护的难度，违背了软件演化过程的轻装上阵法则(pfincipleoftravelinglight)，因而增加的复杂性会令系统的维护更加困难。其次是依靠建立对象中间层(如DOM树)从外部文件获取Java类对象，这样做虽然比较的灵活，却人为的增加了模型抽象层次。而KBeans软件包却给出了更为自然的解决方案。6．2．1KBeans的刻面定义KBeans软件包设计目标在于进一步挖掘JavaBean的潜在能力，实现领域模型与可执行类对象的平滑转化，支持分布式系统间数据和知识交换。为了在JavaBean对象上实现领域模型的语义约束，它支持对类属性定义若干个刻面(facet)的约束声明(如指定某个类型为．mt的属性的最小值等于O)，使用面向对象的Refleaion技术以在运行态(runtime)来动态提取类、菩重 上海大学博士学位论文属性、方法的约束声明，并调用统一的算法和程序处理类实例。下面列出了KBeans中刻面约束概念的半形式化定义。facet．"．rbean。property。facettype)->facetvaluefacetvalue：．AprimitiveJavavalue，allObject，ornull．facettype：．facetname_>typemappingfacetname：．AJavaidentifierwhichisuniqueamongthefacettypesthatareinstalledintheJavaVirtualMachine．properO，type：．TheClassofproperty．typemapping：．propertyType—’facetvaluetype扣eetvaluetype"TheClassofthefacetvalueornull．constrainttype：．Afacettypewith口validationmethod．validationmethod：．(valuexfacetvalue)—>booleanfacet为JavaBean的某个property声明一个刻面约束值(facetvalue)，如果为空(null)则表明对此property不加约束。facettype则定义了刻预约束值(facetvalue)的类型和含义，每一个刻面类型(facettype)有唯一的名称、属性类型(propertytype)和刻面约束类型(facetvaluetype)。KBeans针对每个刻面约束都定义了一个冲突检查方法(validationmethod)，以propertyvalue和facetvalue做参数，返回该属性值是否遵守刻面约束。表6．2列出了KBeans定义的各种刻面类型，以及与表6．1所声明的刻面类型间的对映关系。表6．2KBeans刻面类型AOMG刻面类型XML-Scham属性类型刻面约束类型Facetn口eAOMGhcetnmequivalentProperty姆DesFaeetvaluetypedefaultValue：DBFAULT-VALUE(type>maxLeagthminLength：MAXIMUMCARDINAI肛Ym强L％曲^otalDigits=O)fractionDigits：MINIMUM-CARDINALnY皿nL∞g吐lint(>卸)maxCardinalityfracfionDigitsfloat+．double+intp=O)minCardinalitymaxLength／maxOc￡urs1]i眦()锄minLength／minOccursr]int(>=0)validClasses：Ⅵ～UJE-1YPE，