IT架构规划方法(规划培训精选).ppt

《IT架构规划方法(规划培训精选).ppt》由会员分享，可在线阅读，更多相关《IT架构规划方法(规划培训精选).ppt（77页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法培训目的培训目的p 能力提升能力提升 分析能力提升 规划能力提升p 技术管理技术管理统一规划方法指导统一架构表述模式p 业界发展业界发展对未来规划逐步重视对研发过程逐步重视目录目录目的架构建模方法总论 联邦企业架构FEAF FEAF建模语言业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法FEAF理论基础理论基础制定机构-联邦企业体系结构框架( Federal Enterprise Architecture Framework , FEAF) 是美国国家信息技术委员会(Chief Info

2、rmation Officer s Council ,CIO Council) 提出的一套企业体系结构框架。1999 ,FEAF Version 1.1, 建立了FEAF 及其方法学EAP方法学& Zachman framework2001,FEAF 实用指南Version 1.0详尽地介绍了企业体系结构( Enterprise Architecture , EA) 的相关概念、驱动因素、建立原则、实施经验等实用目的知识，而且按照整个企业体系结构建立的生命周期(包括启动、定义、开发、使用和维护等阶段) 来指导具体的FEAF 实施。2002, FEAF框架参考模型( Federal Enterp

3、rise Architecture reference 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/CIOFEAF/CIO协会框架协会框架

4、业务驱动业务驱动设计驱动设计驱动标准标准技术技术应用应用数据数据安全安全投资评审投资评审分层协调分层协调市场研究市场研究组件管理组件管理变迁过程变迁过程架构驱动架构驱动愿景愿景战略方向战略方向原则原则 分层架构模型分层架构模型 现状现状目标目标业务架构业务架构数据架构数据架构应用架构应用架构技术架构技术架构联邦架构框架联邦架构框架 Level Level III 架构细分架构细分FEAFFEAF架构说明架构说明设计架构现状数据架构 ： 定义业务支撑数据现状，也就是数据模型。应用架构现状： 定义业务功能现状，也就是应用模型。技术架构现状：定义应用和数据管理实现技术现状，也就是技术模型。设计架构目

5、标数据架构 ： 定义业务支撑数据目标，也就是数据模型。应用架构现状： 定义业务功能目标，也就是应用模型。技术架构现状：定义目标应用和数据管理的实现技术，也就是技术模型。设计模型数据模型：定义企业概念应用模型：定义控制数据的应用技术模型：定义当前和目标技术架构细分整个企业范围内的业务域，如果将一个业务域纳入联邦框架管理的投资回报率为正，那该域就回被纳入联邦框架，其架构信息和模型将被记录在架构仓库中。迁移过程：支撑当前架构向目标架构迁移的过程。IT投资规划与决策：基于投资预算、投资回报率等标准进行评价投资管理评审：对架构信息进行投资评审域架构协调：协调域架构，实现统一联邦架构，落实配置管理与工程变

6、更控制。市场调研：进行新技术的市场调研，进行技术更新组件管理：基于联邦架构进行企业基础设施的管理采购：架构及其它迁移过程需要的采购架构治理：避免混乱、误解与重做标准：所有标准、指南与最佳实践安全标准数据标准：应用于数据、元数据及相关结构应用标准：应用于应用软件技术标准：应用于操作系统和平台FEAF LEVEL 4视角数据架构(实体=what)应用架构(活动=how)技术架构(位置=where)规划者视角（目标/范围）业务对象列表业务过程列表业务分布(场所)列表所有者视角（企业模型）语义模型业务过程模型业务支撑系统系统设计者视角（信息系统模型）逻辑数据模型应用架构系统物理部署架构承包商视角（技术

7、模型）物理数据模型系统设计技术架构分包商视角（详细规范）数据定义程序“支撑软件组件(比如操作系统)”网络架构FEAF LEVEL 4说明说明规划者视角：从总体上描述最终结构规模、形态、及局部间关系。即系统范围的估计。所有者视角：是业务人员的视角，由架构师设计的企业模型，描述业务实体、业务过程及其关系。设计者视角：系统分析师的视角，定义数据元素，逻辑过程流及功能。构建者视角：承包商的视角，架构师的规划需要在这里转换成面向建设者的模型。需要足够的细节去确定对工具、原料及技术的限制，在这里需要形成技术模型，使信息系统与具体的编程语言、IO设备或特定支撑技术联系起来。分包商视角：根据详细规范提供模块或

8、组件，组件可由是编程人员开发，也可以是已有的cots产品。目录目录目的架构建模方法总论 联邦企业架构-FEAF FEAF建模语言业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法FEAF 建模语言参考建模语言参考IDEF0&IDEF3，DFDIDEF1，IDEF1x，ERUML（用例图、组件图、序列图、状态图等）（用例图、组件图、序列图、状态图等）The Open Group ArchitectureFramework Format, TOGAF Format业务架构业务架构信息架构信息架构应用架构应用架构技术架构技术架构注：注：FEA推荐软件建模工具厂商Popkin softw

9、are提供IDEF方法体系简介方法体系简介简介：IDEF是由美国空军发明的用于描述企业内部运作的一套建模方法，经过改造后用途变广泛了，适用于一般的软件开发。 IDEF的16套方法（最常使用的是IDEF0IDEF4 ） IDEF0：功能建模（Function Modeling），类似数据流图DFD IDEF1：信息建模（Information Modeling） IDEF1X：数据建模（Data Modeling），类似实体-关系图ER IDEF2：仿真建模设计（Simulation Model Design） IDEF3：过程描述获取（Process Description Capture），

10、类似业务流程图TFD IDEF4：面向对象设计（Object-Oriented Design） IDEF5：本体论描述获取（Ontology Description Capture） IDEF6：设计原理获取（Design Rationale Capture） IDEF7：信息系统审定（Information System Auditing） IDEF8：用户介面建模（User Interface Modeling） IDEF9：场景驱动信息系统设计（Scenario-Driven IS Design） IDEF10：实施体系结构建模（Implementation Architecture M

11、odeling）IDEF11：信息制品建模（Information Artifact Modeling） IDEF12：组织建模（Organization Modeling） IDEF13：三模式映射设计（Three Schema Mapping Design） IDEF14：网络规划（Network Design） UML简介简介1997年，OMG组织（Object Management Group对象管理组织）发布了统一建模语言（Unified Modeling Language，UML），UML的目标之一就是为开发团队提供标准通用的设计语言来开发和构建计算机应用。2003年，UML已经获

12、得了业界的认同。常用UML图 用例图用例图：用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求功能需求 类图类图：类图表示不同的对象对象如何彼此相关；换句话说，它显示了系统的静态系统的静态结构结构。 序列图序列图 ：序列图显示具体用例具体用例（或者是用例的一部分）的详细流程详细流程。它几乎是自描述的，并且显示了流程中中不同对象之间的调用关系不同对象之间的调用关系。 状态图状态图：状态图表示某个类某个类所处的不同状态不同状态和该类的状态转换信息。每个类都有状态，但不是每个类都应该有一个状态图。 活动图活动图：活动图表示在处理某个活动某个活动时，两个或者更多类对象更多类对象之间的过

13、程控过程控制流制流。活动图最适合用于对较高级别的过程建模，比如公司当前在如何运作业务，或者业务如何运作等。 组件图组件图 ：组件图提供系统的物理视图。它的用途是显示系统中的软件对其他软件对其他软件组件（例如，库函数）的依赖关系软件组件（例如，库函数）的依赖关系。 部署图部署图：部署图表示该软件系统如何部署到硬件环境中。它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信不同的组件将在何处物理地运行，以及它们将如何彼此通信。 The Open Group Architecture Framework, TOGAF简介简介来源 TOGAF的开发始于1995年，基于美国国防部的T

14、AFIM框架（ Technical Architecture Framework for Information Management ），每年都有新版本发布，目前版本是v 8.1.1。TOGAF的组成 PART I介绍（Introduction），对企业架构，尤其是TOGAF方法的关键概念做一些高层介绍。 PART II架构开发方法 (Architecture Development Method，ADM) ，这是TOGAF的核心，详细介绍了开发企业架构的步骤和方法。 PART III一作为作为FEAF技术架构的参考技术架构的参考企业统一体(Enterprise Continuum) ，是一

15、个架构资产的虚拟仓库，包含TOGAF基础架构（Foundation Architecture ）及集成信息基础设施参考模型（Integrated Information Infrastructure Reference Model ，III-RM)。 PART IV资源(Resources) ，一系列应用TOGAF及ADM的工具和技术。交付交付操作方法操作方法架构建模操作方法及交付架构建模操作方法及交付业务架构业务架构数据架构数据架构应用架构应用架构技术架构技术架构IT基础架构基础架构DFDERU/C矩阵矩阵TNA/TRM/DIOA参考参考DFD图图DDCDMLDM/PDM系统功能框架系统功能

