U9-UBF应用开发手册.doc
《U9-UBF应用开发手册.doc》由会员分享,可在线阅读,更多相关《U9-UBF应用开发手册.doc(563页珍藏版)》请在咨信网上搜索。
1、用友U9-UBF应用开发手册V2.5前言UAP(Universal Application Platform)是用友公司为开发新一代面向服务(Service-Oriented Architecture, SOA)的世界级商业应用套件产品(U9)而精心打造出来的ERP软件生产平台。通过UAP平台,使企业信息资源变得可重用、透明化,并且系统具有高可扩展性,让业务处理更加高效、简洁、安全。UAP平台为用户提供了一个统一的集成开发环境,用户可以使用包括模型设计、UI设计、报表设计、规则设计、数据库设计、BI设计等各方面的设计器,并通过可视化的界面和友好的交互操作,自动生成用户所需要的各种功能控件。使得
2、大型的企业级商业应用软件第一次实现了技术与业务关注点的分离,并且通过快速的动态业务建模与服务组装技术,实现了企业动态业务的快速部署与应用,真正实现了“随需而变”的实时企业与全球商务的企业信息化价值理念。UAP(Universal Application Platform)平台是用友软件经过多年的技术积累和知识沉淀,在微软.NET相关规范和标准的基础上,提供完全支持基于领域语言(DSL)的模型驱动开发(MDD)模式,为各种复杂的企业级商业应用系统提供专业、安全、高效、可靠的开发、部署和运行企业管理应用软件的开发工具平台。它主要包括:应用运行平台(UBF)、应用开发平台(UBF Studio)和组
3、件化发布平台。 UBF(UFIDA Business Framework)实现与操作系统、数据库、.Net Framework、Office、WMI、.Net Compact Framework、MSMQ等底层核心技术的调用与协作,通过屏蔽底层的复杂实现,提高企业应用软件的灵活性、可扩展性和开放性。针对开发ERP软件的特点,提供了一套适用的类库、框架以及具有扩展性的通用解决方案。有效地降低了开发工作的难度和工作量。在系统交付、安装和部署后,支撑业务系统的解析和执行;提高应用软件的可定制性与可集成性。提供对OFFCIE、移动商务、第三方软件系统等企业级的集成与应用协同。 UBF Studio提供
4、了统一的集成开发环境,其中包括模型设计、UI设计、报表设计、规则设计、数据库设计、BI设计等各方面的设计器,通过可视化的界面和友好的交互自动产生需要的各种软件工件,极大地提高了软件开发的效率和质量。提供对完整产业链的全角色开发的支撑环境。 组件化发布平台提供软件产品的组件规划工具,以定义软件产品的工艺图。自动化构造工具将依据该工艺图,自动地构造组件并存入组件库中。安装系统生成工具将按照用户的意图从组件库中提取适当的组件产生安装包。在本手册中我们将详细介绍怎样使用UAP中的UBF和UBF Studio开发应用。UBF概述UAP平台与应用系统间的整体逻辑架构UAP平台是在国际上主流和公认的技术标准
5、与规范的基础上建立的一个开放的企业级开发工具平台。它采用了元数据驱动的、面向服务的体系架构,并提供了统一的编程抽象模型,是一个适合应用软件开发及部署的全角色平台。UAP平台与应用系统之间的逻辑关系与整体架构如下图所示。其中,UAP平台提供了模型定义、服务组装、应用开发集成环境(UBF Studio)、应用平台以及应用工具等五个核心的工具集。并通过这五大工具集为应用系统以及第三方的其它应用提供统一的模型定义、功能开发与应用集成的环境。UAP平台的技术体系架构UBF的技术体系结构采用分层的架构模式,主要可以分为数据层、业务层、表示层,并且通过抽象的控件模型提供对多种客户端的应用支持。整个架构如下图
6、所示:其中,在数据层中,持久化服务引擎主要负责访问和查询存储在数据库中的各种业务数据,在隔离业务层和数据存储管理的同时,实现与业务层的实时交互。持久化服务的这种隔离有以下好处:减少数据库提供者变更带来的影响;减少因数据对象变更带来的影响(如变更数据库的schema);封装数据的处理操作,这将在很大程度上减少测试和维护工作;通过O/R映射机制,以维护对象和持久存储之间的一致性,减少因面向对象和非面向对象这两种技术存在着阻抗不匹配。在业务层中,业务实体对象封装了一个业务中的元数据、存储过程和触发器以及该业务的规则、过程或事件。业务实体对象是业务中实际存在的事物或概念,是对“ER”模型中概念的面向对
7、象的扩展。业务实体对象负责执行包括强制的业务规则、应用规则、数据有效性、并发和存储等所有方面的内容。且多个独立的但有关联关系的业务实体对象可以一起协作来完成一个应用,完成不同的任务需执行很多具有不同特点的业务实体对象。而业务服务则可以定义为一段独立的逻辑程序,当多个服务组合在一起时可完成不同类型的业务需求。服务描述了贯穿业务的工作流程和信息,同时对业务逻辑进行了封装,实现了对业务实体对象的操作,并驱动业务实体完成业务功能。服务可以由工作流系统、业务实体对象管理器、面向对象语言或交互过程定义系统实现。通过UDDI服务网关来查询、绑定内部或外部相应的服务或应用,并调度相应的一个或多个业务实体对象来
8、实现业务处理。而业务流程对象封装了业务处理与业务策略过程。例如,一个定单处理工作流组件可能结合客户、定单等业务实体对象完成定单处理的工作流程。在表示层中,通过MVC的模式建立业务模型、视图以及控制器之间的业务连接,并实现对各种客户端界面(包括基于浏览器的WEB应用方式、用户交互的窗体以及Smart Client等应用方式)的支持。每个窗体用来显示系统提供的信息以及传递用户的输入信息。这种基于窗体的用户界面包括两种类型的组件:用户界面组件: 基于.NET Framework的组件,包括Smart Client组件和Web Form组件,还支持用户基于.NET Framework定制的组件。用户界
9、面处理组件: 复杂的用户界面通常需要很多非常复杂的窗体。为了提高其可复用性、可维护性和可扩展性,需要创建分离用户界面处理的组件,以封装窗体和界面导航之间的相关逻辑。可以对一个窗体中组件之间的依赖、确认和导航应用相同的概念。这些UIP组件通常是一些基于诸如:Front Controller, Application Controller等设计模式的定制组件。UI和UIP组件之间的交互通常采用MVC模式。另外,UBF技术体系架构中还包含基础服务层:即提供其它所有层都能使用的一系列基础服务。这些服务分成三类: 安全:提供与应用和系统安全相关的服务集合; 执行控制管理:这些服务负责管理组件或服务以及相
10、关的资源,还负责处理容错和可扩展性等操作和控制的需求; 通信:提供组件或服务之间的通信,包括.NET Remoting、SOAP、同步或异步消息等服务。UBF领域模型语言(DSL)为了提供对模型驱动的软件开发技术的有效支持,UBF台提供了一种领域特定语言(DSL),其中包括了业务领域语言、表单领域语言、流程领域语言以及报表领域语言等。并针对不同的领域语言采用不同的模型化以及组件化的生成方式,例如通过业务领域语言,可以有效地建立实体模型、数据模型以及服务模型,并且根据模型的关键属性与特征生成相应的软件组件。通过多种模型生成的各种相关的软件组件在应用组装语言的支持下实现动态组装,从而快速形成一个完
11、整的应用系统。其中: 版型是扩展业务实体定义的描述方法,是对业务对象进行分类识别的工具,主要用来对业务模型进行抽象,找出实体间的公共属性;每个版型可附带一个代码片段作为模版,根据业务需要由设计人员动态创建,在实体定义阶段进行引用。通过设置版型,对实体进行标识,从而易于识别,并可基于版型进行分类。比如:帐表类实体等树形实体,可通过建立版型进行识别。 特性可在不同实体间复用的属性集和版型集;可复用的属性集和版型集通过实体转存为特性,在维护实体属性和方法的时候通过引用特性引入已保存的特性。 模式: 可在不同组件间复用的实体集,以及实体间的关系。实体模型实体模型用于描述业务数据的结构和关系。实体模型族
12、中包括实体组件、实体、属性类型、数据传输对象、动态枚举、异常、实体校验器、事件和关系。其中关系分为继承、组合和关联。实体组件实体组件与软件行业通常所说的组件的概念并不相同,实际是用于描述一组具有强依赖关系的实体的边界。在一个实体组件内仅能有一个主要实体及其组合的实体。UBF的持久化引擎使用实体组件的元信息以保证实体组件内主实体与其组合实体的生命周期的一致性。实体实体模型用于开发者定义应用的数据模型。实体模型中包括属性和方法。实体分为主实体和非主实体,其中只有主实体才能组合非主实体,而不能被组合。在实体模型上需要指定实体在数据库上存储时的数据库表的表名。如果该实体继承于其他实体,还需要指定这种继
13、承关系在数据库上的存储方式,目前UBF仅支持单表继承即基类的数据也将存储在具体的实现类对应得表中。为了优化实体数据的加载和保存效率,开发者还应当在实体上建立一个索引项,并仔细地规划索引项中应当包含的实体的属性和次序。实体模型上还有用于通用查询服务的标志,如果开发人员设置了该标志,则通用查询服务将可以展现该实体的数据。如果开发者设计了一个仅用于继承的抽象实体,需要设置抽象类标志。实体的属性实体属性是关于实体中数据项的描述模型。它的基本信息包括名称、类型、显示名和缺省值。实体属性模型中有一组关于校验的信息用于持久化引擎对数据的合法性进行校验,如可空标志、只读标志、字符串的长度以及数值类型的值范围等
14、。实体属性模型中与持久化有关的信息包括业务主键、一旦使用不可修改、国际化、是否敏感日志字段。其中如果声明为业务主键则该属性将成为该实体的唯一约束的一部分,只有当实体对象上所有业务主键属性的值组合没有重复时,该实体对象才能成功地增加。国际化用于指定字符串类型的属性是否支持多语编辑和保存。一旦使用不可修改标志用于类型为其他实体引用关系,被设置后表明该实体对象所引用的其他实体对象将不能被修改。是否敏感日志字段标志用于指定该属性的改变是否做系统得变更记录。实体属性还可以被指定为计算列,并能定义计算表达式。计算列不会被存储到数据表中。关联实体可见和服务可见标志用于指定属性的可见性,只有被设置的属性才能被
15、关联实体访问或作为服务的参数。而查询属性标志则,表示该属性是否可以被通用查询服务所展示。实体上可以指定任意数目的可开发者设计的校验器,以保证业务数据的合法性。实体的方法实体方法是关于实体中行为的描述模型。开发者除了可以指定名称、显示名称和返回值类型等基本属性外,还可以指定可见性如public、protected等,以及静态、虚方法和重载方法。实体的方法模型上可以声明任意数量的异常,以表明该方法将可能抛出这些业务异常。实体的版型开发者可以为实体指定一个或多个版型。属性类型属性类型是一种没有独立生命周期的特殊实体。它可以有属性和方法,但没有校验器。属性类型模型没有持久化相关的信息,不能被持久化到独
16、立的表中。它的数据只能被存储到使用它的实体的表中,相当于嵌入在实体中的复合数据。数据传输对象数据传输对象是可以远程传输的特殊实体。但不能被持久化到数据库中。在数据传输对象中其属性的类型如果是实体类型,则应当指定是实体的类型本身还是实体Key类型。通常应当指定为实体Key类型。动态枚举动态枚举是一种既可以在设计期指定枚举值,也可以在运行时动态增加枚举值的数据类型。实体校验器、事件和异常用于定义实体的业务校验器和业务异常信息以及业务处理过程中发出的业务事件。关系关系的模型用于定义实体间的关系。这包括继承关系、组合关系和关联关系。组合关系只能用于实体组件内部,而关联关系只能在实体组件间使用。像数据库
17、的表设计一样,组合和关联关系可以定义为一对多、一对一、多对多关系。在关联关系中需要定义级联删除规则。当级联删除标志置为True时,表示需要对关联关系的被引用实体在删除时做级联删除检查,否则不做任何控制。如果级联删除规则为NoAction,表示如果要删除的实体被引用,则将不能被删除;如果级联删除规则为SetNull,表示如果实体被引用,则当它引用的实体被删除时,引用方改为空值;如果果级联删除规则为Cascade,表示如果要删除的实体已经被引用,则连同引用者一起删除。当是否启用级联校验置为True时,如果将要删除一个实体的实例时时需要将该关系上引用被删除实体的实体纳入到规则控制范围内,否则不检查改
18、实体的实例是否引用了将要被删除的实体。在关联关系中也需要定义级联修改检查规则。当修改校验被设置为true时,该关联关系的被引用实体的实例修改时,引用它的实体将被纳入到引用检查范围内,否则不检查该类型的实体实例是否引用了需要修改的实体实例。服务模型服务模型用于描述业务逻辑处理的接口信息。服务模型可以定义服务和业务操作两种接口,在模型上需要定义参数、返回值以及可能抛出的异常。同时还需要指定对数据库事务的支持方式。当一个服务接口可以有多种实现策略时,可以定义多个策略。当然策略的选择逻辑需要开发人员在随后的开发过程中通过编程实现。服务与业务操作的差异是与软件的部署方式和应用组件的边界相关的。UBF提出
19、了服务组的概念,一个服务组是指一组具有高度耦合性的业务组件,它们在安装部署时具有不可分割的整体性。因此当开发人员准备调用另外一个服务组内的组件提供的功能时,只能通过声明为服务类型的接口调用,而在服务组内组件间的相互调用通常使用业务操作。注意这种划分并不仅仅与是否支持远程调用有关,通常无论服务还是业务操作都支持远程调用。界面模型界面模型用于描述应用的交互界面。它包括表单数据模型、表单模型、参照模型及表单模版。表单数据模型表单数据模型(UIModel)用于开发者定义界面的数据模型。它由一个或多个视图(UIView),以及视图间的连接关系(UILink)和动作(Action)组成。每个视图可以关联一
20、个数据来源目前我们仅支持实体作为数据来源,视图下包含数据项(UIField)以及这些数据项的分组(Group)和缺省的数据筛选条件。数据项通常绑定到该视图所关联的实体的属性上,当然开发者也可以建立没有任何绑定关系的数据项以用于存储交互逻辑需要的临时性数据。缺省的数据筛选条件是开发者在设计阶段用OQL定义的缺省数据加载条件,可以通过代码动态的修改。动作用于开发者设计界面的功能行为,通常UBF的设计工具会缺省地预置一些常用行为,如保存、删除、查找等。表单模型表单模型(Form)用于开发者定义用户界面,如显示内容、布局、前端控制行为等。在表单模型中UBF提供了30种是用于ERP软件开发领域的控件,其
21、中有数据录入型的控件也有前端行为控制用的关联控件。每个控件都有数据来源的绑定信息,通常都来源于表单数据模型,特殊情况下开发者可以不绑定UIModel,在代码中实现控件内容的管理。表单模型上由关于Portal整合时使用的表单关联方面的信息。其中Form参数用于定义表单接收的参数,而提供者集合用于定义表单可以提供的参数。参照模型参照模型是轻量的表单数据模型和表单模型的复合体。因为大多数参照页面无论是界面风格还是表单数据模型的结构都具有相似性,唯一定义的仅仅是表单数据模型中视图所关联的实体和数据项以及过滤条件,因此UBF提供了这个简化版的模型以方便开发工作。如果开发者需要定义一些特殊的参照页面,可以
22、使用表单数据模型和表单模型像开发页面一样去开发参照页面。表单模版表单模版用于表单模型的重用目的。通常有一些页面大体相似,仅有一些局部的差异,开发者可以为相同的部分设计表单并生成表单模版,然后在开发表单模型时套用该模版。注意模版套用是一种复制动作,因此对模版的任何修改都将不会影响已经套用了该模版的表单。同时在一个表单上只能在模型创建时进行模版套用动作。应用组装模型应用组装模型用于描述应用的整体结构。包括应用领域的多级划分,每个应用下包含的前后台组件、应用的功能菜单结构、应用的页面。应用模型用于软件开发者以树状结构规划其开发的软件产品。开发者将其开发的业务组件和界面组件规划到每个应用中。作为支持组
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- U9 UBF 应用 开发 手册
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【天****】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【天****】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。