基于模型驱动架构的电信业务元模型抽象研究
- 格式:pdf
- 大小:378.01 KB
- 文档页数:10
软件工程中的元模型技术研究随着软件领域的不断发展,软件工程领域也不断涌现出新的技术和方法。
其中,元模型技术是一种重要的技术手段,被广泛应用于软件工程的需求分析、系统架构设计、软件测试等方面。
本文将介绍软件工程中的元模型技术研究,包括元模型的基本概念、元模型在软件工程中的应用以及目前研究中存在的问题和挑战。
一、元模型的基本概念元模型是指对一组对象的抽象描述,包括这些对象及它们之间的关系和约束条件。
元模型可以看作是对现实世界的一种抽象,它能为软件工程中的分析、设计、开发、测试等工作提供一种统一的语言和框架。
元模型的实现通常需要使用模型驱动开发(MDD)和模型转换技术,将抽象的元模型转化为具体的软件系统。
元模型的建立包括以下步骤:1.定义元模型的范围和目标:选择元模型的应用领域,明确描述元模型的主要目标和目的,确定使用的元素和关系类型。
2.识别元素和关系类型:识别在元模型中需要描述的各种元素和它们之间的关系类型,包括类、属性、操作、数据类型、关系等。
3.定义元素的属性和行为:为每个元素定义相应的属性和行为,包括数据类型、默认值、编辑方式等。
4.定义元素之间的关系:为元素之间的关系定义相应的关系类型和约束条件,包括继承、关联、聚合、组合等。
二、元模型在软件工程中的应用元模型是软件工程中的一种重要工具,它能够为软件开发提供一种建模和描述的方式。
在软件开发中,元模型主要应用于需求分析、系统架构设计、软件测试等方面。
1.需求分析:元模型可以帮助软件工程师更准确地理解用户需求,并将这些需求转化为相应的软件模型。
在需求分析阶段,通过建立元模型,可以更好地理解系统功能、数据、服务等。
2.系统架构设计:在系统架构设计阶段,元模型可以用来描述系统中各个组件之间的关系和交互方式。
通过建立元模型,可以清晰地描述软件系统的组成部分和它们之间的关系,并用于系统架构评估和优化。
3.软件测试:元模型可以帮助测试人员更好地理解软件系统的功能和结构,并根据元模型定义的约束条件生成测试用例。
什么是金蝶EAS BOS?BOS,Business Operation System,业务操作系统,是金蝶融合多年的企业应用软件的经验以及MDA 理念研发新一代技术平台,是金蝶公司全新的管理软件开发工具和管理集成平台。
金蝶BOS提供了基于模型驱动架构(MDA)的开发模式和相关的工具,成功的解决了企业应用软件在开发、实施和维护过程中的质量、周期、成本、风险等方面的问题,并使企业应用软件能够满足企业管理行业特性、企业个性化和持续完善的要求,对于企业应用软件在行业应用开发和维护、实施带来了全新的应用模式和革命。
金蝶EAS BOS提供的集成管理平台,使企业应用可以集企业门户(Portal)、办公自动化(OA)、企业资源管理(ERP)、工作流(Workflow)以及业务重组(BPR)于一体,对于企业的团队协作、业务支持、管理控制、决策分析、商务智能以及企业信息实时化提供全面的支持。
金蝶EAS BOS,集中体现了金蝶公司对中国特色化企业管理和国际先进管理思想领域的孜孜不倦的探索和追求,融合了金蝶公司在企业应用软件领域十多年的行业经验和软件开发经验,对产品不断的发展与完善,为企业用户带来高效、灵活、柔性以及功能强大的企业管理系统,帮助企业用户在激烈的市场竞争中赢得先机并获得前所未有的高回报。
金蝶EAS BOS的基本思想p金蝶EAS BOS体系的基本实现思想可以简单描述为:基于企业应用环节来设计软件企业应用软件的开发过程是一个庞大的系统工程,其中涵盖了业务需求规划、系统设计、程序开发、软件测试等多个环节。
金蝶EAS BOS该系统工程中各个不同的受众提供了相应的服务和工具,使得各个环节只需要关心自己领域内的工作而不需要付出更多无谓劳动,金蝶EAS BOS提供的服务和引擎又能够保证各个环节的衔接,从而使得整个系统工程是一个完美无暇的整体。
基于企业模型来设计软件企业应用软件最终都是要为企业的实际应用管理提供服务的,因此企业应用软件必须基于企业的实际业务流程以及业务模型来构建企业应用系统。
附件4:UAP介绍一、UAP简介UAP(Universal Application Platform)平台是用友软件经过多年的技术积累和知识沉淀,在微软.NET相关规和标准的基础上,提供完全支持基于领域语言(DSL)的模型驱动开发(MDD)模式,为各种复杂的企业级商业应用系统提供专业、安全、高效、可靠的开发、部署和运行企业管理应用软件的开发工具平台。
通过UAP平台,使企业信息资源变得可重用、透明化,并且系统具有高可扩展性,让业务处理更加高效、简洁、安全。
UAP平台为用户提供了一个统一的集成开发环境,用户可以使用包括模型设计、UI设计、报表设计、规则设计、数据库设计、BI设计等各方面的设计器,并通过可视化的界面和友好的交互操作,自动生成用户所需要的各种功能控件。
使得大型的企业级商业应用软件第一次实现了技术与业务关注点的分离,并且通过快速的动态业务建模与服务组装技术,实现了企业动态业务的快速部署与应用,真正实现了“随需而变”的实时企业与全球商务的企业信息化价值理念。
1.1 UAP的目标作为开发工具平台,UAP需要实现与操作系统、数据库、.Net Framework、Office、WMI、.Net Compact Framework、MSMQ等底层核心技术的调用与协作,通过屏蔽底层的复杂实现,提高企业应用软件的灵活性、可扩展性和开放性。
作为应用设计平台,UAP提供了统一的集成开发环境,其中包括模型设计、UI设计、报表设计、规则设计、数据库设计、BI设计等各方面的设计器,通过可视化的界面和友好的交互自动产生需要的各种软件工件,极提高了软件开发的效率和质量。
作为运行执行平台,UAP在系统交付、安装和部署后,支撑业务系统的解析和执行;提高应用软件的可定制性与可集成性。
作为集成平台,UAP提供对OFFCIE、移动商务、第三方软件系统等企业级的集成与应用协同。
作为管理平台,UAP通过使用权限管理、EAI、数据库管理等管理工具实现对业务系统的调整和控制。
领域驱动设计业务建模与架构实践1.引言领域驱动设计(D oma i n-Dr iv en De si gn,简称D DD)是一种以业务领域为核心的软件设计方法论,通过深入理解业务领域的本质和规则,将业务知识融入软件设计和开发的过程中。
本文旨在介绍领域驱动设计的概念与原则,并探讨在实际项目中如何进行业务建模与架构实践。
2.领域驱动设计概述领域驱动设计是由Er i cE va ns于2004年提出的软件设计方法论,其核心思想是将软件设计的重点从技术转移到业务领域上。
D DD通过与领域专家密切合作,共同理解业务知识和业务需求,并将其转化为可执行的软件模型。
通过将业务领域划分为多个子领域,DD D强调每个子领域的独立性和自治性,从而提高系统的灵活性和可维护性。
3.领域建模领域建模是领域驱动设计中的基础工作,通过对业务领域的分析和理解,建立起业务模型。
领域建模主要包括以下几个步骤:3.1.识别核心领域首先,需要识别出业务系统中的核心领域,即对业务成功至关重要的领域。
通过与领域专家的交流和分析,确定出主要的关键领域,并明确其范围和边界。
3.2.拆分子领域将核心领域进一步拆分为多个子领域。
每个子领域应该具有清晰的边界和自治性,既能够独立于其他子领域进行开发,又能够通过定义好的接口进行交互和合作。
3.3.建立领域模型在每个子领域中,通过领域模型的方式来描述业务中的概念、实体、关系和业务规则等。
领域模型是对业务领域知识的抽象和表达,它能够清晰地反映业务领域的本质和规则。
3.4.持续迭代优化领域建模是一个持续迭代的过程,随着对业务领域理解的不断深入和新需求的出现,需要对领域模型进行不断优化和演化,确保其与业务实际情况的一致性。
4.领域驱动设计架构实践领域驱动设计的架构实践是将领域模型转化为现实的软件架构,以实现系统对业务领域的支持和扩展。
4.1.领域服务通过将业务逻辑封装在领域服务中,我们能够更好地实现业务领域的自治性和独立性。
模型驱动架构MDA浅述模型驱动架构(MDA,Model Driven Architecture)浅述袁峰 2007年7月10日前言西西弗斯是古希腊神话中的科林斯国王,他被罚将一块巨石推到山上,但无论西西弗斯如何努力,每次石头到达山顶之前都不可避免地滚下来,周而复始,永无休止。
前言西西弗斯是古希腊神话中的科林斯国王,他被罚将一块巨石推到山上,但无论西西弗斯如何努力,每次石头到达山顶之前都不可避免地滚下来,周而复始,永无休止。
在《应用MDA》一书中,作者Frankel将IT人比作现代版的西西弗斯,面对日新月异层出不穷的技术平台,不可避免地不断重复一些工作。
理想的MDAer,试图阻止这一悲剧的继续发生。
今天,我们通过分析MDA的概念,了解其内涵,看看MDA是否有希望完成这个艰巨的任务。
定义MDA是由OMG(Object Management Group,国际对象管理集团)[1]于2001年提出来的。
其核心思想是抽象出与实现技术无关、完整描述业务功能的核心平台无关模型(PIM,Platform Independent Model),然后针对不同实现技术制定多个转换规则,通过这些转换规则及辅助工具将PIM 转换成与具体实现技术相关的平台相关模型(PSM,Platform Specific Model),最后将经过充实的PSM 转换成代码。
通过PIM和PSM,MDA的目的是分离业务建模与底层平台技术,以保护建模的成果不受技术变迁的影响。
图1 MDA结构示意图[1]图1为MDA的结构示意图。
最内环是MDA的核心技术:MOF(Meta Object Facility,元对象设施)、CWM(Common Warehouse Metamodel,公共数据仓库元模型)和UML。
MDA的主要工作就是要把基于这些技术建立的PIM转换到不同的中间件平台上,得到对应的PSM。
中间环上给出的是目前主要针对的实现平台:CORBA、XML、JAVA、Web Services和.NET。
基于模型驱动架构的电信业务元模型抽象研究1冯跃忠北京邮电大学网络与交换国家重点实验室,北京(100876)E-mail:yzfeng1981@摘要:模型驱动架构(MDA)业务生成技术是新一代的软件开发方法学。
在深入分析基于模型驱动的电信业务生成后,文章以SIP Servlet平台为例,给出了一种SIP Servlet平台上的元模型抽象方法,并利用UML Profile的扩展机制在MDA工具上加以实现,实验表明,在SIP Servlet平台上采用此方法抽象的元模型是正确可行的。
关键词:模型驱动架构,元模型抽象,业务生成,SIP Servlet平台中图分类号:TN9111.引言模型驱动架构(Model Driven Architecture, MDA)是对象管理组织(OMG)在2002年初确定的战略方向。
在过去的几年中MDA技术取得了很大发展,被应用到诸如电信、航空航天、银行以及医疗卫生行业。
作为一种新的业务生成方式,MDA越来越受到人们的关注。
将模型驱动技术引入到电信领域,用于新一代电信业务生成具有重大意义。
基于MDA的电信业务元模型抽象是模型驱动业务生成技术的重要研究课题之一。
如何抽象出正确且能够覆盖所有电信业务能力的元模型需要深入研究。
文章给出一种基于模型驱动架构的电信业务元模型抽象方法,并以SIP Servlet平台为例给出抽象的元模型实例。
2.基于模型驱动架构(MDA)的业务生成技术2.1 MDA概念MDA定义了开发IT系统的一个标准,使系统功能与功能的实现相分离。
最显著的特点是,该标准把关注点放在模型上,模型不再仅仅是描述系统,辅助沟通的设计工具,而是软件开发的核心。
MDA把建模语言当作编程语言来用,把软件开发的关注点从代码实现转移到设计和建模上来。
MDA的核心理念是一切以模型为中心,模型是MDA关注的焦点。
其最终目标就是使模型可执行。
MDA方法在开发过程中提供了更高层次的抽象,其在平台无关模型(PIM)与平台相关模型之间(PSM)的松耦合关系意义十分重大。
模型是以精确定义的语言对系统(或系统的一部分)做出的描述【6】。
在MDA中建模(描述问题)和模型映射技术(转换问题)是其核心,其技术基础为:统一建模语言(UML)、XML元数据交换(XMI)、元对象设施(MOF)、公共仓库元模型(CWM)。
在某个企业应用MDA方法,其实质就是创建一个新的特定领域的MDA描述语言集,该语言集由某种面向对象建模语言(如UML)的标记组成,比如由几个UML Profile组成的、可以由终端用户使用的集合。
所以,MDA方法的核心在于用某种标准的建模语言建模,进行模型之间的转换,从而自动生成代码,提高软件的开发效率以及可重用性。
MDA方法的概念模型是开发的基本脉路,如图1所示。
1本课题得到国家自然科学基金项目(60672122)资助。
图1 MDA的概念模型图2.2 MDA的优势基于模型驱动的软件体系结构,将系统的功能规范与系统在特定平台上的实现分离,使得该体系结构能保持对编程语言、中间件平台、产品厂商的中性。
这种方法的好处是:可方便地将现有的系统、正在建造的系统以及今后可能建造的系统在不同的中间件平台上进行集成,提高系统之间互操作、互移植的程度,使系统在不断变化的软件基础设施面前保持灵活性;同时,可延长软件的寿命周期、降低维护费用等。
另外,模型严格的形式化语义定义可提高系统的质量,也有利于提高系统开发的自动化程度。
总而言之,MDA能够带来大幅度的生产效率的提高,更好的可移植性,更好的互操作性,同时关键的是能够带来模型在应用级别的重用。
用户只需要搭建具有高度抽象的业务平台无关模型,选择不同的实现平台,就能将这些模型映射到不同的平台。
3.MDA的建模标准—UML概述3.1 UML概述UML(Unified Modeling Language),统一建模语言,是开发软件系统时,规范化,可视化,创建并编制相应文档的标准。
UML是八十年代出现的各种面向对象语言(如OMT,BOOCH)的优点整合的结果。
对所有使用面向对象和组件方法来开发的系统而言,UML都可以被作为一种通用的建模语言,它也可以在所有的应用领域和实现平台上应用。
它在业界的地位就像英语在国际交流场合的地位一样,是软件架构师以及软件工程师们交流与沟通的工具,具有明显的图形化,规范化,可视化等优点。
3.2 UML 扩展包(Profile)概要UML Profile包以核心包为基础,它定义了一个构造型化的包,通过UML的扩展机制定义了一个元模型子集而使UML具有描述某个特定领域的丰富语义。
这种扩展机制以UML 为基础,制定了一些领域相关的元素,而并不改变原有UML元素的语义,属于“轻型扩展”。
在常用的建模工具和方法论中,对UML Profile方法来自定义Stereotype以扩展UML建模能力的应用处处可见,比如Rose中的许多对象都是Rational自己定义的Stereotype。
UML Profile扩展的基础是UML的元素,然后给这些元素的一些变形加上新的语义。
新的语义可以有三种形式:重新定义,增加新的,或者对某种元素的使用增加一些限制。
UML有三种扩展其核心的机制:①版类。
它是一种附加在已有模型元素上的语义,如果版类附加于某种元素,则覆盖该元素的语义,该元素就成为一种新的元素。
典型的版类如为类定义的元类(Metaclass),为包之间的相关关系定义的导入(Import)等。
在这种情形中,版类在原来的元素(类或相关关系)中增加了新的或另外的语义。
UML中自带了许多从核心扩展出来的常用的版类可以直接来使用。
②加标签值。
是附属于UML元素的性质,版类中的属性可以看做为标签,其值即为标签值。
③约束。
是UML中限制一种或多个元素语义的规则。
约束可以附加在类或对象上,并且经常附加在关系上。
3.3 UML元模型四层概念架构当定义语言的架构层次时,通常考虑的是以下三层模式:①语言的规范,元模型;②用户规范,模型;③模型的对象(实例化)。
这种结构可以递归的应用多次,于是就得到了不计其数的模型的层次,一个模型在某种情况下是元模型,在另一种情况下也可能作为模型,在UML和MOF中,这种现象是很常见的。
UML这种语言规范允许用户定义自己的模型。
同样,MOF也是允许用户自己定义模型的一个语言规范,从MOF的角度来看,UML是它的一个使用,即UML是基于MOF的一个语言规范。
在UML语言的四层元模型层次中,MOF通常被看作元元模型。
元元模型层是建模层次的基础,这一层的主要作用是定义一个元模型。
这层通常被称为M3,MOF就是这一层的一个例子。
元元模型通常要比它描述的元模型简单,并且会定义几个元模型。
通常,元模型以及它相关的元元模型要共享公共的架构和原理。
尽管如此,也可以把各个层次分开来考虑,需要分别来保持每一层次的完整性。
一个元模型是一个元元模型的实例化,这就意味着元模型中的每一个元素都是元元模型中的某一个元素的实例化。
元模型的主要功能是定义这门语言的一个模型。
这个层次通常被称为M2,UML和CWM (Common Warehouse Metamodel)都是元模型的一个例子。
一般来说,元模型比定义它的元元模型要复杂,尤其是当它定义动态语义的时候。
UML元模型就是MOF的一个实例化。
模型是元模型的实例化。
模型的主要功能是作为描述某个领域内语义的一种语言,允许用户为不同的问题域建模,如软件,商业,需求等。
这层通常被称为M1。
用户模型是UML元模型的一个实例化。
注意的是,用户模型包含了模型元素以及模型元素的注释。
元模型概念层次的最下层是M0,这一层包含的是模型中定义的模型元素的一个实例。
M1层的注释在M0层变成了约束。
UML四层概念架构图如图2所示[1]。
图2 UML四层概念架构图4.基于模型驱动的电信业务描述方法4.1 基于MDA的电信业务元建模概述描述和识别描述进行转换是基于MDA开发方法中的两个主要问题,元建模实现了特定领域的描述。
电信业务元建模的任务是提供一套特定领域的描述语言,该语言完全是功能层次上的描述,与具体接口、实现技术完全分离,在模型驱动的电信业务生成过程中,用该预先定义的电信业务描述语言建模各种电信业务的PIM层模型。
其中,分析特定电信领域的特点,研究创建电信领域元模型的架构,抽象设计元模型的具体业务元素以及如何灵活使用,是元建模者必须考虑的问题。
首先明确电信领域元建模要达到的2个目标:①配合使用UML 核心包元素,能够明确描述电信领域各种复杂多变的业务逻辑;②给模型转换提供足够的标记去定义规则,以支持模型到模型或模型到代码的自动转换。
该点是在模型驱动的背景下,通常的UML元模型建模所增添的理念【7】。
4.2 模型驱动业务生成策略根据MDA的理论,结合未来电信业务网络结构和业务的特点,提出了开发电信业务的一种全新的方法[2,3,4],如图3所示。
基于MDA的电信业务开发首先要创建需求分析模型(CIM);第二步,将电信业务的功能从下层的网络实现技术中抽象出来,创建电信领域相关的扩展元模型,包括电信特征元模型,通用支撑功能元模型,非功能特性(QoS)元模型;第三步,使用电信领域相关元模型创建平台无关的业务模型(PIM);第四步,首先定义特定平台,协议接口和实现语言的映射规则,例如抽象OSA/Parlay的平台接口模型。
然后,完成PIM到平台相关模型(PSM)的转换。
上述PIM和PSM的建立是一个不断求精(从分析到设计)与转换的过程。
最后是PSM到代码的生成、测试和部署运行。
图3 模型驱动的电信业务生成策略5.SIP Servlet平台上的元模型抽象5.1 SIP Servlet平台概述SIP Servlet可以扩展SIP服务器的功能、控制SIP消息的处理,从而实现更为丰富的SIP 业务。
SIP Servlet是一种基于组件与容器的设计架构,在此框架中,SIP应用是在应用服务器(即容器)内运行,并且受到应用服务器控制管理的组件。
由于容器提供了大量的可利用的基础功能,应用开发人员只需要考虑上层的商业应用服务如何实现,从而简化了应用开发的工作流程,提高了效率。
SIP Servlet 应用服务器的核心是SIP协议栈。
应用服务器负责接受和发送SIP消息,管理SIP对话和事务,实现SIP的核心语义。
当SIP服务器收到消息时,服务器会调用相应的SIP Servlet应用,同时SIP Servlet应用也会调用Servlet服务器来发送消息。
图4是一个简单的SIP Servlet基本模型示意图。
图4 SIP Servlet基本模型示意图以模型驱动(MDA)的方式来开发下一代电信业务,SIP Servlet平台是一个开放接口技术的业务生成平台,在MDA框架中,该平台上所有模型被称为平台相关模型PSM,所有元模型都是与平台的具体细节相关的。