16、框架系统数据交互系统数据交互技术无关框架技术无关框架技术相关框架技术相关框架集成架构集成架构EAP物理部署图物理部署图方法：为达到某种目的而采取的途径、步骤、手段方法：为达到某种目的而采取的途径、步骤、手段 目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法事件驱动过程建模事件驱动过程建模-结构化方法（结构化方法（SA)建模建模事件和事件表事件和事件表事物事物实体联系图实体联系图E-RE-R环境图环境图DFDDFD数据字典数据字典DDDD过程说明过程说明( (判定树判定树/ /表）表）分析分析设计设计实施实施编程工具编程工具测试工具测试工具结构图结构图

17、系统流程图系统流程图关系数据库模式关系数据库模式用户界面用户界面表单表单/ /报表报表系统控制系统控制伪码伪码数据字典E-R图DFD处 理规 格说明数 据对 象描 述状态转移图控制规格说明CSPEC实体-关系数据流PSPEC业务架构业务架构业务建模过程业务建模过程明确系统范围过程分解梳理事件列表DFD建模绘制上下文图绘制上下文图明确明确系统与环系统与环境的主要接口境的主要接口将将系统分解成系统分解成逻辑子系统或逻辑子系统或业务过程业务过程，形，形成过程分解图。成过程分解图。至少要分解到至少要分解到活动或用例级活动或用例级（即可（即可由一个由一个岗位独立完成岗位独立完成的任务的任务）。）。过程分

18、解图可过程分解图可作为过程文档作为过程文档不做输出不做输出以事件列表的以事件列表的形式描述事件形式描述事件的的触发器、响触发器、响应、来源、目应、来源、目的的等信息。等信息。除事件列表外，除事件列表外，还可绘制事件还可绘制事件自身的自身的DFDDFD。 事件列表和事事件列表和事件件DFDDFD是过程是过程文档，可不输文档，可不输出。出。绘制绘制0 0、1 1、22等级别的等级别的DFDDFD图图，并输出数据字典。并输出数据字典。数据字典以数据字典以业务业务过程列表过程列表和和实体实体列表列表表达。表达。明确系统范围上下文图明确系统范围上下文图在分解过程中，首先构造的是系统的上下图（CONTEX

19、T DIAGRAM)，上下文图是一个最高层次的数据流程图，它将“业务业务”视之为一个视之为一个黑盒。黑盒。上下文图定义了“产品”的外部环境和范围。上下文图说明了业务的外部实体业务的外部实体（external entity)以及业务与这些外部实体之间的数据交换，即业务与其外部实体之间的接口业务与其外部实体之间的接口。在上下文图中，不描述业务内部的情况，因此，整个业务用一个过程来表示。上下文图只有一张，图中的加工也只有一个，所以不必编号。 明确系统范围过程分解梳理事件列表DFD建模OCSOCS客户客户资料资料业务请求业务请求应答信息应答信息产品产品信息信息产品管理产品管理客户管理客户管理帐务管理帐

