《FEAF架构规划方法.ppt》由会员分享，可在线阅读，更多相关《FEAF架构规划方法.ppt（76页珍藏版）》请在三一办公上搜索。
1、架构规划方法,研究院2010,目录,目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法,培训目的,能力提升 分析能力提升 规划能力提升技术管理统一规划方法指导统一架构表述模式业界发展对未来规划逐步重视对研发过程逐步重视,目录,目的架构建模方法总论联邦企业架构FEAFFEAF建模语言业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法,FEAF理论基础,制定机构-联邦企业体系结构框架(Federal Enterprise Architecture Framework,FEAF)是美国国家信息技术委员会(Chief Information Office
2、r s Council,CIO Council)提出的一套企业体系结构框架。1999,FEAF Version 1.1,建立了FEAF 及其方法学EAP方法学&Zachman framework2001,FEAF 实用指南Version 1.0详尽地介绍了企业体系结构(Enterprise Architecture,EA)的相关概念、驱动因素、建立原则、实施经验等实用目的知识，而且按照整个企业体系结构建立的生命周期(包括启动、定义、开发、使用和维护等阶段)来指导具体的FEAF 实施。2002,FEAF框架参考模型(Federal Enterprise Architecture referenc
3、e model,FEA-RM)绩效指标参考模型(Performance Reference Model,PRM)业务参考模型(Business Reference Model,BRM)服务组件参考模型(Service Component Reference Model,SRM)数据和信息参考模型(Date Reference Model,DRM)技术参考模型(Technical Reference Model,TRM)。,联邦总体架构框架FEAF/CIO协会框架,架构细分,FEAF架构说明,设计架构现状数据架构：定义业务支撑数据现状，也就是数据模型。应用架构现状：定义业务功能现状，也就是应用模
4、型。技术架构现状：定义应用和数据管理实现技术现状，也就是技术模型。设计架构目标数据架构：定义业务支撑数据目标，也就是数据模型。应用架构现状：定义业务功能目标，也就是应用模型。技术架构现状：定义目标应用和数据管理的实现技术，也就是技术模型。设计模型数据模型：定义企业概念应用模型：定义控制数据的应用技术模型：定义当前和目标技术架构细分整个企业范围内的业务域，如果将一个业务域纳入联邦框架管理的投资回报率为正，那该域就回被纳入联邦框架，其架构信息和模型将被记录在架构仓库中。迁移过程：支撑当前架构向目标架构迁移的过程。IT投资规划与决策：基于投资预算、投资回报率等标准进行评价投资管理评审：对架构信息进行
5、投资评审域架构协调：协调域架构，实现统一联邦架构，落实配置管理与工程变更控制。市场调研：进行新技术的市场调研，进行技术更新组件管理：基于联邦架构进行企业基础设施的管理采购：架构及其它迁移过程需要的采购架构治理：避免混乱、误解与重做标准：所有标准、指南与最佳实践安全标准数据标准：应用于数据、元数据及相关结构应用标准：应用于应用软件技术标准：应用于操作系统和平台,FEAF LEVEL 4,FEAF LEVEL 4说明,规划者视角：从总体上描述最终结构规模、形态、及局部间关系。即系统范围的估计。所有者视角：是业务人员的视角，由架构师设计的企业模型，描述业务实体、业务过程及其关系。设计者视角：系统分析
6、师的视角，定义数据元素，逻辑过程流及功能。构建者视角：承包商的视角，架构师的规划需要在这里转换成面向建设者的模型。需要足够的细节去确定对工具、原料及技术的限制，在这里需要形成技术模型，使信息系统与具体的编程语言、IO设备或特定支撑技术联系起来。分包商视角：根据详细规范提供模块或组件，组件可由是编程人员开发，也可以是已有的cots产品。,目录,目的架构建模方法总论联邦企业架构-FEAFFEAF建模语言业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法,FEAF 建模语言参考,IDEF0&IDEF3，DFD,IDEF1，IDEF1x，ER,UML（用例图、组件图、序列图、状态图等）,
7、The Open Group ArchitectureFramework Format,TOGAF Format,业务架构,信息架构,应用架构,技术架构,注：FEA推荐软件建模工具厂商Popkin software提供,IDEF方法体系简介,简介：IDEF是由美国空军发明的用于描述企业内部运作的一套建模方法，经过改造后用途变广泛了，适用于一般的软件开发。IDEF的16套方法（最常使用的是IDEF0IDEF4）IDEF0：功能建模（Function Modeling），类似数据流图DFDIDEF1：信息建模（Information Modeling）IDEF1X：数据建模（Data Modeli
8、ng），类似实体-关系图ERIDEF2：仿真建模设计（Simulation Model Design）IDEF3：过程描述获取（Process Description Capture），类似业务流程图TFDIDEF4：面向对象设计（Object-Oriented Design）IDEF5：本体论描述获取（Ontology Description Capture）IDEF6：设计原理获取（Design Rationale Capture）IDEF7：信息系统审定（Information System Auditing）IDEF8：用户介面建模（User Interface Modeling）ID
9、EF9：场景驱动信息系统设计（Scenario-Driven IS Design）IDEF10：实施体系结构建模（Implementation Architecture Modeling）IDEF11：信息制品建模（Information Artifact Modeling）IDEF12：组织建模（Organization Modeling）IDEF13：三模式映射设计（Three Schema Mapping Design）IDEF14：网络规划（Network Design）,UML简介,1997年，OMG组织（Object Management Group对象管理组织）发布了统一建模语言
10、（Unified Modeling Language，UML），UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。2003年，UML已经获得了业界的认同。常用UML图用例图：用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求类图：类图表示不同的对象如何彼此相关；换句话说，它显示了系统的静态结构。序列图：序列图显示具体用例（或者是用例的一部分）的详细流程。它几乎是自描述的，并且显示了流程中中不同对象之间的调用关系。状态图：状态图表示某个类所处的不同状态和该类的状态转换信息。每个类都有状态，但不是每个类都应该有一个状态图。活动图：活动图表示在处理某个活动时
11、，两个或者更多类对象之间的过程控制流。活动图最适合用于对较高级别的过程建模，比如公司当前在如何运作业务，或者业务如何运作等。组件图：组件图提供系统的物理视图。它的用途是显示系统中的软件对其他软件组件（例如，库函数）的依赖关系。部署图：部署图表示该软件系统如何部署到硬件环境中。它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信。,The Open Group Architecture Framework,TOGAF简介,来源TOGAF的开发始于1995年，基于美国国防部的TAFIM框架（Technical Architecture Framework for Informa
12、tion Management），每年都有新版本发布，目前版本是v。TOGAF的组成PARTI介绍（Introduction），对企业架构，尤其是TOGAF方法的关键概念做一些高层介绍。PARTII架构开发方法(Architecture Development Method，ADM)，这是TOGAF的核心，详细介绍了开发企业架构的步骤和方法。PARTIII一作为FEAF技术架构的参考企业统一体(Enterprise Continuum)，是一个架构资产的虚拟仓库，包含TOGAF基础架构（Foundation Architecture）及集成信息基础设施参考模型（Integrated Infor
13、mation Infrastructure Reference Model，III-RM)。PARTIV资源(Resources)，一系列应用TOGAF及ADM的工具和技术。,交付,操作方法,架构建模操作方法及交付,业务架构,数据架构,应用架构,技术架构,IT基础架构,DFD,ER,U/C矩阵,TNA/TRM/DIOA参考,DFD图,DD,CDM,LDM/PDM,系统功能框架,系统数据交互,技术无关框架,技术相关框架,集成架构,EAP,物理部署图,方法：为达到某种目的而采取的途径、步骤、手段,目录,目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法,事件驱动过
14、程建模-结构化方法（SA)建模,事件和事件表,事物,实体联系图E-R,环境图,DFD,数据字典DD,过程说明(判定树/表）,分析,设计,实施,编程工具,测试工具,结构图,系统流程图,关系数据库模式,用户界面,表单/报表,系统控制,伪码,业务架构,业务建模过程,绘制上下文图明确系统与环境的主要接口,将系统分解成逻辑子系统或业务过程，形成过程分解图。至少要分解到活动或用例级（即可由一个岗位独立完成的任务）。过程分解图可作为过程文档不做输出,以事件列表的形式描述事件的触发器、响应、来源、目的等信息。除事件列表外，还可绘制事件自身的DFD。事件列表和事件DFD是过程文档，可不输出。,绘制0、1、2等级
15、别的DFD图，并输出数据字典。数据字典以业务过程列表和实体列表表达。,明确系统范围上下文图,在分解过程中，首先构造的是系统的上下图（CONTEXT DIAGRAM)，上下文图是一个最高层次的数据流程图，它将“业务”视之为一个黑盒。上下文图定义了“产品”的外部环境和范围。上下文图说明了业务的外部实体（external entity)以及业务与这些外部实体之间的数据交换，即业务与其外部实体之间的接口。在上下文图中，不描述业务内部的情况，因此，整个业务用一个过程来表示。上下文图只有一张，图中的加工也只有一个，所以不必编号。,业务过程分解爆破法过程分解,企业活动,目标,运营管理,What,Who(ro
16、le),How,Level 0业务活动,Level 1过程分组,Level 2中心过程,Level 3业务流程,Level 4操作流程,Level 5详细流程,业务,物主身份,过程分组,系统,交付团队 任务,流程,系统功能,角色 步骤,子流程,交易,详细角色 操作,详细流程,模型结构,方法和建模标准定义业务活动辨别操作的客户经营和战略过程导向展示相关的业务功能集和标准的端到端服务流程中心过程结合在一起交付服务流和其他端到端流程中心过程分解成详细的“成功模式”的业务流程有错误条件、产品和地点的操作流程进行必须的详细操作的分解,业 务 级,过 程 级,操 作 级,爆破法分解业务级LEVEL 0,L
17、evel 0业务活动，定义业务活动，辨别操作的客户，经营和战略过程导向what-企业活动,who-目标，HOW-运营管理确定和定义模型：业务目标，价值流，环境和财务的约束；支持业务运营和产品线的管理。这些业务目标的过程和系统解决方案的交付。,爆破法分解业务级LEVEL 1,Level 1过程分组，展示相关的业务功能集和标准的端到端服务流程what-过程分组,who-物主身份即业务拥有者，可理解为业务部门，HOW-业务设计：产品结构，产品交付和支撑过程链，企业级数据模型，组织结构，业务知识定义不同的过程视图交付给0级的业务活动。过程被组织的方法：过程执行的观点：展示标准的端到端过程，如实施开通等
18、功能的观点：如：客户关系管理等。,爆破法分解过程级LEVEL 2,Level 2中心过程，中心过程结合在一起交付服务流和其他端到端流程what-中心过程,who-交付单位，IT部或SI,HOW-产品参考行业标准参考模型；定义模型：业务数据定义，系统构成；定义业务角色。公认的端到端子过程：通常在一个业务单位或业务线内实现的定义那些传递业务竞争优势的活动。象明显的来自于支撑的过程。通常的被看作价值链的模型。中心过程包含的祥细任务被定义在3级业务流程里,爆破法分解过程级LEVEL 3,Level 3业务流程，中心过程分解成详细的“成功模式”的业务流程，完成任务。what-流程,who-团队，HOW-
19、系统设计详细过程；分配业务角色；确定支撑的系统，数据流。映射业务数据模型到系统数据模型。考虑失败路线；排队和瓶颈。定义2级中心过程的流程：由任务组成通常一般地定义（不是某个特殊的产品，客户，地区的运营等）常常仅展示正常的场景，不包含选择性行动、失败和错误恢复的细节如果需要，任务在4级操作流程里被更详细的分解。,业务事件分解事件列表,事件列表要达到对业务事件进行梳理和说明的目的，业务事件是业务流程的触发器，同时业务流程可分解为业务活动，这种分解关系是DFD业务过程分解的本质，也体现了事件驱动业务过程分析的特点。事件列表可作为一个过程文档，在最终规划文档中不体现,业务建模方法DFD概述,DFD是一
20、种图形化的过程建模工具。它通过4个基本要素：外部实体、数据流、过程和数据存储描述了系统中数据的流动和数据的变化，它强调的是数据流和处理过程。DFD 基本符号,也称“处理或处理”,DFD 建模,采用Chris Gane and Trish Sarson符号体系DFD的过程必须是本质处理过程。描述数据流不描述控制流；本质处理过程描述“做什么（what to do)”,而并不用关心“如何做（how to do)”.父图与子图的平衡。子图的输入输出数据流同父图相应加工的输入输出数据流必须一致 分解的程度：一般不超过7个本质变化包括：计算进行决策数据分流数据合并数据过滤或综合产生新的数据流。过程的命名详
21、细处理过程（以动词开头客体）高层处理过程（名词词组）能够描述系统中流动的数据的组成，数据流和物流分开给每一个处理一个标号，处理之间不要试图让数据流图反映处理的顺序。,DFD建模数据字段(DD)业务过程列表,DFD建模数据字段(DD)数据实体列表,目录,目的架构建模方法总论业务架构建模方法数据架构建模方法数据建模理论模型分析方法应用架构建模方法技术架构设计方法,数据建模理论,对需求调研所得到数据的高层的抽象描述。,ER模型,数据字典数据流图,第1步：需求调研,第2步：概念分析,第3步：逻辑设计,确定客户需要哪些信息，建立哪些应用，常用的操作及对象有哪些等。,将概念模型映射为某个特定类型的DBMS
22、模式数据。,数据建模过程,对已经确定的逻辑结构选择适当的物理结构，包括存储结构、存取路径、存储分配等。,第4步：物理设计,数据工作,DFD工作,验证工作,数据模型,数据流图DFD,利用业务流程校验功能、属性、数据流,业务人员或需求工作,业务事件、信息收集,人员Who,范围分析What,方法hoW,从企业角度，分析业务概念和事件活动,功能数据校验,任务类别,3X3建模过程,3X3矩阵各阶段：概念-逻辑-物理,34,3X3矩阵各层面：业务-管理-实现,纵向分为业务、管理、实现三个层面，这是业务角度上的划分，它们之间是一种并列关系，但是它们之间互相联系，只是它们各自关注的角度不同业务处理核心业务事件
23、(RUP:直接使客户受益的活动)该类业务活动的某环节一旦停止，业务即不能正常开展管理处理为了使业务运转的更好所增加的管理活动，主要分以下两类：一类是对活动本身的管理，既规则管理另一类是对活动结果的管理，如经营分析实现处理为了使核心业务流程能够正常运转所需要开展的辅助活动如：异常处理，支持与就绪，与参与人的交互等,35,3X3矩阵各层面：概念逻辑物理,概念模型设计是整个数据架构设计的关键，通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。概念模型是从业务的视角对企业运营过程中涉及的信息的结构化描述，是技术中立的模型逻辑模型设计对概念分析阶段中牵涉的业务，抽象出处理功能，并
24、逐步细化，以达到能在系统中实现。逻辑模型是从解决方案的角度对数据的结构化描述；是技术相对中立的模型物理模型设计对逻辑设计中的功能与实体进一步细化，使功能/数据能在具体的系统中实现物理模型是结合具体的DBMS等技术选择，考虑系统的可实现性、性能、接口等因素，在逻辑数据模型基础上进一步细化设计的模型,目录,目的架构建模方法总论业务架构建模方法数据架构建模方法数据建模理论模型分析方法应用架构建模方法技术架构设计方法,概念模型分析,定义概念模型是从业务的视角对企业运营过程中涉及的信息的结构化描述，是技术中立的模型目标用IT语言表达现实世界问题空间：分析出所有的业务实体，定义业务概念，阐述清楚实体之间的
25、基本关系方法初步划分业务活动范围寻找业务活动范围中的业务实体并描述定义分析并描述业务实体之间的关系从属关系分析处理关系分析管理关系分析分析并描述业务实体关键属性分析属性所对应的业务值域业务场景校验、CRUD校验,38,逻辑模型分析,定义逻辑模型是从解决方案的角度对数据的结构化描述；是技术相对中立的模型目标 设计支持现实世界概念模型的逻辑模式和子模式(外模式)对概念分析阶段中牵涉的业务，抽象出处理功能，并逐步细化，以达到能在系统中实现方法在概念分析的基础上划定系统边界去掉仅仅代表业务，而不需要应用系统实现的实体和处理将模型转化为关系模式将模型中相近的实体和处理进行归纳抽象，消除冗余引入设计层面所
26、需要的实体和处理，并逐层细化设计实体类的属性，设计相关的值域，确定实体类的候选标识并进一步确定主标识，建立与属性相关的业务规则定义逻辑实体和处理业务场景校验、CRUD校验,39,逻辑模型设计方法,逻辑模型设计模型转换,实体的转换概念层面的实体可直接转成逻辑实体根据实体类、关联关系存在的相似性，进行适当层次的抽象，形成更为通用的概念；实体的归纳和细化将模型中相近的实体进行归纳抽象，消除冗余。归纳是一个由多到少的过程，目的是要达到模型与业务的无关性，实现数据模型的稳定持续发展引入设计层面所需要的实体，然后对系统开展的活动进一步细化，使得处理功能越来越逼近于函数的实现形式；细化是一个由少到多的过程，
27、细化的目标是完善实体和功能关系的转换：若实体间联系是1:1，可以在两个实体类型转换成的两个实体中任意一个实体的属性中加入另一个实体的标识和联系类型（如层级关系）的属性。若实体间联系是1:N，则在N端实体转换成的实体中加入1端实体的键和联系类型的属性。若实体间联系是M:N，则将联系也转换成实体，其属性为两端实体的标识加上联系的属性，而标识为两端实体标识的组合。属性的转换概念层面的实体属性可直接带到逻辑实体中，补充类型和长度等描述,逻辑设计阶段3NF约束,范式化规范化的目的是使数据模型有更好的结构，控制和减少数据冗余，符合关系数据库的设计规则。规范化的目标是保证只有一个途径来知道一个事实。关系数据
28、库的一个目的是最大化数据完整性，保证数据的准确性，而实现这一目的的重要方法就是让每个概念在数据库中只出现在一个地方（外键约束除外），如果同时存在多个地方，就会存在数据不一致的隐患，导致对数据完整性的破坏。规范模型的过程是删除模型结构中那些多种途径来了解相同事实的模型结构。三范式第一范式要求实体的每个属性的值都是原子的，并且必须有单一的含义。第二范式要求符合第一范式后，实体的每一个非键值（Key）属性都必须完全依赖于整个键值，而不是键值的一部分。第三范式要求符合第二范式后，实体的每一个非键值属性都不能依赖其它非键值属性。,物理模型设计,定义物理模型是结合具体的DBMS等技术选择，考虑系统的可实现
29、性、性能、接口等因素，在逻辑数据模型基础上进一步细化设计的模型目标根据DBMS特点和处理的需要，进行物理存储等安排，形成内模式对逻辑设计中的功能与实体进一步细化，使功能/数据能在具体的系统中实现方法设计UI/系统接口考虑性能，进行反规范化设计设计数据存储(内存/文件/DB)设计索引、视图、分区、存储参数等性能参数引入具体实现层面所需要的实体和处理，并细化设计程序异常处理及系统管理设计其他技术实现细节场景校验、CRUD校验,43,目录,目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法,系统框架分析方法UC矩阵,U/C矩阵分析是在业务流程、数据流程及数据分析的基
30、础上，为了整体地考虑系统的功能子系统和数据资源的合理分布而进行的系统化的分析方法U/C矩阵是结构划系统分析方法中，用来表达过程与数据两者之间的关系的方法。矩阵中的列表示数据类，行表示过程，并以字母U（Use）和C（Create）来表示过程对数据类的使用和产生。U/C矩阵是一种用关系数据矩阵进行系统分析方法，并对其存储、正确性检验、表上作业等做了分析，同时利用结果关系进行了子系统划分 U/C矩阵是一张表格。它可以表数据/功能系统化分析的结果。它的左边第一列列出过程的名称，上面第一行列出数据类的名称。表中在各过程与数据类的交叉处，填写过程与数据类的关系。,U/C矩阵使用方法,系统框架,UC矩阵使用
31、过程,U/C矩阵的建立用表的行和列分别记录下数据类和过程。表中功能与数据类交叉点上的符号表示这类数据由相应功能产生，表示这类功能使用相应的数据类 U/C矩阵正确性校验完备性校验：指对具体的数据项必须有一个产生者（C）和至少一个使用者（U），功能则必须有产生或使用（U或C）发生一致性校验：指对具体的数据项必须有且仅有一个产生者（C）无冗余校验:指 UC矩阵中不允许有空行和空列U/C矩阵的求解 UC 矩阵的求解就是对系统结构划分的优化过程。它是基于子系统划分应相互相对独立且内部凝聚性高这一原则之上的一种聚类操作。UC 矩阵的求解过程常通过表上作业法来完成。其具体操作方法是：调整表中的行变量或列变量
32、，使得“C”元素尽量地朝对角线靠近，然后再以“C”元素为标准，划分子系统。系统功能划分与数据资源分布在求解后的UC 矩阵中划出一个个的方块，每一个小方块即为一个子系统。,建立U/C矩阵,列表示数据,列表示过程,C表示此过程创建此数据,U表示此过程使用此数据,无冗余校验!不允许有空行,!,一致性校验!有2个C,完备性校验!数据项只有U没有C,完备性校验!数据项只有C没有U,完备性校验!过程没有U也没有C,U/C矩阵的求解,调整列，使“C”元素尽量地朝对角线靠近,高内聚,子系统的划分,矩形划分子系统,所有的C必须在矩形中,数据交互,系统间的数据交互,子系统的划分的原则,相对独立性 子系统或模块相对
33、独立,尽量减少各种不必要的数据调用和控制联系,并将联系比较密切、功能近似的模块相对集中系统之间数据的依赖性尽量小子系统之间的联系要尽量减少,接口要简单、明确。一个内部联系强的子系统对外部的联系必然很少,所以划分时应将联系较多者列入子系统内部。数据冗余尽量小管理发展的需要必须兼顾组织机构的要求，能够符合现有的情况和人们的习惯。便于系统分阶段实现子系统的划分应能适应这种分期分步的实施。资源的充分利用考虑有利于各种设备资源在开发过程中的搭配使用,考虑到各类信息资源的合理分布和充分使用,应用架构交付模板-系统应用功能框架,目录,目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架
34、构设计方法参考模型集成架构技术架构,NGOSS 设计思路,最大限度满足客户需求变化,四个分离：1.功能和数据分离；2.功能和规则分离；3.功能和流程分离；4.界面和功能分离；横向整合的平台化、专业化,56,56,逐步面向SOA技术架构体系的策略方向,56,流 程,烟囱式,第1级,基础服务化,第4级,复合服务化,第5级,虚拟服务化,第6级,第7级,灵活可配置的服务,组件化,第 3级,集成化,第2级,模块,基础服务,基于服务的流程集成,灵活的应用软件集合,构件,对象,应用软件,结构化分析与设计,面向服务建模,面向服务建模,面向语法建模,基于构件开发,面向对象设计,方法,面向功能,面向服务,面向服务
35、,面向服务,面向功能,面向功能,业务角度,面向服务,面向服务建模,基于服务的 流程集成,特定平台,特定平台,技术兼容,灵活感应,特定平台,特定平台,基础架构,单一架构,基础的SOA,网格化的SOA,灵活可配置的架构,基于构件架构,分层架构,系统架构,SOA,平台无关,IT系统基本实现集成化目标.在未来的3-5年内需实现基于基础服务的初步SOA体系架构进一步实现融合集中的IT,公司目前处于集成化向组件化的成熟过程，向服务化发展。,TMF-TNA与DIOA,NGOSS-TNA基于DIOADIOA:是一种面向组件的设计方法。服务提供者通过接口向服务消费者提供功能，而服务提供者和服务消费者在架构上可能
36、是分布式的。参考其概念层次模型，定义了三类组件：框架服务组件、托管服务组件和业务服务组件。其中，框架服务和托管服务对应DIOA的框架服务。定义了三类容器：应用，组件，服务。三者是向后包含关系。,TNA架构定义运算视角定义了NGOSS组件，定义了组件间交互方式。工程视角定义组件的内部核心对象、契约实例、接口对象从核心对象间关系、契约对象间消息传输与操作调用和中间件以及中间件协议三个层次定义组件间交互。,DIOA分层框架,functional block,component,contract,Service end point,Basic Technology,DIOA概念模型说明,业务模型层（B
37、usiness Model）：关注业务应用的设计与实现。业务应用由一系列组件实现。服务工程层(Service Engineering)：关注组件的建模。包括接口、协议及规范等。服务框架层(Service Framework)：关注提供框架服务接口与对象的建模。如：命名服务、事件服务等。该层提供框架服务类组件基础技术层(Basic Technologies)：关注中间件与基础技术的建模，采用中立的语言描述。,TMF技术中立架构（TNA)详细视图,仓库,位置服务,Contract inst.,Int.Mech,注册服务,Contract inst.,Int.Mech,仓库服务,Contract i
38、nst.,Int.Mech,命名服务,Contract inst.,Int.Mech,强制托管框架 服务,通用通讯传输工具,规则服务,Contract inst.,Int.Mech,流程服务,Contract inst.,Int.Mech,安全服务,Contract inst.,Int.Mech,服务,Contract inst.,Int.Mech,服务,Contract inst.,Int.Mech,遗留应用,TOGAF TRM,TRM 层次分析,应用软件层业务应用基础框架应用应用平台层应用组件框架图形用户交互数据交互数据管理国际化操作位置目录安全传输处理软件工程管理系统与网络管理通讯基础框
39、架,应用平台接口应用软件与应用平台层间的接口通讯基础设施接口应用平台层 与通讯基础设施层间的接口,3个层次,2类接口,DIOA与TRM结合,多层体系：通讯层、应用平台、业务应用、展示层多个分离：应用与数据、应用与流程、流程与规则、功能与展示架构特征：专业化、平台化、组件化接口特征：集中化、通用化、层次化、标准化、开放性,目录,目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法参考模型集成架构技术架构,集成技术定义,数据集成数据集成通过直接访问应用系统所创建、维护并储存的相应信息来实现应用系统间的数据重用和同步，一般不涉及业务逻辑。数据集成主要用于实现批量数据传
40、输和数据同步、数据转换和统一数据视图等功能要求。应用集成应用集成是指应用系统之间业务逻辑调用的要求，在程序代码级别上通过应用系统间的接口实现集成。应用系统提供具备一定业务含义的系统接口，同时也使用其他系统提供的系统接口。适合于同步非实时与异步类型接口集成要求服务集成是指符合一定技术标准规范的应用集成流程集成流程集成是在应用集成和数据集成的基础上，利用流程管理系统把各应用系统暴露出来的应用/数据接口，根据业务流程的要求进行流程定制，达到业务流程与具体应用系统分离的目的，并且依靠流程管理产品的强大功能获得业务流程可灵活配置，可实时监控的优势，为跨系统的端到端业务流程提供流程调度、自动化执行和灵活调
41、整的能力。界面集成界面集成主要是将企业内部系统的访问界面集中起来，实现统一的用户界面视图，用户无需在多个系统之间来回切换。用户界面集成主要应用企业信息门户来实现。,接口技术选型参考,表格说明：1、批量：（数据量1M)2、业务量：(业务量5万/日),集成平台选择参考,以下场景适合用点到点集成技术：接口传递的数据固定，不需要复杂的数据逻辑转换所属的业务只涉及两个系统，且不依赖别的接口也不被别的接口依赖非实时的接口，可以在特定时间传送大量的数据以下场景适用平台集成技术所属的业务交易需要在多个系统中传递同样的交易内容。所属的业务需要各系统间的多次交互，并且这些交互需要系统自动控制流程顺序。,集成架构模
42、版示例-集成总体视图,集成架构交付模版接口列表,目录,目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法参考模型集成架构技术架构,技术中立架构TNA,TNA(technology neutral architecture)是一个基于组件的、分布式的、支持灵活的业务流程部署的、易于集成应用系统的、与技术无关的NGOSS系统框架体系。NGOSS中定义TNA应遵循以下标准：分布式面向接口结构；技术中立的组件模型；业务流程与组件实现相分离；安全使能架构；策略使能架构；共享信息模型与数据环境；分布透明性；,技术架构参考模版-技术中立架构,技术相关架构TSA,TNA对系统分层体系结构及各层组件功能作了规范在此基础上将各层组件的实现技术进行规范则形成了技术相关架构（Technology Specific Architecture）技术相关架构对技术的选用原则是尽量使用行业标准的技术框架（比如支持分布式运算，面向组件的架构，面向服务的架构等）,技术架构参考模版-技术相关架构,讨论,Q？A。,
