国家电网公司信息系统架构设计指南(试行)

系统概要设计 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 国家电网公司 信息系统架构设计指南 2011年11月 目 录 11 适用范围 12 规范性引用文件 13 参照遵从 34 编写流程和职责 45 需求开发设计 45.1 需求调研 65.2 需求 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 85.3 用户体验设计 126 系统概要设计 126.1 系统总体框架设计 146.2 业务能力视图设计 156.3 系统功能视图设计 156.4 系统数据视图设计 176.5 系统组件视图设计 196.6 系统集成视图设计 216.7 系统逻辑部署视图设计 226.8 系统物理部署视图 246.9 系统安全视图设计 277 附录 277.1 软件需求规格说明书编写内容 277.2 概要设计编写内容 图 表 2图表 1 系统架构遵从 3图表 2 编写流程和职责 11图表 3 界面原型设计样例 24图表 4 系统安全防护控制点 表 格 2 表格 关于规范使用各类表格的通知入职表格免费下载关于主播时间做一个表格详细英语字母大小写表格下载简历表格模板下载 1 系统架构遵从清单 5表格 2 需求调研执行角色表 6表格 3 系统用例示例1 7表格 4 系统用例示例2 8表格 5 需求分析执行角色 9表格 6 用户信息 9表格 7 可用性需求 11表格 8 用户体验设计执行角色 12表格 9 应用类型优缺点分析 13表格 10 应用类型典型实现技术 13表格 11 架构决策分类 14表格 12 系统总体框架设计执行角色 17表格 13 系统数据视图设计执行角色 19表格 14 系统组件视图设计执行角色 21表格 15 系统集成视图设计执行角色 22表格 16 系统逻辑部署视图设计 23表格 17 系统物理部署视图执行角色 24表格 18 应用安全设计要点 25表格 19数据安全设计要点 27表格 21 软件需求规格说明书各类系统编写内容 27表格 22 概要设计各类系统编写内容 国家电网公司信息系统架构设计指南 1　 适用范围 本指南定义了国家电网公司信息系统建设中开展需求开发、概要设计工作应遵循的原则、方法, 是国家电网公司信息系统建设的指导性文件。本指南适用于国家电网公司总部、分部,以及省（自治区、直辖市）电力公司和公司其它全资企业、控股企业、直属事业单位、信息系统责任研发单位。 本指南适用于国家电网所有信息化系统，包括定制开发类业务系统、套装软件类业务系统以及平台类系统，各系统需要编写内容参见本指南附录。 2　 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 —— 《国家电网公司应用软件集成设计规范》 —— 《国家电网公司软硬件目标架构设计规范》 —— 《国家电网公司应用软件非功能性需求规范》 —— 《信息系统全生命周期安全管控之安全设计规范》 —— 《国家电网公司应用软件架构设计规范》 3　 参照遵从 系统架构设计应该遵从总体架构，具体遵从关系如下图所示： 图表 1 系统架构遵从 详细信息如下： 表格 1 系统架构遵从清单 总体架构 系统架构 遵从形态 业务架构-业务职能 需求开发-业务职能 遵从 业务架构-组织单元 需求开发-组织单元 细化 业务架构-业务流程 需求开发-业务流程 遵从、细化 业务架构-业务活动 需求开发-业务活动 细化 业务架构-业务步骤 需求开发-业务步骤 细化 业务架构-业务信息 需求开发-业务信息 细化 应用架构-应用 需求开发-系统功能规格-系统功能 遵从、细化 应用架构-功能 需求开发-系统功能规格-系统用例 遵从、细化 应用架构-交互 需求开发-系统功能规格-系统用例 遵从、细化 技术架构-系统 系统概要设计-系统组件 遵从、细化 数据架构-数据实体 系统概要设计-数据模型 遵从、细化 数据架构-属性 系统概要设计-数据模型 细化 技术架构-集成场景 系统概要设计-集成场景 遵从、细化 技术架构-平台组件 系统概要设计-集成设计 遵从、细化 技术架构-位置 系统概要设计-物理部署 细化 4　 编写流程和职责 图表 2 编写流程和职责 注：可以通过缩放word文档查看编写流程和相关职责。 系统架构设计主要涵盖软件工程的需求开发阶段以及概要设计阶段，包含需求调研、需求分析、用户体验设计以及概要设计。 业务需求文档由业务部门负责组织进行编写并发布；项目组负责编写软件需求工作说明书、用户体验设计以及系统概要设计文档，信息化部门负责组织进行评审、发布。 系统架构设计指南用于指导需求开发和概要设计阶段的分析设计活动。各项目组应遵循该指南，采用对应的软件需求规格说明书模板以及概要设计模板进行分析设计。对于大型项目，完成用户体验设计，可单独成册；对于小型项目，不要求进行用户体验设计。 详细设计阶段，各项目组根据系统的特点采用针对性的详细设计方法，基于概要设计开展详细设计并编写详细设计文档，本系统架构设计指南不对详细设计进行约束。 整个流程可根据项目的具体情况决定是否需要进行迭代。如需求存在较多不确定性时，可在需求编制和需求开发两个阶段采用多轮迭代的方式去梳理需求。 5　 需求开发设计 5.1　 需求调研 5.1.1　 调研目标 通过对业务需求报告的分析理解或直接与业务部门调研的方式，获取业务部门的需求信息。 说明：业务需求报告由业务部门负责，主要描述了信息化项目所覆盖的业务范围、关键业务场景、约束和规则、以及相关系统建设范围的说明。软件需求规格说明书是基于业务需求报告，由系统设计人员以软件工程约定的规范描述方式，分析并记录系统的功能和非功能需求，为系统概要设计提供输入。 调研粒度的说明： 1. 对于业务流程，要明确流程中每个活动，以及每个活动所对应的组织单元和执行角色； 2. 对应业务活动，要明确其操作步骤或需要实现的业务功能点； 3. 对业务功能，要逐级划分子功能，直到每个子功能点具有明确的业务输入信息和业务输出信息； 4. 对于执行角色，要梳理出所有业务活动和业务功能中的执行角色；对于组织单元，要覆盖所有业务活动和业务功能中的对应组织； 5. 对于业务信息，明确其业务含义和数据的属性（包括但不限于数据的类型、长度、取值范围和业务规则等）。 5.1.2　 调研输入 —— 客户相关需求； —— 业务需求报告； —— 总体架构蓝图； 5.1.3　 调研步骤 5.1.3.1　 确定业务目标 定义本项目的业务目标是什么，以及本项目的业务范围。 5.1.3.2　 梳理业务流程 梳理本项目涉及到的业务流程，描述每个流程包含哪些业务活动、流程属于什么业务职能。如果需求不涉及业务流程逻辑，则不进行描述。如一体化平台不涉及业务流程逻辑，不用描述。 梳理业务流程可以参考如下要点： —— 以业务为主线梳理业务流程，确定本项目涉及到的业务流程清单，明确业务流程的父级流程及所属的业务职能； —— 针对每个业务流程需要确定以下问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 ： · 包含哪些业务活动/子流程？ · 活动的先后关系是什么？从一个活动到另一个活动的条件是什么？ · 每个活动的责任主体（角色或组织单元）是谁？ · 每个活动的类型（比如：人工、系统等）？ —— 明确以上问题后，通过跨职能流程图或者EPC(事件驱动流程，Event-driven Process Chain)图描述业务流程。其中跨职能流程图应遵循BPMN规范。 5.1.3.3　 确定业务活动 描述每个业务活动的具体业务步骤、输入\输出业务信息、业务规则及涉及到的非功能性需求。 确定业务活动可以参考如下要点： —— 明确每个业务活动的业务功能； —— 针对每个业务活动需要确定以下问题： · 每个活动的具体步骤/业务规则是什么？ · 每个活动的输入和输出业务信息是什么？业务信息应在《软件需求规格说明书》的“4.6业务信息”章节中描述，并将其业务信息的编号记录在当前的业务活动中 · 每个活动的责任主体对本环节中业务信息的操作是什么（新建、删除、修改、读取）？ 5.1.3.4　 确定业务功能 此处的业务功能是在需求调研阶段由用户直接提供的业务功能列表， 专门针对不在特定业务流程中的业务功能进行编写。与前面业务流程的描述形成互补，都作为系统功能规格分析的输入。后面系统功能规格中的系统功能清单中应该涵盖本章节描述的业务功能，从而保证系统功能规格中的系统功能清单始终保持完整的全部功能点。 确定业务功能可以参考以下要点： —— 按照父功能点包含子功能点的方式绘制功能层级图来展示功能点之间的层级关系； —— 用表格的形式列出所有的顶级功能点清单； —— 对每个顶级功能点，分析拆解出子功能点，并以章节的形式列出所有的子功能点； —— 以此类推，对所有可以分解的功能点进行层层拆分，逐级深化。直至每个功能点都可以明确地得出输入的业务信息和输出的业务信息。 5.1.3.5　 确定执行角色 收集本项目涉及到的所有角色，描述角色的职责。 根据“5.1.3.2梳理业务流程”章节中涉及到的角色，整理形成本项目的角色清单。 5.1.3.6　 确定组织单元 收集本项目涉及到的所有组织单元（包括客户、供应商），描述各部门的职责。 确定组织单元可以参考如下要点： —— 根据“5.1.3.2梳理业务流程”章节中涉及到的组织单元，整理形成本项目的组织单元清单； —— 基于组织单元清单，调研形成组织单元的组织结构图。 5.1.3.7　 确定业务信息 收集本项目涉及到的所有业务信息。业务信息包括表单、报表、文档等业务信息，及这些业务信息的内容。 确定业务信息可以参考如下要点： —— 业务信息有两个来源。一是从“5.1.3.3确定业务活动”章节中梳理出来的；二是从“5.1.3.4确定业务功能” 章节中梳理出来的。经过归集整理后，形成本项目的业务信息清单。每个业务信息都应该有业务信息编号，并应该将编号记录在其来源处，即业务活动或业务功能中。 —— 针对每个业务信息，确定具体的信息内容； —— 确定业务信息的校验规则（如不能为空）； 5.1.4　 调研输出 —— 《软件需求规格说明书》的第四章节“业务描述”。 5.1.5　 执行角色 表格 2 需求调研执行角色表 角色 负责 执行 询问 通知 客户与最终用户 √ √ 需求分析人员 √ √ 系统设计人员 √ 5.2　 需求分析 5.2.1　 分析目标 根据需求调研结果，对用户需求进行分析归纳，确定系统需要实现的功能和非功能需求。通过系统用例模型描述系统的功能需求，使之成为在开发全过程中研讨系统需求和进行系统设计的依据，在软件测试阶段作为系统测试的基础。 需求分析粒度的说明： 1. 对于系统用例，要覆盖所有的业务活动，每个用例需明确基本流程和所有备选流程的操作步骤，或者详细标识每个用例的功能点； 2. 对于系统功能点，要逐级划分子功能，直到每个子功能点具有明确的业务输入信息和业务输出信息； 3. 对于技术规格，要对需求调研阶段获得的所有非功能性需求，给出具体的技术规格说明。 5.2.2　 分析输入 —— 《软件需求规格说明书》的第四章节“业务描述” —— 总体架构蓝图 5.2.3　 分析步骤 5.2.3.1　 确定系统用例 系统用例分为两种。一种是按业务步骤进行描述，另一种是按功能进行分解描述。其目的是为了确定系统参与者和系统功能之间是怎么相互联系的。 确定系统用例可以参考如下要点： —— 根据总体架构蓝图及业务需求确定系统边界； —— 基于“5.1.3.3确定业务活动”章节中的业务活动清单，确定涉及到的系统用例清单，明确系统用例的子用例； —— 明确每个用例的描述； —— 针对每个用例需要确定以下问题： · 该用例的前置条件是什么，什么情况下会触发该用例？ · 该用例有哪些参与者？参与者包括使用系统的用户及和系统有交互的其他系统或者子系统； · 该用例中参与者与系统的基本流程和备选流程是怎样的？或者该用例包含哪些子功能？ · 参与者需要读取、产生、删除、修改、存储系统中的什么信息？ · 系统如何响应参与者的操作？ · 该用例的主要界面是什么？ · 该用例的后置条件是什么？ —— 明确以上问题后，通过下面两个表格中的一个来描述系统用例。 表格 3 系统用例示例1 属性 描述 备注 用例名称 用例编号 描述用例的编号 参与者 描述用例的参与者 前置条件 描述用例开始的约束 子功能点 描述业务功能的子功能点 对业务功能可能涉及到的各种场景进行分析整理，得到全部的子功能点。 后置条件 描述用例结束，系统处在什么状态 无论执行的结果如何，用例的后置条件都应为“真”。如果可能出现故障，则应在后置条件内包括“该动作已经完成，或者如果可能出现故障，则不执行该动作”，而不只是“该动作已经完成” 主要界面 展示该用例涉及到的主要界面 非功能性需求 描述该用例有哪些非功能性的需求 抽取出的功能名称列表 从此用例中抽取出来的功能点名称列表 表格 4 系统用例示例2 属性 描述 备注 用例名称 用例编号 描述用例的编号 参与者 描述用例的参与者 前置条件 描述用例开始的约束 基本流程 描述用户和系统交互流程 基本流程描述格式： 1. 每一个步骤都需要用数字编号清楚地标明步骤的先后顺序。 2. 当整个用例模型基本稳定之后，针对每一步骤详细描述参与者和系统之间所发生的交互。建议采用双向(roundtrip)描述法来保证描述的完整性，即每一步骤都需要从正反两个方面来描述:(1)参与者向系统提交了什么信息；(2)对此系统有什么样的响应。 3. 在描述参与者和系统之间的信息交换时，需指出来回传递的具体信息。如：不能只描述参与者输入了客户信息，应确切说参与者输入了客户姓名、客户地址。 备选流程 描述基本流程相关的可选或异常特征的行为，同时也包括基本流程的各种变形 备选流程必须说明以下内容： 1. 基本流程中可以插入备选流程的位置。 2. 为使备选流程开始而需要满足的条件。 3. 系统在该备选流程下会采取哪些动作。 4. 基本流程重新开始的方式和位置，或者用例结束的方式。 后置条件 描述用例结束，系统处在什么状态 无论执行了哪些可选流程，用例的后置条件都应为“真”；它不能只对基本流程为“真”。如果可能出现故障，则应在后置条件内包括“该动作已经完成，或者如果可能出现故障，则不执行该动作”，而不只是“该动作已经完成” 主要界面 展示该用例涉及到的主要界面 非功能性需求 描述该用例有哪些非功能性的需求 抽取出的功能名称列表 从此用例中抽取出来的功能点名称列表 5.2.3.2　 确定系统功能点 收集本项目涉及到的所有系统功能点，描述系统功能点的类型、依赖的功能点、父级功能点及所属的应用。 确定系统功能点可以参考如下要点： —— 根据“5.2.3.1确定系统用例”和“5.1.3.4确定业务功能” 章节，绘制功能层级图，按照父功能点包含子功能点的方式，将所有功能点在一个层级图中展示出来； —— 将所有的顶级功能点以表格的形式制成功能点清单，明确每个系统功能点的功能描述； —— 从顶级功能点开始逐个功能点分析拆解，分章节描绘每个功能点的子功能点清单，直至最底层的功能点可以明确得出其输入的业务信息和输出的业务信息； —— 分析确定功能点之间的依赖关系，此功能点的前置、后置以及交互的功能点称为依赖功能点。 5.2.3.3　 确定技术规格 确定系统在技术层面如何实现系统的非功能性需求。技术规格至少要包含：性能、可靠性、可用性、可扩展性、易用性、安全性及容量规划方面的内容。 系统技术规格必须参照《国家电网公司应用软件非功能性需求规范》的要求进行设计。 系统技术规格中安全相关的规格必须参照《信息系统全生命周期安全管控之安全设计规范》的要求进行设计。 系统技术规格中对系统运行维护提出了相应的需求，应该予以实现。 5.2.4　 分析输出 —— 《软件需求规格说明书》的第五章节“系统功能规格”和第六章节“系统技术规格”。 5.2.5　 执行角色 表格 5 需求分析执行角色 角色 负责 执行 询问 通知 客户与最终用户 √ 需求分析人员 √ √ 系统设计人员 √ √ 5.3　 用户体验设计 5.3.1　 设计目标 根据《软件需求规格说明书》文档内容构造系统界面原型，通过用户使用以验证需求文档内容的完整性和正确性，发现可能存在的质量问题，并为后续系统开发提供输入。 用户体验设计粒度的说明： 1. 实现界面原型。 5.3.2　 设计输入 —— 《软件需求规格说明书》的第五章节“系统功能规格”和第六章节“系统技术规格” 5.3.3　 设计步骤 用户体验设计可以参考如下要点： —— 收集用户信息 用户交互设计要考虑到目标用户的不同引起的交互设计重点的不同，需要通过收集不同类型的用户信息来指导后续的UI设计、可用性设计、功能性设计等，并可以验证用例中的参与者与需求的完整性。 表格 6 用户信息 属性 描述 备注 用户 用户名标识 角色 用户在系统中承担的各个角色 以往经验知识 例如知识领域、计算机技能、教育背景等 物理特征 年龄、性别、语言等 物理环境 文化、环境、技术的接受能力、其他并行使用的系统等 目前工作特征 例如是否出差 —— 评估当前用户体验要求/ 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 通过收集当前用户使用系统的对比数据，分析原有的针对现实的交互流程、已有软件工具的交互流程，找出用户体验的缺点与优点，并结合不同类型用户的交互习惯，以及其希望达到的交互效果，对这些优缺点按用户重要程度与满足程度进行排序。 —— 定义可用性需求 可用性需求的定义是为了使用户接受最终的系统。在定义可用性需求时，需要同样关注目前已有系统的可用性需求特点。 表格 7 可用性需求 类别 属性 描述 备注 交互 定制化 系统可按照用户要求进行定制化，例如字体、屏幕尺寸、颜色等 效率 使用效率，例如键盘、鼠标、快捷方式等 集成 对于分布在多个功能中的流程是否可以自动化执行 导航 用户可以知道目前的功能位置 可预测 操作的结果是否是客户预期的 响应 用户对于系统响应的接受度 显示 可识别 显示的内容是清晰可见的，区别于一般内容的 可理解 用户必须可以理解界面各元素对应的功能。 有意义 对于现实的内容，文字、图表、声音，都是可以被用户理解的，例如是否一目了然，是否有详细说明等 布局 显示元素的摆放是符合逻辑的 一致性 所有的操作、显示的风格一致，形式一致、交互行为一致。 连接/访问 输入方式选择 系统的输入方式是多样的，例如键盘、鼠标、声音、从指定格式导入、从采集工具接入等 输出方式选择 系统可以有可选择的输出方式，例如文字终端输出，界面图形输出，或者图形输出的图标、图像、控制等 —— 选择界面设计标准规范 首先选择界面设计风格，Web、Windows应用、终端文字输出等。 其次定义公共UI元素。例如对于按钮的样式进行统一定义。 最后定义界面设计方法，例如定义显示要求，高亮显示、文字提示等。并描述那些要求是必须遵从的，哪些是可选的。 —— 制定用户界面原型 界面原型着重描述界面元素、布局、页面之间的跳转关系，是确定用户需求的有效手段，为详细设计奠定基础。界面原型定义需要定义如下要素： · 界面元素 定义所有界面元素组件,例如文本框、按钮、下拉框、列表等。 · 界面布局 定义界面中的元素位置布局。 · 界面风格 主要定义界面的美观性和协调性,例如组件大小、颜色、字体等样式。 · 界面易用性 定义界面的易用性，例如输入快捷键、输入方式、提示方式、帮助等。 · 界面跳转 定义界面与界面之间的跳转关系。 · 非功能需求 定义界面性能、自适应要求等。 界面原型示例： 图表 3 界面原型设计样例 —— 用户界面原型验证 通过用户对界面原型的验证，确认界面原型是否支持业务应用，其易用性、美观性等方面是否满足用户要求。 5.3.4　 设计输出 —— 对于大型项目，可单独成册进行编写，对于小型项目可不写。文档命名为《XX系统用户体验设计》。 5.3.5　 执行角色 表格 8 用户体验设计执行角色 角色 负责 执行 询问 通知 客户与最终用户 √ 需求分析人员 √ √ 系统设计人员 √ √ 6　 系统概要设计 6.1　 系统总体框架设计 6.1.1　 设计目标 设计系统总体框架，为后续组件视图、数据视图、集成视图、部署视图、环境视图和安全视图的设计提供指导。设计内容包括：系统设计原则、总体技术路线、架构概览和架构遵从。 总体框架设计粒度的说明： 1. 对于技术路线，要阐明选择的技术路线的技术特点和选型的依据及对系统的影响； 2. 对于架构概览，要明确与此系统相关的所有系统及所处的网络位置（内网、外网）等情况； 3. 对于架构遵从，要标明系统架构中与企业总体架构的四大架构相关的所有元素的对应关系。 6.1.2　 设计输入 确定系统总体框架所需的输入通常应遵循和参考如下架构资产和工作产品： —— 《软件需求规格说明书》的第五章节“系统功能规格”和第六章节“系统技术规格” —— 总体架构蓝图 —— 各种参考架构 6.1.3　 设计步骤 6.1.3.1　 确定设计原则 确定本项目在系统设计时应遵循的相关原则，在后续的所有设计过程中都要考虑这些原则。 6.1.3.2　 确定总体技术路线 确定总体技术路线包括确定系统采用的应用类型、技术路线和架构决策。 确定总体技术路线可以参考如下要点： —— 根据“5.2.3.2确定系统功能点”和“5.2.3.3确定技术规格”章节，分析选择应用类型；可以参照下表选择应用类型： 表格 9 应用类型优缺点分析 应用分层 应用类型 优点 缺点 客户端 Web应用程序 主流企业应用实现方式，具有跨平台UI标准，容易部署和关联变更。 需要在线操作； 相比GUI应用程序用户界面欠丰富。 GUI应用程序 可以充分利用客户端资源； 响应速度快、界面丰富，用户体验好； 可以离线操作。 部署复杂，通常需要借助特定技术完成部署； 对版本管理要求高； 难以跨平台。 RIA应用程序 与富客户端应用相当的用户界面； 支持多媒体和图形显示； 部署简单； 升级和版本管理简单； 可以支持不同平台和不同浏览器。 客户端相比Web应用程序需要更高的配置； 相比于富客户端应用程序，对客户端资源访问有限制； 客户端部署通常需要合适版本运行框架。 移动应用程序 支持手持设备； 适合连线和偶尔连线的场合。 输入和导航限制； 显示区域限制。 服务端 客制化开发 灵活、可以实现个性化的需求； 易于扩展。 开发周期长，需要相当较多的测试来保证质量。 套装软件 预置很多成熟的业务功能； 能快速部署使用。 实现个性化需求相对需要更多的工作量。 其他（可以根据实际情况进行添加） —— 根据选择的应用类型决定所采用的关键技术。可以参照下表决定技术路线： 表格 10 应用类型典型实现技术 应用分层 应用类型 典型实现技术 客户端 Web应用程序 HTML、JSP、FrameWork、Spring等。 GUI应用程序 Java、C++等。 RIA应用程序 Flex、Silverlight、Applet、ExtJs、JQuery、Flash等 移动应用程序 ASP.NET Mobile、Silverlight Mobile等。 服务端 客制化开发 J2EE、.Net等 套装软件 SAP等 —— 确定系统关键设计的架构决策。下表列出了一些常见的架构决策，具体设计时可以根据系统特点进行补充： 表格 11 架构决策分类 分类 架构决策 组件通信 面向服务（SOA）、消息总线（Message Bus）、管道过滤器（Pipes and Filters） 应用部署 客户端/服务器（Client/Server）、3-Tier、N-Tier 领域模型 领域模型(Domain Model)、数据网关（Gateway） 用户交互 模型-视图-控制器(MVC)、模型-视图-呈现（MVP） 应用结构 基于组件（Component-Based）、面向对象（ Object-Oriented）、分层架构（ Layered Architecture） —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容。 6.1.3.3　 确定架构概览 架构概览主要描述系统的上下文关系，包括：本系统与周边系统的关系、各系统所属分区。 确定架构概览可以参考如下要点： —— 根据“5.2.3.1确定系统用例”章节，分析确定和本系统相关的所有的系统清单； —— 获取企业分区信息； —— 确定每个系统的所属分区，一个系统可能分布在多个分区； —— 确定本系统和现存其它系统的关系； —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容。 6.1.3.4　 确定架构遵从 分别从业务架构、应用架构、数据架构和技术架构四个方面，描述系统架构与企业总体架构的遵从情况。 —— 业务架构遵从，“业务架构：业务域”应引用总体架构蓝图业务架构部分的业务域。“系统架构：业务功能”一项仅需逐一列出《软件需求规格说明书》中的第一级业务功能；“业务架构：业务职能”一项需参考总体架构的业务架构部分的业务职能，说明业务功能所对应的业务职能；“遵从说明”一项需描述系统业务功能与业务职能的遵从关系，可选项为：遵从、细化、参照。 —— 应用架构遵从，“应用架构：应用域”一项用于说明本系统设计所对应的应用域；“应用架构：应用”一项用于说明本系统设计所对应的应用，如实现多个应用，需要逐一列出；“系统架构：一级功能”一项仅需逐一列出《软件需求规格说明书》中的第一级系统功能；“应用架构：一级应用功能”一项需说明系统功能所对应的总体架构的应用架构部分中的一级功能；“遵从说明”一项用于描述系统功能与应用功能的遵从关系，可选项为：遵从、细化、参照。 —— 数据架构中，“数据域”和“数据主题”应引用总体架构蓝图数据架构部分的数据域和数据主题。“系统架构：数据实体”一项需逐一列出系统涉及到的数据实体；“数据架构：数据实体”一项需列出总体架构的数据架构部分中对应的数据实体；“遵从说明”一项需描述系统数据实体与总体数据架构中数据实体的遵从关系，可选项为：遵从、细化、参照。 —— 技术架构中，“总体架构：系统名称”应引用总体架构蓝图技术架构部分的系统名称。“集成场景”中的“系统架构：集成场景”一项需逐一列出本系统相关的集成场景；“集成场景”中的“技术架构：集成场景”一项需列出总体技术架构中对应的集成场景；“集成场景”中的“遵从说明”一项需描述系统架构中的集成场景与总体架构的技术架构部分中的集成场景的遵从关系，可选项为：遵从、细化、参照。“产品标准”中的“系统架构：软件产品”一项用于描述系统拟使用的软件产品（如操作系统、数据库、中间件等基础软件）和版本号；“产品标准”中的“技术架构：软件产品”一项用于描述与之对应的总体架构的技术架构部分所列举的软件产品；“产品标准”中的“遵从说明”一项需描述系统架构中的软件产品与总体技术架构中定义的软件产品的遵从关系，可选项为：遵从、细化、参照。 —— 如果蓝图中没有相应设计内容，应遵循架构资产维护流程，提出架构资产修编申请。 6.1.4　 设计输出 —— 《系统概要设计》中的第三章节“系统总体框架” 6.1.5　 执行角色 表格 12 系统总体框架设计执行角色 角色 负责 执行 询问 通知 安全运行人员 √ 架构管控组 √ √ 需求分析人员 √ 系统设计人员 √ √ 6.2　 业务能力视图设计 系统概要设计中的业务能力视图设计是将《软件需求规格说明书》中的4.4章节“业务功能”和4.5章节“业务流程”直接复制过来的。目的是作为后续设计的重要输入。 6.3　 系统功能视图设计 系统概要设计中的系统功能视图是将《软件需求规格说明书》中的第五章节“系统功能”直接复制过来的。目的是作为后续设计的重要输入。 6.4　 系统数据视图设计 6.4.1　 设计目标 根据业务需求，确定支持系统实现的数据实体。设计内容包括：数据模型、数据分类、数据流转和数据存储与分布。 数据视图设计粒度的说明： 1. 对于概念数据模型，应明确概念数据实体之间的关系并明确其所子主题； 2. 对于逻辑数据模型，应明确每个数据实体的属性定义，主键、外键及数据实体之间的对应关系； 3. 对于数据分类，应明确所有逻辑数据实体的分类情况； 4. 对于数据流转，应明确所有系统间交换的数据实体的流转情况； 5. 对于数据的存储与分布，应明确所有数据实体的存储和分布情况。 6.4.2　 设计输入 数据视图设计所需的输入通常应遵循和参考如下架构资产和工作产品： —— 《软件需求规格说明书》的“4.6章节业务信息”和第五章节“系统功能规格” —— 《系统概要设计》的第三章节“系统总体框架”和第七章节“系统组件视图” —— 总体架构蓝图 —— 业务数据标准（包括各种典设成果，比如SG-CIM标准等） —— 已有相关系统的数据模型 —— 行业数据标准：比如IEC CIM标准对模型的完善提供补充 6.4.3　 设计步骤 6.4.3.1　 定义数据模型 数据模型的定义应按照先概念模型后逻辑模型的顺序，设计出数据的逻辑实体模型。总体架构概念数据模型是概念数据模型的重要输入，概念模型再进一步细化成逻辑数据实体的定义和关系，并梳理出数据实体的具体属性，以及描述属性的各参数，包括属性名称、属性编码、属性类型、数据长度、数据精度、是否主键及外键。 定义数据模型可以参考如下要点： —— 根据“5.1.3.7确定业务信息”章节，识别数据实体； —— 确定每个数据实体的属性名称、属性编码、属性类型、数据长度、数据精度、是否主键及外键； —— 分析可应用的业务数据标准，基于该标准对每个数据实体进行调整； —— 确定每个数据实体的所属数据域和数据主题； —— 分析确定数据实体间的关系； —— 根据“5.2.3.1确定系统用例”章节，确定每个方法的输入输出数据实体； —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容； —— 根据“6.1.3.2确定总体技术路线”章节中的技术路线和架构决策检查以上设计内容。 6.4.3.2　 定义数据分类 确定每个数据实体的分类。 定义数据分类可以参考如下要点： —— 根据“6.4.3.1定义数据模型”章节，整理出本项目的所有数据实体清单； —— 针对每个数据实体确定其属于结构化或非结构化实体； —— 针对每个结构化数据实体确定其属于主数据或业务数据； —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容。 —— 根据“6.1.3.2确定总体技术路线”章节中的技术路线和架构决策检查以上设计内容。 可以参考以下内容对数据实体进行分类： —— 按照存储方式可以将数据分为结构化数据和非结构化数据。其中结构化数据分为主数据和业务数据，业务数据分为其他业务基础数据和交易数据。分类关系如下： · 主数据 · 业务数据 · 非结构化数据 6.4.3.3　 定义数据流转 数据流转包括：系统之间的流转、系统和数据中心之间的流转。 定义数据流转可以参考如下要点： —— 根据“6.1.3.3确定架构概览”章节，分析出所有存在交互关系的系统； —— 根据“6.4.3.1定义数据模型”章节，获取所有数据实体清单； —— 针对每个数据实体，根据“5.2.3.1确定系统用例”章节，确定该数据实体是否是数据交换实体。数据交换实体为跨系统边界的数据实体； —— 确定每个数据交换实体的源系统和目标系统； —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容； —— 根据“6.1.3.2确定总体技术路线”章节中的技术路线和架构决策检查以上设计内容。 6.4.3.4　 定义数据存储与分布 确定数据实体的存储与分布。 在系统架构设计中，数据存储指数据实体存储在哪些系统；数据分布指数据在不同系统的存在状态，是所有者或复制者，即O-owner或C-copy。 定义数据存储与分布可以参考如下要点： —— 根据“6.1.3.3确定架构概览”章节，分析出所有存在交互关系的系统； —— 根据“6.4.3.1定义数据模型”章节，获取所有数据实体清单； —— 针对每个数据实体确定其存储的系统，一个数据实体可以存储在多个系统； —— 针对每个数据实体，根据“5.2.3.1确定系统用例”章节，确定该数据实体在这些系统的分布情况； —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容。 —— 根据“6.1.3.2确定总体技术路线”章节中的技术路线和架构决策检查以上设计内容。 6.4.4　 设计输出 —— 《系统概要设计》中的第六章节“系统数据视图” 6.4.5　 执行角色 表格 13 系统数据视图设计执行角色 角色 负责 执行 询问 通知 客户与最终用户 需求分析人员 √ √ 系统设计人员 √ √ 6.5　 系统组件视图设计 6.5.1　 设计目标 把业务需求落实到具体的系统实现。设计内容包括：定义系统的逻辑分层、每一分层包含哪些组件、以及组件的包含依赖关系。 组件设计粒度的说明： 1. 每个组件都需明确其所在的系统分层； 2. 每个组件都需要明确对外的功能方法名称； 3. 每个组件都需要确定与其他组件之间的关联关系； 4. 所有的系统功能都需要有组件与之对应。 6.5.2　 设计输入 系统组件视图设计所需的输入通常应遵循和参考如下架构资产和工作产品： —— 《软件需求规格说明书》的第五章节“系统功能规格”和第六章节“系统技术规格” —— 《系统概要设计》的第五章节“系统功能” —— 《系统概要设计》的第三章节“系统总体框架” —— 总体架构蓝图 —— 各种参考架构 6.5.3　 设计步骤 6.5.3.1　 确定系统逻辑分层 说明系统共有多少逻辑分层，并描述每个层级的职责、实现技术、依赖层级及与该层级的层间通信方式。 确定系统逻辑分层可以参考如下要点： —— 根据“6.1.3.2确定总体技术路线”中确定的技术路线和架构决策，确定系统的逻辑分层； —— 对每层的职责进行描述，确定其实现技术； —— 确定层间调用规则（例如：不能跨层调用），以及通信方式； —— 应该参照《国家电网公司应用软件架构设计规范》的要求，来进行系统的逻辑分层； —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容； —— 根据“6.1.3.2确定总体技术路线”章节中的技术路线和架构决策检查以上设计内容。 6.5.3.2　 定义功能组件 确定系统有哪些功能组件，并描述功能组件包含哪些功能点、可以拆分为哪些组件，这些组件分布在哪些逻辑层级及每个组件开放了哪些方法。 定义功能组件可以参考如下要点： —— 识别组件的常用方法： · 对“5.2.3.2确定系统功能点”章节中梳理出的每个功能点，分析设计出对应的候选功能组件； · 基于对业务流程、活动和业务功能的详细分析，将系统中所有的候选功能组件划分成几个子系统集合； · 再基于高内聚松耦合的原则，对所有组件进行优化重构，使之满足高内聚松耦合的标准。 —— 对每个功能组件进行描述，明确其实现的系统功能点； —— 确定每个功能组件的包含关系，并确定每一功能组件的层级。将每个组件放置到对应的层级中，在功能组件图中表示出来。如果每层放置的组件很多，可以将每一层作为一个图进行绘制； —— 确定每个功能组件开放了哪些方法，包含方法名称和描述； —— 确定每个组件方法可能产生的异常情况及处理办法，包括但不限于： · 反馈给用户的提示信息； · 错误信息的日志记录情况； · 对其他业务的影响。 —— 标示每个功能组件是否接口组件； —— 根据“5.2.3.3确定技术规格”章节，分析确定关键的功能组件的非功能性要求； —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容； —— 根据“6.1.3.2确定总体技术路线”章节中的技术路线和架构决策检查以上设计内容。 6.5.3.3　 定义公共组件 确定系统使用的公共组件，并描述每个公共组件的职责、来源、开放的方法及分布在哪些逻辑层级。 定义公共组件可以参考如下要点： —— 根据“5.2.3.2确定系统功能点”和“5.2.3.3确定技术规格”章节，分析需要的公共组件，整理形成本项目的公共组件清单；公共组件分为可以重用的功能组件和质量属性相关的组件。可以重用的功能组件来自上一节“定义功能组件”中的功能组件清单。可能是清单中的某些组件，也可能是提炼出来的可以为某些功能组件提供服务的组件。这类公共组件所实现的业务逻辑本身一般具有通用性，适用面比较广，而且业务比较成熟稳定，不常修改。而质量属性相关的组件包括但不限于：认证、授权、缓存、并发、事务处理、数据访问、异常处理、日志、监控、验证、工作流等对架构设计有重要影响的技术组件。鉴别这些质量属性相关的组件时，可以从以下几个方面着手：1.从能够提供公共服务的基础设施中发现，如认证、授权等；2.从使用的第三方产品中发现，如日志工具，XML解析器等；3.从技术路线的特点中发现，如某某EJB组件、某某JSF组件、某某COM组件、某某CORBA组件等。 —— 认证、授权、日志、异常处理是四类必备公共组件，认证、授权、异常管理均依赖于日志组件，异常处理组件在确保系统的可靠性和安全性等质量属性方面至关重要，通常需要考虑如下策略：（1）不要向最终用户暴露因异常产生的敏感信息（如数据库连接信息等）；（2）基于第（1）点考虑，采用适当的异常屏蔽策略（异常替换）；（3）系统产生的异常，尤其是关键错误信息应确保记录其错误产生时的原始堆栈信息；（4）设计统一的异常传播策略，明确系统各逻辑层异常记录和传播关系；（5）设计异常记录和通知机制，有助于异常及时发现和系统排错。 —— 对每个公共组件进行描述，说明其职责； —— 确定每个公共组件的层级，如果一个公共组件分布在多个层级，则在公共组件清单中应该分多条记录进行说明。将每个组件放置到对应的层级中，在公共组件图中表示出来。如果每层放置的组件很多，可以将每一层作为一个图进行绘制； —— 确定每个公共组件开放了哪些方法，包含方法名称和描述； —— 确定每个组件方法可能产生的异常情况及处理办法，包括但不限于： · 反馈给用户的提示信息； · 错误信息的日志记录情况； · 对其他业务的影响。 —— 说明每个公共组件的来源。如：企业公共组件库、开源包、产品自带或本次项目自开发； —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容； —— 根据“6.1.3.2确定总体技术路线”章节中的技术路线和架构决策检查以上设计内容。 6.5.3.4　 定义组件依赖 组件依赖描述组件方法间的依赖关系。 定义组件依赖可以参考如下要点： —— 根据“6.5.3.2定义功能组件”章节，确定需要考虑组件依赖的组件清单； —— 针对每个组件，根据“5.2.3.1确定系统用例”章节中的用例描述，确定该组件依赖的组件； —— 绘制组件依赖图，将所有存在依赖关系的组件放置在对应的层级上，并通过带有箭头的虚线将组件间的依赖关系明确表示出来。如一张图不便描述所有组件依赖关系，可以分章节描述； —— 在组件依赖清单的表格中，描述每个组件的依赖关系； —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容； —— 根据“6.1.3.2确定总体技术路线”章节中的技术路线和架构决策检查以上设计内容。 6.5.4　 设计输出 —— 《系统概要设计》中的第七章节“系统组件视图” 6.5.5　 执行角色 表格 14 系统组件视图设计执行角色 角色 负责 执行 询问 通知 客户与最终用户 需求分析人员 √ √ 系统设计人员 √ √ 6.6　 系统集成视图设计 6.6.1　 设计目标 明确本系统与周边系统的集成关系。设计内容包括：明确集成场景、选择集成方式，设计集成接口组件。 集成设计粒度的说明： 1. 对于每种集成场景，都需要在集成总图中表示； 2. 对于系统架构概览图中的每个外围系统与本系统的关联关系，都需要在集成场景中找到对应的场景； 3. 对于数据流转中的每个流转数据，都需要在集成场景中找到对应的场景； 4. 对于每一个集成接口（包括界面集成接口、应用集成接口以及数据集成接口），都必须明确标识出所属的集成场景。 6.6.2　 设计输入 系统集成视图设计所需的输入通常应遵循和参考如下架构资产和工作产品： —— 《软件需求规格说明书》的第五章节“系统功能规格”和第六章节“系统技术规格” —— 《系统概要设计》的第三章节“系统总体框架”、 第六章节“系统数据视图”和第七章节“系统组件视图”章节 —— 总体架构蓝图 —— 各种参考架构 6.6.3　 设计步骤 6.6.3.1　 定义集成场景 确定系统有哪些集成场景，并描述集成场景的源系统、目标系统、频率、实时性、数据量、集成方式。 定义集成场景可以参考如下要点： —— 根据“6.4.3.3定义数据流转”章节，获取数据流转清单； —— 针对每个数据流转，根据“5.2.3.1确定系统用例”章节，分析出集成接口，包括：集成接口名称、源系统、目标系统、输入/输出信息及信息量大小、调用频率、触发方式等非功能性要求。整理形成本项目的所有集成接口清单，集成接口清单为过程性文档，不在系统概要设计模板中体现； —— 根据集成接口属性，选择合适的集成方式。集成方式包括：界面集成、应用集成、数据集成； —— 对所有的集成接口进行归集，形成本项目的集成场景清单； —— 对每个集成场景进行描述，明确其源系统、目标系统、频率、实时性、数据量、集成方式； —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容； —— 根据“6.1.3.2确定总体技术路线”章节中的技术路线和架构决策检查以上设计内容。 6.6.3.2　 定义界面集成 界面集成通过界面集成接口组件来实现。界面集成接口组件的设计包括：所属的集成场景、发起方/提供方、接口信息（接口名称、描述、实现技术）。 定义界面集成可以参考如下要点： —— 获取定义集成场景时梳理的集成接口清单； —— 从集成接口清单中找出集成方式为界面集成的接口； —— 针对每个集成接口，根据“6.5.3.2定义功能组件”章节，找出对应的集成接口组件； —— 确定该集成接口的实现技术； —— 完善“6.5.3.2定义功能组件”章节中的集成接口组件设计； —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容； —— 根据“6.1.3.2确定总体技术路线”章节中的技术路线和架构决策检查以上设计内容。 6.6.3.3　 定义应用集成 应用集成通过应用集成接口组件来实现。应用集成接口组件的设计包括：所属的集成场景、发起方/提供方、集成方式、发起方的接口信息、提供方的接口信息。 定义应用集成可以参考如下要点： —— 获取定义集成场景时梳理的集成接口清单； —— 从集成接口清单中找出集成方式为应用集成的接口； —— 针对每个集成接口，根据“6.5.3.2定义功能组件”章节，找出对应的集成接口组件； —— 针对该集成接口，确定本系统是发起方还是提供方； —— 确定本系统提供的集成接口的接口信息，内容需要包括：接口名称和描述、输入消息及其格式、输出消息及其格式、实现技术、同步\异步、异常处理； —— 确定关联系统提供的集成接口的接口信息，内容需要包括：接口名称和描述、输入消息及其格式、输出消息及其格式、实现技术、同步\异步、异常处理； —— 确定该集成接口组件是通过企业服务总线还是直连方式与其他系统进行集成； —— 完善“6.5.3.2定义功能组件”章节中的集成接口组件设计； —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容； —— 根据“6.1.3.2确定总体技术路线”章节中的技术路线和架构决策检查以上设计内容。 6.6.3.4　 定义数据集成 数据集成通过数据集成接口组件来实现。数据集成接口组件的设计包括：所属的集成场景、发起方、发起方的数据格式、接收方、接收方的数据格式、集成方式、数据类型、发起方式、时间窗口、交换数据信息。 定义数据集成可以参考如下要点： —— 获取定义集成场景时梳理的集成接口清单； —— 从集成接口清单中找出集成方式为数据集成的接口； —— 针对每个集成接口，根据“6.5.3.2定义功能组件”章节，找出对应的集成接口组件； —— 确定该数据集成接口组件的发起方和接收方及他们传输数据的格式； —— 确定该数据集成接口组件的集成方式，如数据交换平台、数据联盟、ETL、ESB等； —— 确定该数据集成接口组件的数据类型，如非结构化数据、结构化数据、结构化主数据等； —— 确定该数据集成接口组件的发起方式，如手动、自动； —— 确定该数据集成接口组件的时间窗口，如什么时间段可以运行、多长时间可以完成； —— 确定该集成接口的交换数据信息。内容需要包括：交换数据实体名称和属性、涉及数据量、校验规则。 —— 完善“6.5.3.2定义功能组件”章节中的集成接口组件设计； —— 根据“6.1.3.1确定设计原则”章节中的设计原则检查以上设计内容； —— 根据“6.1.3.2确定总体技术路线”章节中的技术路线和架构决策检查以上设计内容。 6.6.4　 设计输出 —— 《系统概要设计》中的第八章节“系统集成视图” 6.6.5　 执行角色 表格 15 系统集成视图设计执行角色 角色 负责 执行 询问 通知 客户与最终用户 需求分析人员 √ √ 系统设计人员 √ √ 6.7　 系统逻辑部署视图设计 6.7.1　 设计目标 设计定义系统所有的逻辑部署单元及其依赖关系，说明每个部署单元所包含的组件，并定义系统所有的部署节点、节点承载的部署单元。 部署设计粒度的说明： 1. 系统的全部组件都应该被分布在部署单元之中，应该明确表示出部署单元之间的关联关系； 2. 对于部署节点，应明确部署单元与之的对应关系，以及部署节点之