20、务管理业务业务网元网元管理管理/ /维护信息维护信息客户服务客户服务帐单帐单/ /详单详单余额信息余额信息网管网管网管网管KPIKPI统计分析统计分析缴费信息缴费信息余额余额离线计费离线计费局数据局数据累计消费信息累计消费信息经分经分SMSCSMSC帐单详单帐单详单计费通知短信部分计费通知短信部分充值网关充值网关充值信息充值信息业务人员业务人员业务过程分解爆破法过程分解业务过程分解爆破法过程分解企业活动企业活动目标目标运营管理运营管理WhatWho(role)HowLevel 0业务活动业务活动Level 1过程分组过程分组Level 2中心过程中心过程Level 3业务流程业务流程Level

21、 4操作流程操作流程Level 5详细流程详细流程业务业务物主身份物主身份过程分组过程分组产品产品交付单位交付单位中心过程中心过程系统系统交付团队交付团队 任务任务流程流程系统功能系统功能角色角色 步骤步骤子流程子流程交易交易详细角色详细角色 操作操作详细流程详细流程模型结构模型结构,方法和建模标准方法和建模标准定义业务活动定义业务活动辨别辨别操作的客户操作的客户经营和战略过程经营和战略过程导向导向展示相关的展示相关的业务功能集业务功能集和和标准的端到端服务流程标准的端到端服务流程中心过程中心过程结合在一起结合在一起交付服务流交付服务流和和其他端到端流程其他端到端流程中心过程分解成详细中心过程

