架构规划方法架构规划方法研究院研究院20102010 目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法 培训目的培训目的p能力提升能力提升 分析能力提升 规划能力提升p技技术管理管理统一规划方法指导统一架构表述模式p业界界发展展对未来规划逐步重视对研发过程逐步重视 目录目录目的架构建模方法总论–联邦企业架构－FEAF–FEAF建模语言业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法 FEAF理论基础理论基础制定机构--联邦企业体系结构框架( Federal Enterprise Architecture Framework , FEAF) 是美国国家信息技术委员会(Chief Information 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 Enterprise 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协会框架协会框架业务驱动业务驱动设计驱动设计驱动标准标准技术技术应用应用数据数据安全安全投资评审投资评审分层协调分层协调市场研究市场研究组件管理组件管理变迁过程变迁过程架构驱动架构驱动愿景愿景战略方向战略方向原则原则 分层架构模型分层架构模型 业务架构业务架构数据架构数据架构应用架构应用架构技术架构技术架构数据架构数据架构应用架构应用架构技术架构技术架构架构架构架构架构现状现状目标目标业务架构业务架构业务架构业务架构数据架构数据架构应用架构应用架构技术架构技术架构联邦架构框架联邦架构框架 –– Level Level III 架构细分架构细分 FEAFFEAF架构说明架构说明设计架构现状–数据架构 ： 定义业务支撑数据现状，也就是数据模型。
–应用架构现状： 定义业务功能现状，也就是应用模型–技术架构现状：定义应用和数据管理实现技术现状，也就是技术模型设计架构目标–数据架构 ： 定义业务支撑数据目标，也就是数据模型–应用架构现状： 定义业务功能目标，也就是应用模型–技术架构现状：定义目标应用和数据管理的实现技术，也就是技术模型设计模型–数据模型：定义企业概念–应用模型：定义控制数据的应用–技术模型：定义当前和目标技术架构细分–整个企业范围内的业务域，如果将一个业务域纳入联邦框架管理的投资回报率为正，那该域就回被纳入联邦框架，其架构信息和模型将被记录在架构仓库中迁移过程：支撑当前架构向目标架构迁移的过程–IT投资规划与决策：基于投资预算、投资回报率等标准进行评价–投资管理评审：对架构信息进行投资评审–域架构协调：协调域架构，实现统一联邦架构，落实配置管理与工程变更控制–市场调研：进行新技术的市场调研，进行技术更新–组件管理：基于联邦架构进行企业基础设施的管理–采购：架构及其它迁移过程需要的采购–架构治理：避免混乱、误解与重做标准：所有标准、指南与最佳实践–安全标准–数据标准：应用于数据、元数据及相关结构–应用标准：应用于应用软件–技术标准：应用于操作系统和平台 FEAF LEVEL 4视角数据架构(实体=what)应用架构(活动=how)技术架构(位置=where)规划者视角（目标/范围）业务对象列表业务过程列表业务分布(场所)列表所有者视角（企业模型）语义模型业务过程模型业务支撑系统系统设计者视角（信息系统模型）逻辑数据模型应用架构系统物理部署架构承包商视角（技术模型）物理数据模型系统设计技术架构分包商视角（详细规范）数据定义程序“支撑软件组件(比如操作系统)”网络架构 FEAF LEVEL 4说明说明规划者视角：从总体上描述最终结构规模、形态、及局部间关系。
即系统范围的估计所有者视角：是业务人员的视角，由架构师设计的企业模型，描述业务实体、业务过程及其关系设计者视角：系统分析师的视角，定义数据元素，逻辑过程流及功能构建者视角：承包商的视角，架构师的规划需要在这里转换成面向建设者的模型需要足够的细节去确定对工具、原料及技术的限制，在这里需要形成技术模型，使信息系统与具体的编程语言、IO设备或特定支撑技术联系起来分包商视角：根据详细规范提供模块或组件，组件可由是编程人员开发，也可以是已有的cots产品 目录目录目的架构建模方法总论–联邦企业架构-FEAF–FEAF建模语言业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法 FEAF 建模语言参考建模语言参考IDEF0&IDEF3，，DFDIDEF1，，IDEF1x，，ERUML（用例图、组件图、序列图、状态图等）（用例图、组件图、序列图、状态图等）The Open Group ArchitectureFramework Format, TOGAF Format业务架构业务架构信息架构信息架构应用架构应用架构技术架构技术架构注：注：FEA推荐软件建模工具厂商Popkin software提供 IDEF方法体系简介方法体系简介简介：IDEF是由美国空军发明的用于描述企业内部运作的一套建模方法，经过改造后用途变广泛了，适用于一般的软件开发。
IDEF的16套方法（最常使用的是IDEF0～IDEF4 ）–IDEF0：功能建模（Function Modeling），类似数据流图DFD–IDEF1：信息建模（Information Modeling）–IDEF1X：数据建模（Data Modeling），类似实体-关系图ER–IDEF2：仿真建模设计（Simulation Model Design）–IDEF3：过程描述获取（Process Description Capture），类似业务流程图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 Modeling） 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已经获得了业界的认同常用UML图–用例用例图：用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求功能需求–类图：类图表示不同的对象象如何彼此相关；换句话说，它显示了系系统的静的静态结构构–序列序列图 ：序列图显示具体用例具体用例（或者是用例的一部分）的详细流程流程它几乎是自描述的，并且显示了流程中中不同不同对象之象之间的的调用关系用关系–状状态图：状态图表示某个某个类所处的不同状不同状态和该类的状态转换信息每个类都有状态，但不是每个类都应该有一个状态图–活活动图：活动图表示在处理某个活某个活动时，两个或者更多更多类对象象之间的过程控程控制流制流活动图最适合用于对较高级别的过程建模，比如公司当前在如何运作业务，或者业务如何运作等–组件件图 ：组件图提供系统的物理视图它的用途是显示系统中的软件件对其他其他软件件组件（例如，件（例如，库函数）的依函数）的依赖关系关系 –部署部署图：部署图表示该软件系统如何部署到硬件环境中它的用途是显示该系统不同的不同的组件将在何件将在何处物理地运行，以及它物理地运行，以及它们将如何彼此通信将如何彼此通信 The Open Group Architecture Framework, TOGAF简介简介来源–TOGAF的开发始于1995年，基于美国国防部的TAFIM框架（ 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) ，是一个架构资产的虚拟仓库，包含TOGAF基础架构（Foundation Architecture ）及集成信息基础设施参考模型（Integrated Information Infrastructure Reference Model ，III-RM)–PART IV资源(Resources) ，一系列应用TOGAF及ADM的工具和技术 交付交付操作方法操作方法架构建模操作方法及交付架构建模操作方法及交付DFD图图DDCDMLDM/PDM系统功能框架系统功能框架系统数据交互系统数据交互技术无关框架技术无关框架技术相关框架技术相关框架集成架构集成架构EAP物理部署图物理部署图方法：为达到某种目的而采取的途径、步骤、手段方法：为达到某种目的而采取的途径、步骤、手段 目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法 事件驱动过程建模事件驱动过程建模-结构化方法（结构化方法（SA)建模建模事件和事件表事件和事件表事物事物实体－联系图实体－联系图E-RE-R环境图环境图DFDDFD数据字典数据字典DDDD过程说明过程说明( (判定树判定树/ /表）表）分析分析设计设计实施实施编程工具编程工具测试工具测试工具结构图结构图系统流程图系统流程图关系数据库模式关系数据库模式用户界面用户界面表单表单/ /报表报表系统控制系统控制伪码伪码业务架构业务架构 业务建模过程业务建模过程明确系统范围过程分解梳理事件列表DFD建模绘制上下文图绘制上下文图明确明确系统与环系统与环境的主要接口境的主要接口将将系统分解成系统分解成逻辑子系统或逻辑子系统或业务过程业务过程，形，形成过程分解图。
成过程分解图至少要分解到至少要分解到活动或用例级活动或用例级（即可（即可由一个由一个岗位独立完成岗位独立完成的任务的任务）过程分解图可过程分解图可作为过程文档作为过程文档不做输出不做输出以事件列表的以事件列表的形式描述事件形式描述事件的的触发器、响触发器、响应、来源、目应、来源、目的的等信息除事件列表外，除事件列表外，还可绘制事件还可绘制事件自身的自身的DFDDFD 事件列表和事事件列表和事件件DFDDFD是过程文是过程文档，可不输出档，可不输出绘制绘制0 0、、1 1、、2 2……等级别的等级别的DFDDFD图图，，并输出数据字典并输出数据字典数据字典以数据字典以业务业务过程列表过程列表和和实体实体列表列表表达 明确系统范围－上下文图明确系统范围－上下文图在分解过程中，首先构造的是系统的上下图（CONTEXT DIAGRAM)，上下文图是一个最高层次的数据流程图，它将““业务业务””视之为一个黑视之为一个黑盒上下文图定义了“产品”的外部环境和范围上下文图说明了业务的外部实体业务的外部实体（external entity)以及业务与这些外部实体之间的数据交换，即业务与其外部实体之间的接口业务与其外部实体之间的接口。
在上下文图中，不描述业务内部的情况，因此，整个业务用一个过程来表示上下文图只有一张，图中的加工也只有一个，所以不必编号 明确系统范围过程分解梳理事件列表DFD建模 业务过程分解－爆破法过程分解业务过程分解－爆破法过程分解企业活动企业活动目标目标运营管理运营管理WhatWho(role)HowLevel 0业务活动业务活动Level 1过程分组过程分组Level 2中心过程中心过程Level 3业务流程业务流程Level 4操作流程操作流程Level 5详细流程详细流程业务业务物主身份物主身份过程分组过程分组产品产品交付单位交付单位中心过程中心过程系统系统交付团队交付团队 任务任务流程流程系统功能系统功能角色角色 步骤步骤子流程子流程交易交易详细角色详细角色 操作操作详细流程详细流程模型结构模型结构,方法和建模标准方法和建模标准定义业务活动定义业务活动辨别辨别操作的客户操作的客户经营和战略过程经营和战略过程导向导向展示相关的展示相关的业务功能集业务功能集和和标准的端到端服务流程标准的端到端服务流程中心过程中心过程结合在一起结合在一起交付服务流交付服务流和和其他端到端流程其他端到端流程中心过程分解成详细中心过程分解成详细的的“成功模式成功模式”的业务流程的业务流程有有错误条件、产品和地点错误条件、产品和地点的的操作流程操作流程进行必须的进行必须的详细操作的分解详细操作的分解业 务 级过 程 级操 作 级明确系统范围过程分解梳理事件列表DFD建模 爆破法分解－业务级爆破法分解－业务级LEVEL 0Level 0业务活动，定义业务活动，辨别操作的客户，经营和战略过程导向what-企企业活活动, who-目目标，HOW-运运营管理管理确定和定义模型：业务目标，价值流，环境和财务的约束；支持业务运营和产品线的管理。
这些业务目标的过程和系统解决方案的交付 爆破法分解－业务级爆破法分解－业务级LEVEL 1Level 1过程分组，展示相关的业务功能集和标准的端到端服务流程what-过程分程分组, who-物主身份即物主身份即业务拥有者有者，可理解为业务部门，HOW-业务设计：产品结构，产品交付和支撑过程链，企业级数据模型，组织结构，业务知识定义不同的过程视图交付给0级的业务活动过程被组织的方法：–过程程执行行的观点：展示标准的端到端过程，如实施开通等–功能的观点：如：客户关系管理等 爆破法分解－过程级爆破法分解－过程级LEVEL 2Level 2中心过程，中心过程结合在一起交付服务流和其他端到端流程what-中心中心过程程, who-交付交付单位位，IT部或SI,HOW-产品品参考行业标准参考模型；定义模型：业务数据定义，系统构成；定义业务角色公认的端到端子过程：–通常在一个一个业务单位或位或业务线内实现的–定义那些传递业务竞争优势的活动象明显的来自于支撑的过程–通常的被看作价值链的模型中心过程包含的祥细任务被定义在3级业务流程里 爆破法分解－过程级爆破法分解－过程级LEVEL 3Level 3业务流程，中心过程分解成详细的“成功模式”的业务流程，完成任务。
what-流程流程, who-团队，HOW-系系统设计详细过程；分配业务角色；确定支撑的系统，数据流映射业务数据模型到系统数据模型考虑失败路线；排队和瓶颈定义2级中心过程的流程：–由任务组成–通常一般地定义（不是某个特殊的产品，客户，地区的运营等）–常常仅展示正常的场景，不包含选择性行动、失败和错误恢复的细节如果需要，任务在4级操作流程里被更详细的分解 业务事件分解－事件列表业务事件分解－事件列表事件来源业务流程触发响应目的地客户来营业厅客户来营业厅缴费缴费营业人员营业人员缴费缴费缴费请求缴费请求收款并打印收据收款并打印收据客户客户 销帐销帐 •事件列表要达到对业务事件进行梳理和说明的目的，业务事件是业务流程业务事件是业务流程的触发器，同时业务流程可分解为业务活动的触发器，同时业务流程可分解为业务活动，这种分解关系是DFD业务过程分解的本质，也体现了事件驱动业务过程分析事件驱动业务过程分析的特点•事件列表可作为一个过程文档，在最终规划文档中不体现明确系统范围过程分解梳理事件列表DFD建模 业务建模方法－业务建模方法－DFD概述概述DFD是一种图形化的过程建模工具它通过4个基本要素：外部实体、数据流、过程和数据存储描述了系统中数据的流动和数据的变化，它强调的是数据流和处理过程。
DFD 基本符号也称也称“处处理或处理理或处理”明确系统范围过程分解梳理事件列表DFD建模 DFD 建模建模采用Chris Gane and Trish Sarson符号体系DFD的过程必须是本质处理过程描述数据流不描述控制流；本质处理过程描述“做什么（what to do)”,而并不用关心“如何做（how to do)”.父图与子图的平衡子图的输入输出数据流同父图相应加工的输入输出数据流必须一致 分解的程度：一般不超过7个本质变化包括：–计算–进行决策–数据分流–数据合并–数据过滤或综合产生新的数据流过程的命名–详细处理过程（以动词开头＋客体）–高层处理过程（名词词组）–能够描述系统中流动的数据的组成，数据流和物流分开–给每一个处理一个标号 ，处理之间不要试图让数据流图反映处理的顺序明确系统范围过程分解梳理事件列表DFD建模 DFD建模－数据字段建模－数据字段(DD)业务过程列表业务过程列表明确系统范围过程分解梳理事件列表DFD建模 DFD建模－数据字段建模－数据字段(DD)数据实体列表数据实体列表明确系统范围过程分解梳理事件列表DFD建模 目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法–数据建模理论–模型分析方法应用架构建模方法技术架构设计方法 数据建模理论数据建模理论 对需求调研所得到对需求调研所得到数据的高层的抽象数据的高层的抽象描述。
描述ERER模型模型数据字典数据字典数据流图数据流图第1步：需求调研需求调研第2步：概念分析概念分析第3步：逻辑设计逻辑设计确定客户需要哪些信息，确定客户需要哪些信息，建立哪些应用，常用的建立哪些应用，常用的操作及对象有哪些等操作及对象有哪些等将概念模型映射为某个将概念模型映射为某个特定类型的特定类型的DBMSDBMS模式数模式数据数据建模过程数据建模过程对已经确定的逻辑结对已经确定的逻辑结构选择适当的物理结构选择适当的物理结构，包括存储结构、构，包括存储结构、存取路径、存储分配存取路径、存储分配等等第4步：物理设计物理设计 流水作业概念逻辑物理业务管理实现数据工作DFD工作验证工作数据模型数据流图DFD利用业务流程校验功能、属性、数据流校验完善数据模型校验完善DFD业务人员或需求工作业务事件、信息收集概念逻辑物理业务管理实现功能功能功能实体属性CRU实体属性RRU实体属性CDC业务概念描述事件活动描述人员Who范围分析What方法hoW从企业角度，分析业务概念和事件活动功能数据校验任务类别流水作业3X3建模过程 3X3矩阵各阶段：概念矩阵各阶段：概念-逻辑逻辑-物理物理34目的目的交付交付要素要素概念概念分析分析用IT语言表达现实世界问题空间(信息模型)1、目标及业务定位2、概念ERD3、概念DFD4、CRUD校验5、业务场景验证利用业务活动逐步分解•确定业务概念•确定业务概念之间的联系•确定业务概念关键属性•确定业务值域逻辑逻辑设计设计设计支持现实世界概念模型的逻辑模式和子模式(外模式)1、定位图2、逻辑ERD3、逻辑DFD4、CRUD校验5、业务场景验证•逻辑块之间的聚合关系•将ERD转化为关系模式•对实体和处理进行归纳抽象•对实体和处理逐层细化•逻辑实体和处理定义物理物理设计设计根据DBMS特点和处理的需要，进行物理存储安排，形成内模式1、物理ERD2、物理DFD3、功能结构图4、集成架构图5、技术架构图•设计UI/系统接口•设计数据存储(内存/文件/DB)•设计索引等性能参数•设计异常处理及系统管理•设计其他技术实现细节 3X3矩阵各层面：业务矩阵各层面：业务-管理管理-实现实现纵向分为业务、管理、、管理、实现三个层面，这是业务角度上的划分，它们之间是一种并列关系，但是它们之间互相联系，只是它们各自关注的角度不同业务–处理核心核心业务事件事件(RUP:直接使客户受益的活动)–该类业务活动的某环节一旦停止，业务即不能正常开展管理–处理为了使业务运转的更好所增加的管理活动，主要分以下两类：–一类是对活动本身的管理本身的管理，既规则管理管理–另一类是对活动结果的管理果的管理，如经营分析分析实现–处理为了使核心业务流程能够正常运转所需要开展的辅助活助活动–如：异常处理，支持与就绪，与参与人的交互等35 3X3矩阵各层面：概念－逻辑－物理矩阵各层面：概念－逻辑－物理概念模型设计–是整个数据架构设计的关键，通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。
–概念模型是从业务的视角业务的视角对企业运营过程中涉及的信息的结构化描述信息的结构化描述，是技术中立的模型逻辑模型设计–对概念分析阶段中牵涉的业务，抽象出处理功能，并逐步细化，以达到能在系统中实现–逻辑模型是从解决方案的角度解决方案的角度对数据的结构化数据的结构化描述；是技术相对中立的模型物理模型设计–对逻辑设计中的功能与实体进一步细化，使功能/数据能在具体的系统中实现–物理模型是结合具体的DBMS等技术选择，考虑系统的可实现性、性能、接口等因素，在逻辑数据模型基础上进一步细化设计的模型 目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法–数据建模理论–模型分析方法应用架构建模方法技术架构设计方法 概念模型分析概念模型分析定义–概念模型是从业务的视角对企业运营过程中涉及的信息的结构化描述，是技术中立的模型目标–用IT语言表达现实世界问题空间：分析出所有的业务实体所有的业务实体，定义业务概念，阐述清楚实体之间的基本关系实体之间的基本关系方法–初步划分业务活动范围–寻找业务活动范围中的业务实体并描述定义–分析并描述业务实体之间的关系实体之间的关系从属关系分析处理关系分析管理关系分析–分析并描述业务实体关键属性–分析属性所对应的业务值域–业务场景校验、CRUD校验38 逻辑模型分析逻辑模型分析定义–逻辑模型是从解决方案的角度对数据的结构化描述；是技术相对中立的模型目标 –设计支持现实世界概念模型的逻辑模式和子模式(外模式)–对概念分析阶段中牵涉的业务，抽象出处理功能，并逐步细化，以达到能在系统中实现方法–在概念分析的基础上划定系统边界–去掉仅仅代表业务，而不需要应用系统实现的实体和处理去掉仅仅代表业务，而不需要应用系统实现的实体和处理–将模型转化为关系模式将模型转化为关系模式–将模型中相近的实体和处理进行归纳抽象，消除冗余归纳抽象，消除冗余–引入设计层面所需要的实体引入设计层面所需要的实体和处理，并逐层细化–设计实体类的属性设计实体类的属性，设计相关的值域，确定实体类的候选标识并进一步确定主标识，建立与属性相关的业务规则–定义逻辑实体和处理–业务场景校验、CRUD校验39 逻辑模型设计方法逻辑模型设计方法带主属性的ER图与具体DBMS无关：表、键、索引及视图等，确定完整性约束1：1，M：N等关系的转化范式化完整性约束完善实体属性 逻辑模型设计－模型转换逻辑模型设计－模型转换实体的转换–概念层面的实体可直接转成逻辑实体–根据实体类、关联关系存在的相似性，进行适当层次的抽象，形成更为通用的概念；实体的归纳和细化–将模型中相近的实体进行归纳抽象，消除冗余。
归纳是一个由多到少的过程，目的是要达到模型与业务的无关性，实现数据模型的稳定持续发展–引入设计层面所需要的实体，然后对系统开展的活动进一步细化，使得处理功能越来越逼近于函数的实现形式；细化是一个由少到多的过程，细化的目标是完善实体和功能关系的转换：–若实体间联系是1:1，可以在两个实体类型转换成的两个实体中任意一个实体的属性中加入另一个实体的标识和联系类型（如层级关系）的属性 –若实体间联系是1:N，则在N端实体转换成的实体中加入1端实体的键和联系类型的属性–若实体间联系是M:N，则将联系也转换成实体，其属性为两端实体的标识加上联系的属性，而标识为两端实体标识的组合属性的转换–概念层面的实体属性可直接带到逻辑实体中，补充类型和长度等描述 逻辑设计阶段－逻辑设计阶段－3NF3NF约束约束范式化–规范化的目的是使数据模型有更好的结构，控制和减少数据冗余控制和减少数据冗余，符合关系数据库的设计规则–规范化的目标是保证只有一个途径来知道一个事实关系数据库的一个目的是最大化数据完整性，保证数据的准确性，而实现这一目的的重要方法就是让每个概念在数据库中只出现在一个地方让每个概念在数据库中只出现在一个地方（外键约束除外），如果同时存在多个地方，就会存在数据不一致的隐患，导致对数据完整性的破坏。
–规范模型的过程是删除模型结构中那些多种途径来了解相同事实删除模型结构中那些多种途径来了解相同事实的模型结构三范式–第一范式要求实体的每个属性的值都是原子的每个属性的值都是原子的，并且必须有单一的含义–第二范式要求符合第一范式后，实体的每一个非键值（每一个非键值（KeyKey）属性）属性都必须完全依赖于整个键值，而不是键值的一部分都必须完全依赖于整个键值，而不是键值的一部分–第三范式要求符合第二范式后，实体的每一个非键值属性都不能依每一个非键值属性都不能依赖其它非键值属性赖其它非键值属性 物理模型设计物理模型设计定义–物理模型是结合具体的DBMS等技术选择，考虑系统的可实现性、性能、接口等因素，在逻辑数据模型基础上进一步细化设计的模型目标–根据DBMS特点和处理的需要，进行物理存储等安排，形成内模式–对逻辑设计中的功能与实体进一步细化，使功能/数据能在具体的系统中实现方法–设计UI/系统接口–考虑性能，进行反规范化设计考虑性能，进行反规范化设计–设计数据存储(内存/文件/DB)–设计索引、视图、分区、存储参数等性能参数–引入具体实现层面所需要的实体和处理，并细化引入具体实现层面所需要的实体和处理，并细化–设计程序异常处理及系统管理–设计其他技术实现细节–场景校验、CRUD校验43 目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法 系统框架分析方法－系统框架分析方法－UC矩阵矩阵U/C矩阵分析是在业务流程、数据流程及数据分析的基础上，为了整体地考虑系统的功能子系统系统的功能子系统和数据资源的合理分布而进行的系统化的分析方法U/C矩阵是结构划系统分析方法中，用来表达过程与数据两者之间的关系过程与数据两者之间的关系的方法。
矩阵中的列表示数据类，行表示过程，并以字母U（Use）和C（Create）来表示过程对数据类的使用和产生U/C矩阵是一种用关系数据矩阵进行系统分析方法，并对其存储、正确性检验、表上作业等做了分析，同时利用结果关系进行了子系统划分利用结果关系进行了子系统划分 U/C矩阵是一张表格它可以表数据/功能系统化分析的结果它的左边第一列列出过程的名称，上面第一行列出数据类的名称表中在各过程与数据类的交叉处，填写过程与数据类的关系 U/C矩阵的建立矩阵的建立用矩阵表实现用矩阵表实现行表示过程行表示过程列表示数据类列表示数据类在行列交叉处填充在行列交叉处填充U/CU/CC表示表示这类表示表示这类数据由相应功能数据由相应功能产生产生Ｕ表示这类功能Ｕ表示这类功能使用相应的数据使用相应的数据类类U/C矩阵使用方法矩阵使用方法U/C矩阵的校验矩阵的校验完备性校验完备性校验一致性校验一致性校验无冗余校验无冗余校验完备性校验：完备性校验：一个数据项必须有一个C和至少一个U；一个功能则必须U/C一致性：一致性：一个数据项必须且只能有一个C无冗余校验无冗余校验: U／C矩阵中不允许有空行和空列U/C矩阵的求解矩阵的求解调整表中的行或列，调整表中的行或列，使使““C C””元素尽量地朝元素尽量地朝对角线靠近对角线靠近求解就是对系统结构求解就是对系统结构划分的优化过程。
划分的优化过程系统划分应相互相独系统划分应相互相独立且高内聚立且高内聚系统划分系统划分在在U/CU/C矩阵中，沿对角矩阵中，沿对角线划矩形，每个矩形线划矩形，每个矩形即为子系统即为子系统矩阵既不能重叠也不矩阵既不能重叠也不能漏掉数据和功能项能漏掉数据和功能项所有的所有的C C必须包含在矩必须包含在矩阵中阵中矩阵内的数据项为本矩阵内的数据项为本系统需要处理的数据系统需要处理的数据矩阵外的矩阵外的U表示各个系表示各个系统之间的数据交互统之间的数据交互DFDDD系统系统框架框架 UC矩阵使用过程矩阵使用过程U/CU/C矩阵的建立矩阵的建立用表的行和列分别记录下数据类和过程表中功能与数据类交叉点上的符号Ｃ表示这类数据由相应功能产生，Ｕ表示这类功能使用相应的数据类 U/CU/C矩阵正确性校验矩阵正确性校验完备性校验：完备性校验：指对具体的数据项必须有一个产生者（C）和至少一个使用者（U），功能则必须有产生或使用（U或C）发生一致性校验：一致性校验：指对具体的数据项必须有且仅有一个产生者（C）无冗余校验无冗余校验: :指 U／C矩阵中不允许有空行和空列U/CU/C矩阵的求解矩阵的求解 U／C 矩阵的求解就是对系统结构划分的优化过程。
它是基于子系统划分应相互相对独立且内部凝聚性高这一原则之上的一种聚类操作 U／C 矩阵的求解过程常通过表上作业法来完成其具体操作方法是：调整表中的行变量或列变量，使得“C”元素尽量地朝对角线靠近，然后再以“C”元素为标准，划分子系统系统功能划分与数据资源分布系统功能划分与数据资源分布在求解后的U／C 矩阵中划出一个个的方块，每一个小方块即为一个子系统 建立建立U/C矩阵矩阵列表示数据列表示数据列表示过程列表示过程C表示此过程创表示此过程创建此数据建此数据U表示此过程使表示此过程使用此数据用此数据无冗余校验无冗余校验!不允许有空行不允许有空行!一致性校验一致性校验!有有2个个C完备性校验完备性校验!数据项只有数据项只有U没有没有C完备性校验完备性校验!数据项只有数据项只有C没有没有U完备性校验完备性校验!过程没有过程没有U也没有也没有C U/C矩阵的求解矩阵的求解调整列，使调整列，使“C”元素尽量元素尽量地朝对角线靠近地朝对角线靠近高内聚高内聚 子系统的划分子系统的划分矩形划分子系统矩形划分子系统所有的所有的C必须在矩必须在矩形中形中 数据交互数据交互系统间的数据交互系统间的数据交互 子系统的划分的原则子系统的划分的原则n相对独立性相对独立性 子系统或模块相对独立,尽量减少各种不必要的数据调用和控制联系尽量减少各种不必要的数据调用和控制联系,并将联系比较密切、功能近似的模块相对集中n系统之间数据的依赖性尽量小系统之间数据的依赖性尽量小子系统之间的联系要尽量减少,接口要简单、明确。
一个内部联系强的子系统对外部的联系必然很少,所以划分时应将联系较多者列入子系统内部n数据冗余尽量小数据冗余尽量小n管理发展的需要管理发展的需要必须兼顾组织机构的要求，能够符合现有的情况和人们的习惯习惯n 便于系统分阶段实现便于系统分阶段实现子系统的划分应能适应这种分期分步的实施分步的实施n资源的充分利用资源的充分利用考虑有利于各种设备资源在开发过程中的搭配使用,考虑到各类信息资源的合理分布和充分使用 应用架构交付模板应用架构交付模板-系统应用功能框架系统应用功能框架 目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法–参考模型–集成架构–技术架构 NGOSS 设计思路设计思路业务流程+业务规则+功能+数据业务规则+ 功能+数据业务流程功能+数据业务流程业务规则用例流程策略契约传统模式传统模式SOA业务领域应用系统NGBSS 方法论NGBSS企业企业ITIT架构模式架构模式最最大大限限度度满满足足客客户户需需求求变变化化•四个分离：四个分离： 1.功能和数据分离；2.功能和规则分离；3.功能和流程分离；4.界面和功能分离；•横向整合的平台化、专业化横向整合的平台化、专业化 5656逐步面向逐步面向SOA技技术架构体系的策略方向架构体系的策略方向 56流程烟囱式第1级基础服务化第4级复合服务化第5级虚拟服务化第6级第7级灵活可配置的服务组件化第3级集成化第2级模块基础服务基于服务的流程集成灵活的应用软件集合构件对象应用软件结构化分析与设计面向服务建模面向服务建模面向语法建模基于构件开发面向对象设计方法面向功能面向服务面向服务面向服务面向功能面向功能业务角度面向服务面向服务建模基于服务的流程集成特定平台特定平台技术兼容灵活感应特定平台特定平台基础架构单一架构基础的SOA网格化的SOA灵活可配置的架构基于构件架构分层架构系统架构SOA平台无关IT系统基本实现集成化目标. 在未来的3-5年内需实现基于基础服务的初步SOA体系架构进一步实现融合集中的ITp公司目前处于集成化向组件化的成熟过程，向服务化发展。
TMF-TNA与与DIOANGOSS-TNA基于DIOA–DIOA:是一种面向组件的设计方法服务提供者通过接口向服务消费者提供功能，而服务提供者和服务消费者在架构上可能是分布式的–参考其概念层次模型，定义了三类组件：框框架架服服务务组组件件、托托管管服服务务组组件件和业业务务服服务组件务组件其中，框架服务和托管服务对应DIOA的框架服务–定义了三类容器：应用，组件，服务三者是向后包含关系TNA架构定义–运算视角定义了NGOSS组件组件，定义了组件间交互方式组件间交互方式–工程视角定义组件的内部核心对象、契约实例、接口对象从核心对象间关系核心对象间关系、契约对象间消息传输与操作调用契约对象间消息传输与操作调用和中间件以及中间件协议中间件以及中间件协议三个层次定义组件间交互 DIOA分层框架分层框架functional blockcomponentcontractService end pointBasic Technology DIOA概念模型说明概念模型说明业务模型层（Business Model）：关注业务应用业务应用的设计与实现业务应用由一系列组件实现服务工程层(Service Engineering)：关注组件的建模。
包括接口、协议及规范等服务框架层(Service Framework)：关注提供框架服务接口与对象的建模如：命名服务、事件服务等该层提供框架服务类组件基础技术层(Basic Technologies)：关注中间件与基础技术的建模，采用中立的语言描述 TMF技术中立架构（技术中立架构（TNA)详细视图详细视图 共享信息组件注册服务注册锲约注册锲约实例注册流程规则仓库仓库位置服务位置服务Contract inst.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服务服务Contract inst.Int.Mech服务服务Contract inst.Int.Mech遗留应用遗留应用 TOGAF TRM TRM 层次分析层次分析应用软件层–业务应用–基础框架应用应用平台层－应用组件框架–图形–用户交互–数据交互–数据管理–国际化操作–位置目录–安全–传输处理–软件工程管理–系统与网络管理通讯基础框架应用平台接口–应用软件与应用平台层间的接口通讯基础设施接口–应用平台层 与通讯基础设施层间的接口3个层次个层次2类接口类接口 DIOA与与TRM结合结合多层体系：通讯层、应用平台、业务应用、展示层多个分离：应用与数据、应用与流程、流程与规则、功能与展示架构特征：专业化、平台化、组件化接口特征：集中化、通用化、层次化、标准化、开放性 目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法–参考模型–集成架构–技术架构 集成技术定义集成技术定义数据集成数据集成–数据集成通过直接访问应用系统所创建、维护并储存的相应信息来实现应用系统间的数据重用和同步，一般不涉及业务逻辑。
数据集成主要用于实现批量数据传输和数据同步实现批量数据传输和数据同步、数据转换和统一数据视图等功能要求应用集成应用集成–应用集成是指应用系统之间业务逻辑调用系统之间业务逻辑调用的要求，在程序代码级别上通过应用系统间的接口实现集成应用系统提供具备一定业务含义的系统接口，同时也使用其他系统提供的系统接口适合于同步非实时与异步类型接口集成要求–服务集成是指符合一定技术标准规范的应用集成服务集成是指符合一定技术标准规范的应用集成流程集成流程集成–流程集成是在应用集成和数据集成的基础上，利用流程管理系统把各应用系统暴露出来的应用利用流程管理系统把各应用系统暴露出来的应用/ /数数据接口据接口，根据业务流程的要求进行流程定制进行流程定制，达到业务流程与具体应用系统分离的目的，并且依靠流程管理产品的强大功能获得业务流程可灵活配置，可实时监控的优势，为跨系统的端到端业务流程提供流程调度、自动化执行和灵活调整的能力界面集成界面集成–界面集成主要是将企业内部系统的访问界面集中起来访问界面集中起来，实现统一的用户界面视图，用户无需在多个系统之间来回切换用户界面集成主要应用企业信息门户来实现 接口技术选型参考接口技术选型参考 表格说明：表格说明：1、批量：、批量：★（数据量<10k），★★：（10k<数据量<1M），★★★(数据量>1M)2、业务量：、业务量：★(业务量<5千/日)，★★(5千/日<业务量<5万/日)，★★★(业务量>5万/日) 集成平台选择参考集成平台选择参考以下场景适合用点到点集成技术：–接口传递的数据固定数据固定，不需要复杂的数据逻辑转换–所属的业务只涉及两个系统只涉及两个系统，且不依赖别的接口也不被别的接口依赖–非实时的接口非实时的接口，可以在特定时间传送大量的数据大量的数据以下场景适用平台集成技术–所属的业务交易需要在多个系统多个系统中传递同样的交易内容。
–所属的业务需要各系统间的多次交互多次交互，并且这些交互需要系统自动控制流程顺序自动控制流程顺序 集成架构模版示例集成架构模版示例-集成总体视图集成总体视图 集成架构交付模版－接口列表集成架构交付模版－接口列表序号序号源系统源系统目的系统目的系统交互内容交互内容集成方式集成方式技术方式技术方式同同/ /异步异步1 1综合客服综合客服计费帐务计费帐务产品产品, ,用户订购信用户订购信息息数据集成数据集成数据库表数据库表异步异步2 2综合客服综合客服服务开通服务开通定单定单流程集成流程集成工作流工作流异步异步3 3综合客服综合客服服务激活服务激活业务信息业务信息数据集成数据集成数据库表数据库表异步异步4 4综合客服综合客服决策支持决策支持业务数据业务数据数据集成数据集成文件文件异步异步9 9网络资源管理网络资源管理综合客服综合客服资源信息资源信息数据集成数据集成数据库表数据库表同步同步1010网络资源管理网络资源管理服务开通服务开通资源信息资源信息数据集成数据集成数据库表数据库表异步异步1111网络资源管理网络资源管理决策支持决策支持业务数据业务数据数据集成数据集成文件文件异步异步1212网络资源管理网络资源管理服务激活服务激活资源信息资源信息数据集成数据集成数据库表数据库表异步异步1313服务开通服务开通服务激活服务激活工单工单流程集成流程集成工作流工作流异步异步1414服务激活服务激活外部网元外部网元接口指令接口指令应用集成应用集成socketsocket同步同步1515统一接口统一接口综合客服系统综合客服系统业务受理，缴费充业务受理，缴费充值信息，客户值信息，客户资料资料数据集成数据集成数据库表数据库表异步异步1616统一接口统一接口专业网管专业网管接口信息接口信息数据集成数据集成数据库表数据库表异步异步1717统一接口统一接口其他系统其他系统接口信息接口信息数据集成数据集成数据库表数据库表异步异步181810060/112/11410060/112/114统一接口统一接口业务受理业务受理, ,查询信查询信息息数据集成数据集成数据库表数据库表异步异步 目录目录目的架构建模方法总论业务架构建模方法数据架构建模方法应用架构建模方法技术架构设计方法–参考模型–集成架构–技术架构 技术中立架构技术中立架构TNATNA(TNA(technology neutral architecture)是一个基于组件的、分布是一个基于组件的、分布式的、支持灵活的业务流程部署的、易于集成应用系统的、与技术无关的式的、支持灵活的业务流程部署的、易于集成应用系统的、与技术无关的NGOSSNGOSS系统框架体系。
系统框架体系NGOSSNGOSS中定义中定义TNATNA应遵循以下标准：应遵循以下标准：ü分布式面向接口结构；分布式面向接口结构；ü技术中立的组件模型；技术中立的组件模型；ü业务流程与组件实现相分离；业务流程与组件实现相分离；ü安全使能架构；安全使能架构；ü策略使能架构；策略使能架构；ü共享信息模型与数据环境；共享信息模型与数据环境；ü分布透明性；分布透明性； 技术架构参考模版技术架构参考模版-技术中立架构技术中立架构 技术相关架构技术相关架构TSATNA对系统分层体系结构及各层组件功能作了规范在此基础上对系统分层体系结构及各层组件功能作了规范在此基础上将各层组件的实现技术进行规范则形成了技术相关架构将各层组件的实现技术进行规范则形成了技术相关架构（（Technology Specific Architecture））技术相关架构对技术的选用原则是尽量使用行业标准的技术框技术相关架构对技术的选用原则是尽量使用行业标准的技术框架（比如支持分布式运算，面向组件的架构，面向服务的架构架（比如支持分布式运算，面向组件的架构，面向服务的架构等）等） 技术架构参考模版技术架构参考模版-技术相关架构技术相关架构 讨论讨论Q ？？A 。