第7章企业架构之架构建模 _软件开发管理

PPT 内容
PPT 图集

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

第7章企业架构之架构建模

关键词

相关PPT

第7章 企业架构之架构建模

关键词

相关PPT

第7章企业架构之架构建模