22、分解成详细的的“成功模式成功模式”的业务流程的业务流程有有错误条件、产品和地点错误条件、产品和地点的的操作流程操作流程进行必须的进行必须的详细操作的分解详细操作的分解业 务 级过 程 级操 作 级明确系统范围过程分解梳理事件列表DFD建模爆破法分解业务级爆破法分解业务级LEVEL 0Level 0业务活动，定义业务活动，辨别操作的客户，经营和战略过程导向what-企业活动企业活动, who-目标目标，HOW-运营管理运营管理确定和定义模型：业务目标，价值流，环境和财务的约束；支持业务运营和产品线的管理。这些业务目标的过程和系统解决方案的交付。爆破法分解业务级爆破法分解业务级LEVEL 1Lev

23、el 1过程分组，展示相关的业务功能集和标准的端到端服务流程what-过程分组过程分组, who-物主身份即业务拥有者物主身份即业务拥有者，可理解为业务部门，HOW-业务业务设计：产品结构，产品交付和支撑过程链，企业级数据模型，组织结构，业务知识定义不同的过程视图交付给0级的业务活动。过程被组织的方法： 过程执行过程执行的观点：展示标准的端到端过程，如实施开通等 功能的观点：如：客户关系管理等。爆破法分解过程级爆破法分解过程级LEVEL 2Level 2中心过程，中心过程结合在一起交付服务流和其他端到端流程what-中心过程中心过程, who-交付单位交付单位，IT部或SI,HOW-产品产品参

24、考行业标准参考模型；定义模型：业务数据定义，系统构成；定义业务角色。公认的端到端子过程： 通常在一个业务单位或业务线一个业务单位或业务线内实现的 定义那些传递业务竞争优势的活动。象明显的来自于支撑的过程。 通常的被看作价值链的模型。中心过程包含的祥细任务被定义在3级业务流程里爆破法分解过程级爆破法分解过程级LEVEL 3Level 3业务流程，中心过程分解成详细的“成功模式”的业务流程，完成任务。what-流程流程, who-团队团队，HOW-系统系统设计详细过程；分配业务角色；确定支撑的系统，数据流。映射业务数据模型到系统数据模型。考虑失败路线；排队和瓶颈。定义2级中心过程的流程： 由任务组

25、成 通常一般地定义（不是某个特殊的产品，客户，地区的运营等） 常常仅展示正常的场景，不包含选择性行动、失败和错误恢复的细节如果需要，任务在4级操作流程里被更详细的分解。业务事件分解事件列表业务事件分解事件列表事件来源业务流程触发响应目的地客户来营业厅客户来营业厅缴费缴费营业人员营业人员缴费缴费缴费请求缴费请求收款并打印收据收款并打印收据客户客户。销帐销帐。事件列表要达到对业务事件进行梳理和说明的目的，业务事件是业务流程业务事件是业务流程的触发器，同时业务流程可分解为业务活动的触发器，同时业务流程可分解为业务活动，这种分解关系是DFD业务过程分解的本质，也体现了事件驱动业务过程分析事件驱动业务过

26、程分析的特点。事件列表可作为一个过程文档，在最终规划文档中不体现明确系统范围过程分解梳理事件列表DFD建模业务建模方法业务建模方法DFD概述概述DFD是一种图形化的过程建模工具。它通过4个基本要素：外部实体、数据流、过程和数据存储描述了系统中数据的流动和数据的变化，它强调的是数据流和处理过程。DFD 基本符号也称也称“处处理或处理理或处理”明确系统范围过程分解梳理事件列表DFD建模DFD 建模建模采用Chris Gane and Trish Sarson符号体系DFD的过程必须是本质处理过程。描述数据流不描述控制流；本质处理过程描述“做什么（what to do)”,而并不用关心“如何做（ho

27、w to do)”.父图与子图的平衡。子图的输入输出数据流同父图相应加工的输入输出数据流必须一致 分解的程度：一般不超过7个本质变化包括： 计算 进行决策 数据分流 数据合并 数据过滤或综合产生新的数据流。过程的命名 详细处理过程（以动词开头客体） 高层处理过程（名词词组） 能够描述系统中流动的数据的组成，数据流和物流分开 给每一个处理一个标号 ，处理之间不要试图让数据流图反映处理的顺序。明确系统范围过程分解梳理事件列表DFD建模DFD建模数据字段建模数据字段(DD)业务过程列表业务过程列表明确系统范围过程分解梳理事件列表DFD建模DFD建模数据字段建模数据字段(DD)数据实体列表数据实体列表

28、明确系统范围过程分解梳理事件列表DFD建模目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法 数据建模理论 模型分析方法应用架构建模方法技术架构设计方法数据建模理论数据建模理论对需求调研所得到对需求调研所得到数据的高层的抽象数据的高层的抽象描述。描述。ERER模型模型数据字典数据字典数据流图数据流图第1步：需求调研需求调研第2步：概念分析概念分析第3步：逻辑设计逻辑设计确定客户需要哪些信息，确定客户需要哪些信息，建立哪些应用，常用的建立哪些应用，常用的操作及对象有哪些等操作及对象有哪些等。将概念模型映射为某个将概念模型映射为某个特定类型的特定类型的DBMSDBMS模式模式数据。数据。

29、数据建模过程数据建模过程对已经确定的逻辑结对已经确定的逻辑结构选择适当的物理结构选择适当的物理结构，包括存储结构、构，包括存储结构、存取路径、存储分配存取路径、存储分配等等。第4步：物理设计物理设计流水作业概念逻辑物理业务管理实现数据工作DFD工作验证工作数据模型数据流图DFD利用业务流程校验功能、属性、数据流校验完善数据模型校验完善DFD业务人员或需求工作业务事件、信息收集概念逻辑物理业务管理实现功能功能功能实体属性CRU实体属性RRU实体属性CDC业务概念描述事件活动描述人员Who范围分析What方法hoW从企业角度，分析业务概念和事件活动功能数据校验任务类别流水作业3X3建模过程3X3矩

30、阵各阶段：概念矩阵各阶段：概念-逻辑逻辑-物理物理34目的目的交付交付要素要素概念概念分析分析用IT语言表达现实世界问题空间(信息模型)1、目标及业务定位2、概念ERD3、概念DFD4、CRUD校验5、业务场景验证利用业务活动逐步分解确定业务概念确定业务概念之间的联系确定业务概念关键属性确定业务值域逻辑逻辑设计设计设计支持现实世界概念模型的逻辑模式和子模式(外模式)1、定位图2、逻辑ERD3、逻辑DFD4、CRUD校验5、业务场景验证逻辑块之间的聚合关系将ERD转化为关系模式对实体和处理进行归纳抽象对实体和处理逐层细化逻辑实体和处理定义物理物理设计设计根据DBMS特点和处理的需要，进行物理存储

31、安排，形成内模式1、物理ERD2、物理DFD3、功能结构图4、集成架构图5、技术架构图设计UI/系统接口设计数据存储(内存/文件/DB)设计索引等性能参数设计异常处理及系统管理设计其他技术实现细节3X3矩阵各层面：业务矩阵各层面：业务-管理管理-实现实现纵向分为业务、管理、实现业务、管理、实现三个层面，这是业务角度上的划分，它们之间是一种并列关系，但是它们之间互相联系，只是它们各自关注的角度不同业务 处理核心业务事件核心业务事件(RUP:直接使客户受益的活动) 该类业务活动的某环节一旦停止，业务即不能正常开展管理 处理为了使业务运转的更好所增加的管理活动，主要分以下两类： 一类是对活动本身的管

32、理本身的管理，既规则管理规则管理 另一类是对活动结果的管理结果的管理，如经营分析经营分析实现 处理为了使核心业务流程能够正常运转所需要开展的辅助活动辅助活动 如：异常处理，支持与就绪，与参与人的交互等353X3矩阵各层面：概念逻辑物理矩阵各层面：概念逻辑物理概念模型设计 是整个数据架构设计的关键，通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。 概念模型是从业务的视角业务的视角对企业运营过程中涉及的信息的结构化描述信息的结构化描述，是技术中立的模型逻辑模型设计 对概念分析阶段中牵涉的业务，抽象出处理功能，并逐步细化，以达到能在系统中实现。 逻辑模型是从解决方案的角度解

33、决方案的角度对数据的结构化数据的结构化描述；是技术相对中立的模型物理模型设计 对逻辑设计中的功能与实体进一步细化，使功能/数据能在具体的系统中实现 物理模型是结合具体的DBMS等技术选择，考虑系统的可实现性、性能、接口等因素，在逻辑数据模型基础上进一步细化设计的模型目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法 数据建模理论 模型分析方法应用架构建模方法技术架构设计方法概念模型分析概念模型分析定义概念模型是从业务的视角对企业运营过程中涉及的信息的结构化描述，是技术中立的模型目标用IT语言表达现实世界问题空间：分析出所有的业务实体所有的业务实体，定义业务概念，阐述清楚实体之间的基本

34、关系实体之间的基本关系方法初步划分业务活动范围寻找业务活动范围中的业务实体并描述定义分析并描述业务实体之间的关系实体之间的关系从属关系分析处理关系分析管理关系分析分析并描述业务实体关键属性分析属性所对应的业务值域业务场景校验、CRUD校验38逻辑模型分析逻辑模型分析定义 逻辑模型是从解决方案的角度对数据的结构化描述；是技术相对中立的模型目标 设计支持现实世界概念模型的逻辑模式和子模式(外模式) 对概念分析阶段中牵涉的业务，抽象出处理功能，并逐步细化，以达到能在系统中实现方法 在概念分析的基础上划定系统边界 去掉仅仅代表业务，而不需要应用系统实现的实体和处理去掉仅仅代表业务，而不需要应用系统实现

35、的实体和处理 将模型转化为关系模式将模型转化为关系模式 将模型中相近的实体和处理进行归纳抽象，消除冗余归纳抽象，消除冗余 引入设计层面所需要的实体引入设计层面所需要的实体和处理，并逐层细化 设计实体类的属性设计实体类的属性，设计相关的值域，确定实体类的候选标识并进一步确定主标识，建立与属性相关的业务规则 定义逻辑实体和处理 业务场景校验、CRUD校验39逻辑模型设计方法逻辑模型设计方法转化为数据模型关系规范化模式优化设计用户子模式物理设计阶段概念模型:(E-R模型)逻辑设计阶段概念设计阶段逻辑模型(关系模型)带主属性的ER图与具体DBMS无关：表、键、索引及视图等，确定完整性约束1：1，M：N

36、等关系的转化范式化完整性约束完 善 实体属性逻辑模型设计模型转换逻辑模型设计模型转换实体的转换概念层面的实体可直接转成逻辑实体根据实体类、关联关系存在的相似性，进行适当层次的抽象，形成更为通用的概念；实体的归纳和细化将模型中相近的实体进行归纳抽象，消除冗余。归纳是一个由多到少的过程，目的是要达到模型与业务的无关性，实现数据模型的稳定持续发展引入设计层面所需要的实体，然后对系统开展的活动进一步细化，使得处理功能越来越逼近于函数的实现形式；细化是一个由少到多的过程，细化的目标是完善实体和功能关系的转换：若实体间联系是1:1，可以在两个实体类型转换成的两个实体中任意一个实体的属性中加入另一个实体的标

37、识和联系类型（如层级关系）的属性。 若实体间联系是1:N，则在N端实体转换成的实体中加入1端实体的键和联系类型的属性。若实体间联系是M:N，则将联系也转换成实体，其属性为两端实体的标识加上联系的属性，而标识为两端实体标识的组合。属性的转换概念层面的实体属性可直接带到逻辑实体中，补充类型和长度等描述逻辑设计阶段逻辑设计阶段3NF3NF约束约束范式化规范化的目的是使数据模型有更好的结构，控制和减少数据冗余控制和减少数据冗余，符合关系数据库的设计规则。规范化的目标是保证只有一个途径来知道一个事实。关系数据库的一个目的是最大化数据完整性，保证数据的准确性，而实现这一目的的重要方法就是让每个概念在数据库

38、中只出现在一个地方让每个概念在数据库中只出现在一个地方（外键约束除外），如果同时存在多个地方，就会存在数据不一致的隐患，导致对数据完整性的破坏。规范模型的过程是删除模型结构中那些多种途径来了解相同事实删除模型结构中那些多种途径来了解相同事实的模型结构。三范式第一范式要求实体的每个属性的值都是原子的每个属性的值都是原子的，并且必须有单一的含义。第二范式要求符合第一范式后，实体的每一个非键值（每一个非键值（KeyKey）属性）属性都必须完全依赖于整个键值，而不是键值的一部分都必须完全依赖于整个键值，而不是键值的一部分。第三范式要求符合第二范式后，实体的每一个非键值属性都不能依每一个非键值属性都不能

39、依赖其它非键值属性赖其它非键值属性。物理模型设计物理模型设计定义 物理模型是结合具体的DBMS等技术选择，考虑系统的可实现性、性能、接口等因素，在逻辑数据模型基础上进一步细化设计的模型目标 根据DBMS特点和处理的需要，进行物理存储等安排，形成内模式 对逻辑设计中的功能与实体进一步细化，使功能/数据能在具体的系统中实现方法 设计UI/系统接口 考虑性能，进行反规范化设计考虑性能，进行反规范化设计 设计数据存储(内存/文件/DB) 设计索引、视图、分区、存储参数等性能参数 引入具体实现层面所需要的实体和处理，并细化引入具体实现层面所需要的实体和处理，并细化 设计程序异常处理及系统管理 设计其他技

40、术实现细节 场景校验、CRUD校验43目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法系统框架分析方法系统框架分析方法UC矩阵矩阵U/C矩阵分析是在业务流程、数据流程及数据分析的基础上，为了整体地考虑系统的功能子系统系统的功能子系统和数据资源的合理分布而进行的系统化的分析方法U/C矩阵是结构划系统分析方法中，用来表达过程与数据两者之间的关系过程与数据两者之间的关系的方法。矩阵中的列表示数据类，行表示过程，并以字母U（Use）和C（Create）来表示过程对数据类的使用和产生。U/C矩阵是一种用关系数据矩阵进行系统分析方法，并对其存储、正确性检验、表上

41、作业等做了分析，同时利用结果关系进行了子系统划分利用结果关系进行了子系统划分 U/C矩阵是一张表格。它可以表数据/功能系统化分析的结果。它的左边第一列列出过程的名称，上面第一行列出数据类的名称。表中在各过程与数据类的交叉处，填写过程与数据类的关系。 U/C矩阵的建立矩阵的建立用矩阵表实现用矩阵表实现行表示过程行表示过程列表示数据类列表示数据类在行列交叉处填充在行列交叉处填充U/CU/CC表示表示这类表示表示这类数据由相应功能数据由相应功能产生产生表示这类功能表示这类功能使用相应的数据使用相应的数据类类U/C矩阵使用方法矩阵使用方法U/C矩阵的校验矩阵的校验完备性校验完备性校验一致性校验一致性校

42、验无冗余校验无冗余校验完备性校验：完备性校验：一个数据项必须有一个C和至少一个U；一个功能则必须U/C一致性：一致性：一个数据项必须且只能有一个C无冗余校验无冗余校验: UC矩阵中不允许有空行和空列U/C矩阵的求解矩阵的求解调整表中的行或列，调整表中的行或列，使使“C”C”元素尽量地朝元素尽量地朝对角线靠近对角线靠近求解就是对系统结构求解就是对系统结构划分的优化过程。划分的优化过程。系统划分应相互相独系统划分应相互相独立且高内聚立且高内聚系统划分系统划分在在U/CU/C矩阵中，沿对矩阵中，沿对角线划矩形，每个矩角线划矩形，每个矩形即为子系统形即为子系统矩阵既不能重叠也不矩阵既不能重叠也不能漏掉

43、数据和功能项能漏掉数据和功能项所有的所有的CC必须包含在矩必须包含在矩阵中阵中矩阵内的数据项为本矩阵内的数据项为本系统需要处理的数据系统需要处理的数据矩阵外的矩阵外的U表示各个系表示各个系统之间的数据交互统之间的数据交互DFDDD系统系统框架框架UC矩阵使用过程矩阵使用过程U/CU/C矩阵的建立矩阵的建立用表的行和列分别记录下数据类和过程。表中功能与数据类交叉点上的符号表示这类数据由相应功能产生，表示这类功能使用相应的数据类 U/CU/C矩阵正确性校验矩阵正确性校验完备性校验：完备性校验：指对具体的数据项必须有一个产生者（C）和至少一个使用者（U），功能则必须有产生或使用（U或C）发生一致性校

44、验：一致性校验：指对具体的数据项必须有且仅有一个产生者（C）无冗余校验无冗余校验: :指 UC矩阵中不允许有空行和空列U/CU/C矩阵的求解矩阵的求解 UC 矩阵的求解就是对系统结构划分的优化过程。它是基于子系统划分应相互相对独立且内部凝聚性高这一原则之上的一种聚类操作。 UC 矩阵的求解过程常通过表上作业法来完成。其具体操作方法是：调整表中的行变量或列变量，使得“C”元素尽量地朝对角线靠近，然后再以“C”元素为标准，划分子系统。系统功能划分与数据资源分布系统功能划分与数据资源分布在求解后的UC 矩阵中划出一个个的方块，每一个小方块即为一个子系统。建立建立U/C矩阵矩阵列表示数据列表示数据列表

45、示过程列表示过程C表示此过程创表示此过程创建此数据建此数据U表示此过程使表示此过程使用此数据用此数据无冗余校验无冗余校验!不允许有空行不允许有空行!一致性校验一致性校验!有有2个个C完备性校验完备性校验!数据项只有数据项只有U没有没有C完备性校验完备性校验!数据项只有数据项只有C没有没有U完备性校验完备性校验!过程没有过程没有U也没有也没有CU/C矩阵的求解矩阵的求解调整列，使调整列，使“C”元素尽量元素尽量地朝对角线靠近地朝对角线靠近高内聚高内聚子系统的划分子系统的划分矩形划分子系统矩形划分子系统所有的所有的C必须在矩必须在矩形中形中数据交互数据交互系统间的数据交互系统间的数据交互子系统的划

46、分的原则子系统的划分的原则n相对独立性相对独立性 子系统或模块相对独立,尽量减少各种不必要的数据调用和控制联系尽量减少各种不必要的数据调用和控制联系,并将联系比较密切、功能近似的模块相对集中n系统之间数据的依赖性尽量小系统之间数据的依赖性尽量小子系统之间的联系要尽量减少,接口要简单、明确。一个内部联系强的子系统对外部的联系必然很少,所以划分时应将联系较多者列入子系统内部。n数据冗余尽量小数据冗余尽量小n管理发展的需要管理发展的需要必须兼顾组织机构的要求，能够符合现有的情况和人们的习惯习惯。n 便于系统分阶段实现便于系统分阶段实现子系统的划分应能适应这种分期分步的实施分步的实施。n资源的充分利用

47、资源的充分利用考虑有利于各种设备资源在开发过程中的搭配使用,考虑到各类信息资源的合理分布和充分使用应用架构交付模板应用架构交付模板-系统应用功能框架系统应用功能框架目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法 参考模型 集成架构 技术架构NGOSS 设计思路设计思路业务流程+业务规则+功能+数据业务规则+ 功能+数据业务流程功能+数据业务流程业务规则用例流程策略契约传统模式传统模式SOA业务领域应用系统NGBSS 方法论NGBSS企业企业ITIT架构模式架构模式最最大大限限度度满满足足客客户户需需求求变变化化四个分离：四个分离： 1.功能和数据分

48、离；2.功能和规则分离；3.功能和流程分离；4.界面和功能分离；横向整合的平台化、专业化横向整合的平台化、专业化5656逐步面向逐步面向SOA技术架构体系的策略方向技术架构体系的策略方向 56 流 程烟囱式烟囱式第1级基础服务化基础服务化第4级复合服务化复合服务化 第5级虚拟服务化虚拟服务化第6级第7级灵活可配置灵活可配置的服务的服务组件化组件化第 3级 集成化集成化第2级模块基础服务基于服务的流程集成灵活的应用软件集合构件对象应用软件结构化分析与设计面向服务建模面向服务建模面向语法建模基于构件开发面向对象设计方法面向功能面向服务面向服务面向服务面向功能面向功能 业务角度面向服务面向服务建模基

49、于服务的 流程集成特定平台特定平台技术兼容灵活感应特定平台特定平台基础架构 单一架构基础的SOA网格化的SOA灵活可配置的架构基于构件架构分层架构系统架构SOA平台无关IT系统基本实现集成化目标系统基本实现集成化目标. 在未来的在未来的3-5年内需实现基于基础服务的初步年内需实现基于基础服务的初步SOA体系架构进一步实体系架构进一步实现融合集中的现融合集中的ITp公司目前处于集成化向组件化的成熟过程，向服务化发展。TMF-TNA与与DIOANGOSS-TNA基于DIOA DIOA:是一种面向组件的设计方法。服务提供者通过接口向服务消费者提供功能，而服务提供者和服务消费者在架构上可能是分布式的。

50、 参考其概念层次模型，定义了三类组件：框架服务组件框架服务组件、托管服务组件托管服务组件和业务服业务服务组件务组件。其中，框架服务和托管服务对应DIOA的框架服务。 定义了三类容器：应用，组件，服务。三者是向后包含关系。TNA架构定义 运算视角定义了NGOSS组件组件，定义了组件间交互方式组件间交互方式。 工程视角定义组件的内部核心对象、契约实例、接口对象从核心对象间关系核心对象间关系、契约对象间消息传输与操作调用契约对象间消息传输与操作调用和中间件以及中间件协议中间件以及中间件协议三个层次定义组件间交互。DIOA分层框架分层框架functional blockcomponentcontrac