《国家电网公司信息系统架构设计指南(试行).docx》由会员分享，可在线阅读，更多相关《国家电网公司信息系统架构设计指南(试行).docx（71页珍藏版）》请在三一办公上搜索。
1、家电网公司信息系统架构设计指南2023年11月目录1适用范围12标准性引用文件13参照遵从14编写流程和职责25带求开发设计2需求调研2需求分析4用户体验设计76系统概要设计10系统总体框架设计10业务能力视图设计13系统功能视图设计13系统数据视图设计13系统组件视图设计15系统集成视图设计18系统逻辑部署视图设计20系统物理部署视图21系统平安视图设计237附录25软件需求规格说明书编写内容25概要设计编写内容26图表图表1系统架构遵从1图表2编写流程和职责2图表3界面原型设计样例9图表4系统平安防护控制点23表格表格1系统架构遵从清单1表格2需求调研执行角色表4表格3系统用例例如15表格
2、4系统用例例如26表格5需求分析执行角色7表格6用户信息8表格7可用性需求8表格8用户体验设计执行角色9表格9应用类型优缺点分析10表格10应用类型典型实现技术11表格11架构决策分类11表格12系统总体框架设计执行角色12表格13系统数据视图设计执行角色15表格14系统组件视图设计执行角色17表格15系统集成视图设计执行角色20表格16系统逻辑部署视图设计21表格17系统物理部署视图执行角色22表格18应用平安设计要点23表格19数据平安设计要点24表格21软件需求规格说明书各类系统编写内容25表格22概要设计各类系统编写内容26国家电网公司信息系统架构设计指南1适用范围本指南定义了国家电网
3、公司信息系统建设中开展需求开发、概要设计工作应遵循的原那么、方法，是国家电网公司信息系统建设的指导性文件。木指南适用于国家电网公司总部、分部，以及省（自治区、直辖市）电力公司和公司其它全资企业、控股企业、直属事业单位、信息系统责任研发单位。本指南适用于国家电网所有信息化系统，包括定制开发类业务系统、套装软件类业务系统以及平台类系统，各系统需要编写内容参见本指南附录。2标准性引用文件以下文件对于本文件的应用是必不可少的。但凡注H期的引用文件，仅所注日期的版本适用于本文件。但凡不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。-国家电网公司应用软件集成设计标准-国家电网公司软硬件目标
4、架构设计标准-国家电网公司应用软件非功能性需求标准一一信息系统全生命周期平安管控之平安设计标准一一国家电网公司应用软件架构设计标准3参照遵从系统架构设计应该遵从总体架构，具体遵从关系如以卜图所示：图表1系统架构遵从详细信息如下：表格1系统架构遵从清单总体架构系统架构遵从形态业务架构-业务职能需求开发-业务职能遵从业务架构-组织单元需求开发-组织单元业务架构-业务流程需求开发-业务流程遵从、细化业务架构-业务活动需求开发-业务活动细化业务架构-业务步骤需求开发-业务步骤细化业务架构-业务信息需求开发-业务信息细化应用架构-应用需求开发-系统功能规格-系统功能遵从、细化应用架构-功能需求开发-系统
5、功能规格-系统用例遵从、细化应用架构-交互需求开发-系统功能规格-系统用例遵从、细化技术架构-系统系统概要设计-系统组件遵从、细化数据架构，数据实体系统概要设计数据模型避从、细化数据架构属性系统概要设计数据模型细化技术架构。集成场景系统概要设计集成场景遵从、细化技术架构-平台组件系统概要设计-集成设计遵从、细化技术架构一位置系统概要设计-物理部署细化4编写流程和职责图表2编写流程和职责注；可以通过缩放WOm文档查看编写流程和相关职责.系统架构设计主要涵盖软件工程的需求开发阶段以及概要设计阶段，包含需求调研、需求分析、用户体验设计以及概要设计。业务需求文档由业务部门负责组织进行编写并发布；工程组
6、负责编写软件需求工作说明书、用户体验设计以及系统概要设计文档，信息化部门负责组织进行评审、发布。系统架构设计指南用于指导需求开发和概要设计阶段的分析设计活动。各工程组应遵循该指南，采用对应的软件需求规格说明书模板以及概要设计模板进行分析设计。对于大型工程，完成用户体验设计，可单独成册：对于小型工程，不要求进行用户体验设计。详细设计阶段，各工程组根据系统的特点采用针对性的详细设计方法，基于概要设计开展详细设计并编写详细设计文档，本系统架构设计指南不对详细设计进行约束。整个流程可根据工程的具体情况决定是否需要进行迭代。如需求存在较多不确定性时，可在需求编制和需求开发两个阶段采用多轮迭代的方式去梳理
7、需求。5需求开发设计5.1需求调研5.1.1调研目标通过对业务需求报告的分析理解或直接与业务部门调研的方式，获取业务部门的需求信息。说明：业务需求报告由业务部门负责，主要描述了信息化工程所覆盖的业务范围、关键业务场景、约束和规那么、以及相关系统建设范闹的说明。软件需求规格说明书是基于业务需求报告，由系统设计人员以软件工程约定的标准描述方式，分析并记录系统的功能和非功能需求，为系统概要设计提供输入。调研粒度的说明：1.对于业务流程，要明确流程中每个活动，以及每个活动所对应的组织单元和执行角色；2.对应业务活动，要明确其操作步骤或需要实现的业务功能点；3.对业务功能，要逐级划分子功能，直到每个子功
8、能点具有明确的业务输入信息和业务输出信息：4.对于执行角色，要梳理出所有业务活动和业务功能中的执行角色；对于组织单元，要覆盖所有业务活动和业务功能中的对应组织：5.对于业务信息，明确其业务含义和数据的属性（包括但不限于数据的类型、长度、取值范困和业务规那么等）。5.1.2调研输入客户相关需求：-业务需求报告：总体架构蓝图：5.1.3调研步骤5.1.3.1确定业务目标定义本工程的业务目标是什么，以及本工程的业务范围。5.1.3.2梳理业务流程梳理本工程涉及到的业务流程，描述每个流程包含哪些业务活动、流程属于什么业务职能。如果需求不涉及业务流程逻辑，那么不进行描述。如-体化平台不涉及业务流程逻辑，
9、不用描述。梳理业务流程可以参考如下要点：-以业务为主线梳理业务流程，确定本工程涉及到的业务流程清单，明确业务流程的父级流程及所属的业务职能；针对每个业务流程需要确定以下问题：包含哪些业务活动/子流程？活动的先后关系是什么？从一个活动到另一个活动的条件是什么？每个活动的责任主体（角色或组织单元）是谁？每个活动的类型（比方：人工、系统等）？明确以上问题后，通过跨职能流程图或者EPC（事件驱动流程,Event-drivenProcessChain）图描述业务流程。其中跨职能流程图应遵循BPMN标准。5.1.3.3确定业务活动描述每个业务活动的具体业务步骤、输入、输出业务信息、业务规那么及涉及到的非功
10、能性需求。确定业务活动可以参考如下要点：明确每个业务活动的业务功能：针对每个业务活动需要确定以下问题：每个活动的具体步骤/业务规那么是什么？每个活动的输入和输出业务信息是什么？业务信息应在软件需求规格说明书的4.6业务信息章节中描述，并将其业务信息的编号记录在当前的业务活动中每个活动的责任主体对本环节中业务信息的操作是什么（新建、删除、修改、读取）？5.1.3.4确定业务功能此处的业务功能是在需求调研阶段由用户直接提供的业务功能列表，专门针对不在特定业务流程中的业务功能进行编写与前面业务流程的描述形成互补，都作为系统功能规格分析的输入。后面系统功能规格中的系统功能清单中应该涵盖本章节描述的业务
11、功能，从而保证系统功能规格中的系统功能清单始终保持完整的全部功能点。确定业务功能可以参考以下要点：一按照父功能点包含子功能点的方式绘制功能层级图来展示功能点之间的层级关系：一用表格的形式列出所有的顶级功能点清单：一对每个顶级功能点，分析拆解出子功能点，并以章节的形式列出所有的子功能点:-以此类推，对所有可以分解的功能点进行层层拆分，逐级深化。直至每个功能点都可以明确地得出输入的业务信息和输出的业务信息。5.1.3.5确定执行角色收集本工程涉及到的所有角色，描述角色的职责。根据“5章节中涉及到的角色，整理形木钱工程的角色清单。5.1.3.6确定组织单元收集本工程涉及到的所有组织单元（包括客户、供
12、给商），描述各部门的职责。确定组织单元可以参考如下要点：-根据5章节中涉及到的组织单元，整理形本钱工程的组织单元清单；基于组织单元清单，调研形成组织单元的组织结构图。5.1.3.7确定业务信息收集本工程涉及到的所有业务信息。业务信息包括表单、报表、文档等业务信息.，及这些业务信息的内容。确定业务信息可以参考如下要点：一业务信息有两个来源。一是从“5确定业务活动章节中梳理出来的:二是从5章节中梳理出来的。经过归集整理后，形本钱工程的业务信息清单。每个业务信息都应该有业务信息编号，并应该将编号记录在其来源处，即业务活动或业务功能中。-针对每个业务信息，确定具体的信息内容：-确定业务信息的校验规那么
13、（如不能为空）i5.1.4调研泊出一一软件需求规格说明书的第四章节业务描述。5.1.5执行角色表格2需求调研执行角色表角色负责执行询问通知客户与最终用户需求分析人员系统设计人员52需求分析5.2.1分析目标根据需求调研结果，对用户需求进行分析归纳，确定系统需要实现的功能和非功能需求。通过系统用例模型描述系统的功能需求，使之成为在开发全过程中研讨系统需求和进行系统设计的依据，在软件测试阶段作为系统测试的根底。需求分析粒度的说明：1.对于系统用例，要覆盖所有的业务活动，每个用例需明确根木流程和所有备选流程的操作步骤，或者详细标识每个用例的功能点:2.对于系统功能点，要逐级划分子功能，直到每个子功能
14、点具有明确的业务输入信息和业务输出信息；3.对于技术规格，要对需求调研阶段获得的所有非功能性需求，给出具体的技术规格说明。5.2.2分析输入软件需求规格说明书的第四章节“业务描述总体架构蓝图5.2.3分析步骤5.2.3.1确定系统用例系统用例分为两种。一种是按业务步骤进行描述，另种是按功能进行分解描述。其目的是为了确定系统参与者和系统功能之间是怎么相互联系的。确定系统用例可以参考如下要点：-根据总体架构蓝图及业务需求确定系统边界：基于5确定业务活动”章节中的业务活动清单，确定涉及到的系统用例清单，明确系统用例的子用例：明确每个用例的描述；针对每个用例需要确定以下问题：该用例的前置条件是什么，什
15、么情况下会触发该用例？该用例有哪些参与者？参与者包括使用系统的用户及和系统有交互的其他系统或者子系统；该用例中参与者与系统的根本流程和备选流程是怎样的？或者该用例包含哪些子功能？参与者需要读取、产生、删除、修改、存储系统中的什么信息？系统如何响应参与者的操作？该用例的主要界面是什么？该用例的后置条件是什么？明确以上问题后，通过下面两个表格中的-个来描述系统用例。表格3系统用例例如1属性描述备注用例名称用例编号描述用例的编号参与者描述用例的参与者前置条件描述用例开始的约束子功能点描述业务功能的子功能点对业务功能可能涉及到的各种场景进行分析整理，得到全部的子功能点。后置条件描述用例结束，系统处在什
16、么状态无论执行的结果如何，用例的后置条件都应为真。如果可能出现故障，那么应在后置条件内包括该动作已经完成，或者如果可能出现故障，那么不执行该动作，而不只是该动作己经完成，主要界面展示该用例涉及到的主要界面非功能性需求描述该用例有哪些非功能性的需求抽取出的功能名称列表从此用例中抽取出来的功能点名称列表表格4系统用例例如2属性描述备注用例名称用例编号描述用例的编号参与者描述用例的参与者前置条件描述用例开始的约束根本流程描述用户和系统交互流程根本流程描述格式：1.每一个步骤都需要用数字编号清楚地标明步弊的先后顺序。2.当整个用例模型根本稳定之后，针对每一步骤详细描述参者和系统之间所发生的交互。建议采
17、用双向(roundtrip)描述法来保证描述的完整性，即每一步骤都需要从正反两个方面来描述:(1)参与者向系统提交了什么信息；(2)对此系统有什么样的响应.3.在描述参与者和系统之间的信息交换时，需指出来回传递的具体信息.如：不能只描述参与者输入了客户信息，应确切说参与者输入了客户姓名、客户地址。备选流程描述根本流程相关的可选或异常特征的行为，同时也包括根本流程的各种变形备选流程必须说明以下内容:1.根本流程中可以插入备选流程的位置。2.为使备选流程开始而需要满足的条件。3.系统在该备选流程卜会采取哪些动作。4.根本流程重新开始的方式和位置，或者用例结束的方式。后置条件描述用例结束，系统处在什
18、么状态无论执行了哪些可选流程，用例的后置条件都应为真；它不能只对根本流程为“真.如果可能出现故障，那么应在后置条件内包括该动作已经完成，或者如果可能出现故障，那么不执行该动作.,而不只是该动作己经完成.主要界面展示该用例涉及到的主要界面非功能性需求描述该用例有哪些非功能性的需求抽取出的功能名称列表从此用例中抽取出来的功能点名称列表5.2.3.2确定系统功能点收集本工程涉及到的所有系统功能点，描述系统功能点的类型、依赖的功能点、父级功能点及所属的应用。确定系统功能点可以参考如下要点：根据5和“5章节，绘制功能层级图，按照父功能点包含子功能点的方式，将所有功能点在一个层级图中展示出来；一将所有的顶
19、级功能点以表格的形式制成功能点清单，明确每个系统功能点的功能描述：一从顶级功能点开始逐个功能点分析拆解，分章节描绘每个功能点的子功能点清单，直至最底层的功能点可以明确得出其输入的业务信息和输出的业务信息：一分析确定功能点之间的依赖关系，此功能点的前置、后置以及交互的功能点称为依赖功能点。5.2.3.3确定技术规格确定系统在技术层面如何实现系统的非功能性需求。技术规格至少要包含：性能、可靠性、可用性、可扩展性、易用性、平安性及容量规划方面的内容。系统技术规格必须参照国家电网公司应用软件非功能性需求标准的要求进行设计。系统技术规格中平安相关的规格必须参照信息系统全生命周期平安管控之平安设计标准的要
20、求进行设计。系统技术规格中对系统运行维护提出了相应的需求，应该予以实现。5.2.4分析输出一一软件需求规格说明书的第五章节“系统功能规格和第六章节“系统技术规格。5.2.5执行角色表格5需求分析执行角色角色负责执行询问通知客户与最终用户需求分析人员系统设计人员5-3用户体验设计5.3.1设计目标根据软件需求规格说明书文档内容构造系统界面原型，通过用户使用以验证需求文档内容的完整性和正确性，发现可能存在的质量问题，并为后续系统开发提供输入。用户体验设计粒度的说明：1.实现界面原型。5.3.2设计泊入软件需求规格说明书的第五章节“系统功能规格和第六章节“系统技术规格5.3.3设计步骤用户体验设计可
21、以参考如下要点：收集用户信息用户交互设计要考虑到目标用户的不同引起的交互设计重点的不同，需要通过收集不同类型的用户信息来指导后续的Ul设计、可用性设计、功能性设计等，并可以验证用例中的参与者与需求的完整性。表格6用户信息属性描述备注用户用户名标识角色用户在系统中承当的各个角色以往经验知识例如知识领域、计算机技能、教育背景等物理特征年龄、性别、语言等物理环境文化、环境、技术的接受能力、其他并行使用的系统等目前工作特征例如是否出差评估当前用户体验要求/标准通过收集当前用户使用系统的比照数据，分析原有的针对现实的交互流程、已有软件工具的交互流程，找出用户体验的缺点与优点，并结合不同类型用户的交互习惯
22、，以及其希望到达的交互效果，对这些优缺点按用户重要程度与满足程度进行排序。定义可用性需求可用性需求的定义是为了使用户接受最终的系统。在定义可用性需求时，需要同样关注目前已有系统的可用性需求特点。表格7可用性需求类别属性描述备注交互定制化系统可按照用户要求进行定制化，例如字体、屏幕尺寸、颜色等效率使用效率，例如键盘、鼠标、快捷方式等集成对于分布在多个功能中的流程是否可以自动化执行导航用户可以知道目前的功能位置可预测操作的结果是否是客户预期的响应用户对于系统响应的接受度显示可识别显示的内容是清晰可见的，区别于一般内容的可理解用户必须可以理解界面各元素对应的功能.有意义对于现实的内容，文字、图表、声
23、音，都是可以被用户理解的，例如是否一目了然，是否有详细说明等布局显示元素的摆放是符合逻辑的一致性所有的操作、显示的风格一致，形式一致、交互行为一致。连接/访问输入方式选择系统的输入方式是多样的，例如键盘、鼠标、声音、从指定格式导入、从采集工具接入等输出方式选择系统可以有可选择的输出方式，例如文字终端输出，界面图形输出，或者图形输出的图标、图像、控制等选择界面设计标准标准首先选择界面设计风格，Web、NindOWS应用、终端文字输出等。其次定义公共Ul元素。例如对于按钮的样式进行统一定义。最后定义界面设计方法，例如定义显示要求，高亮显示、文字提示等。并描述那些要求是必须遵从的，哪些是可选的。-制
24、定用户界面原型界面原型着重描述界面元素、布局、页面之间的跳转关系，是确定用户需求的有效手段，为详细设计奠定根底。界面原型定义需要定义如下要素：界面元素定义所有界面元素组件,例如文木框、按钮、下拉框、列表等。界面布局定义界面中的元素位置布局。界面风格主要定义界面的美观性和协调性,例如组件大小、颜色、字体等样式。界面易用性定义界面的易用性，例如输入快捷键、输入方式、提示方式、帮助等。界面跳转定义界面与界面之间的跳转关系。非功能需求定义界面性能、自适应要求等。界面原型例如：图表3界面原型设计样例一用户界面原型验证通过用户对界面原型的验证，确认界面原型是否支持业务应用，其易用性、美观性等方面是否满足用
25、户要求。5.3.4设计输出一对于大型工程，可单独成册进行编写，对于小型工程可不写。文档命名为XX系统用户体验设计。5.3.5执行角色表格8用户体验设计执行角色角色负责执行询问通知客户与最终用户需求分析人员系统设计人员6系统概要设计61系统总体框架设计6.1.1设计目标设计系统总体框架，为后续组件视图、数据视图集成视图、部署视图、环境视图和平安视图的设计提供指导。设计内容包括：系统设计原那么、总体技术路线、架构概览和架构遵从。总体框架设计粒度的说明：1.对于技术路线，要说明选择的技术路线的技术特点和选型的依据及对系统的影响；2.对于架构概览，要明确与此系统相关的所有系统及所处的网络位置（内网、外
26、网）等情况:3.对于架构遵从，要标明系统架构中与企业总体架构的四大架构相关的所有元素的对应关系。6.1.2设计泊入确定系统总体框架所需的输入通常应遵循和参考如下架构资产和工作产品：-软件需求规格说明书的第五章节系统功能规格和第六章节系统技术规格一一总体架构蓝图一一各种参考架构6.1.3设计步骤6.1.3.1确定设计原那么确定本工程在系统设计时应遵循的相关原那么，在后续的所有设计过程中都要考虑这些原那么。6.1.3.2确定总体技术路线确定总体技术路线包括确定系统采用的应用类型、技术路线和架构决策。确定总体技术路线可以参考如下要点：根据5和5章节，分析选择应用类型；可以参照下表选择应用类型：表格9
27、应用类型优缺点分析应用分层应用类型优点缺点客户端Web应用程序主流企业应用实现方式，具有跨平台Ul标准，容易部署和关联变更。需要在线操作；相比GUl应用程序用户界面欠丰富。GUI应用程序可以充分利用客户端资源：响应速度快、界面丰富，用户体验好；可以离线操作,部署复杂，通常需要借助特定技术完成部署：对版本管理要求高；难以跨平台.RIA应用程序与高客户端应用相当的用户界面；支持多媒体和图形显示；部署简单；升级和版本管理简单；可以支持不同平台和不同浏览器。客户端相比Web应用程序需要更高的配置；相比于富客户端应用程序，对客户端资源访问有限制：客户端部署通常需要适宜版本运行框架。移动应用程序支持手持设
28、备：适合连线和偶尔连线的场合。输入和导航限制；显示区域限制。效劳端客制化开发是活、可以实现个性化的需求；易于扩展Q开发周期长，需要相当较多的测试来保证质量.套装软件侦置很多成熟的业务功能：能快速部署使用。实现个性化需求相对需要更多的工作量U其他(可以根据实际情况进行添加)根据选择的应用类型决定所采用的关键技术。可以参照下表决定技术路线:表格10应用类型典型实现技术应用分层应用类型典型实现技术客户端Web应用程序HTML、JSP、FrameWorkSpring等。GUI应用程序JavaC+等。RIA应用程序Flex、SiIverlightApplet、EXtJs、JQUery、Flash等移动应
29、用程序ASP.NETMobile,SilverlightMobile等.效劳端客制化开发J2EE、.Net等套装软件SAP等确定系统关键设计的架构决策。下表列出了一些常见的架构决策，具体设计时可以根据系统特点进行补充：表格11架构决策分类分类架构决策组件通信面向效劳(SOA)、消息总线(MessageBus)、管道过浦器(PipesandFilters)应用部署客户端/效劳器(ClicntZServcr)3-Ticr、N-Tier领域模型领域模型(DOlnainModel)、数据网关(Gateway)用户交互模型-视图-控制器(MVC)、模型-视图-呈现(MVP)应用结构基于组件(Compon
30、ent-Based)、面向对象(Object-Oriented)、分层架构(LayeredArchitecture)根据6.1章节中的设计原那么检查以上设计内容。6.1.3.3确定架构概览架构概览主要描述系统的上下文关系，包括：本系统与周边系统的关系、各系统所属分区。确定架构概览可以参考如下要点：根据5章节，分析确定和本系统相关的所有的系统清单：一一获取企业分区信息：-确定每个系统的所属分区，一个系统可能分布在多个分区；一一确定本系统和现存其它系统的关系；根据6.1章节中的设计原那么检查以上设计内容。6.1.34确定架构遵从分别从业务架构、应用架构、数据架构和技术架构四个方面，描述系统架构与企
31、业总体架构的遵从情况。一业务架构遵从，业务架构：业务域应引用总体架构蓝图业务架构局部的业务域。系统架构:业务功能一项仅需逐一列出软件需求规格说明书中的第一级业务功能：业务架构：业务职能一项需参考总体架构的业务架构局部的业务职能，说明业务功能所对应的业务职能：“遵从说明一项需描述系统业务功能与业务职能的遵从关系，可选项为：遵从、细化、参照。一应用架构遵从，应用架构：应用域一项用于说明本系统设计所对应的应用域：应用架构；应用一项用于说明本系统设计所对应的应用，如实现多个应用，需要逐一列出:系统架构：一级功能一项仅需逐一列出软件需求规格说明书中的第一级系统功能：“应用架构：一级应用功能一项需说明系统
32、功能所对应的总体架构的应用架构局部中的一级功能：“遵从说明一项用于描述系统功能与应用功能的遵从关系，可选项为：遵从、细化、参照。一数据架构中，数据域和“数据主题应引用总体架构蓝图数据架构局部的数据域和数据主题。系统架构；数据实体一项需逐一列出系统涉及到的数据实体:数据架构：数据实体一项需列出总体架构的数据架构局部中对应的数据实体：遵从说明一项需描述系统数据实体与总体数据架构中数据实体的遵从关系，可选项为：遵从、细化、参照。一技术架构中，总体架构:系统名称应引用总体架构蓝图技术架构局部的系统名称。集成场景中的系统架构：集成场景一项需逐一列出本系统相关的集成场景：集成场景中的“技术架构：集成场景一
33、项需列出总体技术架构中对应的集成场景：“集成场景中的遵从说明一项需描述系统架构中的集成场景与总体架构的技术架构局部中的集成场景的遵从关系，可选项为:遵从、细化、参照。产品标准中的系统架构：软件产品一项用于描述系统拟使用的软件产品（如操作系统、数据库、中间件等根底软件）和版本号；产品标准中的技术架构:软件产品一项用于描述与之对应的总体架构的技术架构局部所列举的软件产品；产品标准中的遵从说明*一项需描述系统架构中的软件产品与总体技术架构中定义的软件产品的遵从关系，可选项为：遵从、细化、参照。一如果蓝图中没有相应设计内容，应遵循架构资产维护流程，提出架构资产修编申请61.4设计输出-系统概要设计中的
34、第三章节“系统总体框架6.1.5执行角色表格12系统总体框架设计执行角色角色负责执行询问通知平安运行人员架构管控组需求分析人员系统设计人员62业务能力视图设计系统概要设计中的业务能力视图设计是将软件需求规格说明书中的“业务功能和“业务流程直接复制过来的。目的是作为后续设计的重要输入。6.3系统功能视图设计系统概耍设计中的系统功能视图是将软件需求规格说明书中的第五章节“系统功能直接复制过来的。目的是作为后续设计的重耍输入。64系统数据视图设计6.4.1设计目标根据业务需求，确定支持系统实现的数据实体。设计内容包括：数据模型、数据分类、数据流转和数据存储与分布。数据视图设计粒度的说明；1.对于概念
35、数据模型，应明确概念数据实体之间的关系并明确其所子主题；2.对于逻辑数据模型，应明确每个数据实体的属性定义，主键、外健及数据实体之间的对应关系；3.对于数据分类，应明确所有逻辑数据实体的分类情况；4.对于数据流转，应明确所有系统间交换的数据实体的流转情况；5.对于数据的存储与分布，应明确所有数据实体的存储和分布情况。6.4.2设计输入数据视图设计所需的输入通常应遵循和参考如下架构资产和工作产品：-软件需求规格说明书的业务信息和第五章节系统功能规格*-系统概要设计的第三章节系统总体框架和第七章节系统组件视图总体架构蓝图一业务数据标准（包括各种典设成果，比方SG-CIM标准等）一己有相关系统的数据
36、模型一行业数据标准：比方IECCIM标准对模型的完善提供补充6.4.3设计步骤6.4.3.1定义败据模型数据模型的定义应按照先概念模型后逻辑模型的顺序，设计出数据的逻辑实体模型。总体架构概念数据模型是概念数据模型的重要输入，概念模型再进-步细化成逻辑数据实体的定义和关系，并梳理出数据实体的具体属性，以及描述属性的各参数，包括属性名称、属性编码、属性类型、数据长度、数据精度、是否主键及外键。定义数据模型可以参考如下要点：根据5章节，识别数据实体：一一确定每个数据实体的属性名称、属性编码、属性类型、数据长度、数据精度、是否主键及外键：分析可应用的业务数据标准，基于该标准对每个数据实体进行调整：-确
37、定每个数据实体的所属数据域和数据主题：分析确定数据实体间的关系；根据5章节，确定每个方法的输入输出数据实体：根据6.1章节中的设计原那么检查以上设计内容；一一根据6.1章节中的技术路线和架构决策检查以上设计内容。6.4.3.2定义败据分类确定每个数据实体的分类。定义数据分类可以参考如下要点：-根据“6章节，整理出本工程的所有数据实体清单：一一针对每个数据实体确定其属于结构化或非结构化实体：一针对每个结构化数据实体确定其属于主数据或业务数据：根据6.1章节中的设计原那么检查以上设计内容。根据6.1章节中的技术路线和架构决策检查以上设计内容。可以参考以下内容对数据实体进行分类：一按照存储方式可以将
38、数据分为结构化数据和非结构化数据。其中结构化数据分为主数据和业务数据，业务数据分为其他业务根底数据和交易数据。分类关系如下：主数据*业务数据非结构化数据6.4.3.3定义败据流转数据流转包括：系统之间的流转、系统和数据中心之间的流转。定义数据流转可以参考如下要点：一一根据6.1章节，分析出所有存在交互关系的系统；根据6章节，获取所有数据实体清单；一针对每个数据实体，根据5章节，确定该数据实体是否是数据交换实体。数据交换实体为跨系统边界的数据实体：一确定每个数据交换实体的源系统和目标系统；一一根据6.1章节中的设计原那么检查以上设计内容；根据6.1章节中的技术路线和架构决策检查以上设计内容。6.
39、4.3.4定义数据存储与分布确定数据实体的存储与分布。在系统架构设计中，数据存储指数据实体存储在哪些系统：数据分布指数据在不同系统的存在状态,是所有者或复制者，即O-OWner或C-CoPy。定义数据存储与分布可以参考如下要点：-根据6.1章节，分析出所有存在交互关系的系统；根据6章节，获取所有数据实体清单：-针对每个数据实体确定其存储的系统，一个数据实体可以存储在多个系统：针对每个数据实体，根据5章节，确定该数据实体在这些系统的分布情况：-根据6.1章节中的设计原那么检查以上设计内容。根据6.1章节中的技术路线和架构决策检查以上设计内容。6.4.4设计*出系统概要设计中的第六章节“系统数据视
40、图6.4.5执行角色表格13系统数据视图设计执行角色角色负责执行询问通知客户与最终用户需求分析人员系统设计人员1/65系统组件视图设计6.5.1设计目标把业务需求落实到具体的系统实现。设计内容包括：定义系统的逻辑分层、每一分层包含哪些组件、以及组件的包含依赖关系。组件设计粒度的说明：1.每个组件都需明确其所在的系统分层：2.每个组件都需要明确对外的功能方法名称：3.每个组件都需要确定与其他组件之间的关联关系；4.所有的系统功能都需要有组件与之对应。65.2设计输入系统组件视图设计所需的输入通常应遵循和参考如下架构资产和工作产品：软件需求规格说明书的第五章节“系统功能规格和第六章节“系统技术规格
41、系统概要设计的第五章节系统功能系统概要设计的第三章节系统总体框架总体架构蓝图各种参考架构65.3设计步骤6.5.3.1确定系统逻辑分层说明系统共有多少逻辑分层，并描述每个层级的职责、实现技术、依赖层级及与该层级的层间通信方式。确定系统逻辑分层可以参考如下要点：根据“6.1.3.2确定总体技术路线中确定的技术路线和架构决策，确定系统的逻辑分层：一一对每层的职责进行描述，确定其实现技术：一一确定层间调用规那么（例如：不能跨层调用），以及通信方式：应该参照国家电网公司应用软件架构设计标准的要求，来进行系统的逻辑分层：根据6.1章节中的设计原那么检查以上设计内容：根据“6.1章节中的技术路线和架构决策
42、检查以上设计内容。6.5.3.2定义功能组件确定系统有哪些功能组件，并描述功能组件包含哪些功能点、可以拆分为哪些组件，这些组件分布在哪些逻辑层级及每个组件开放了哪些方法。定义功能组件可以参考如下要点：一一识别组件的常用方法：对5章节中梳理出的每个功能点，分析设计出对应的候选功能组件：基于对业务流程、活动和业务功能的详细分析，将系统中所有的候选功能组件划分成几个子系统集合；再基于高内聚松耦合的原那么，对所有组件进行优化重构，使之满足高内聚松耦合的标准。一对每个功能组件进行描述，明确其实现的系统功能点；一确定每个功能组件的包含关系，并确定每一功能组件的层级。将每个组件放置到对应的层级中，在功能组件
43、图中表示出来。如果每层放置的组件很多，可以将每一层作为一个图进行绘制；一一确定每个功能组件开放了哪些方法，包含方法名称和描述；一一确定每个组件方法可能产生的异常情况及处理方法，包括但不限于：反应给用户的提示信息；错误信息的日志记录情况；对其他业务的影响。一一标示每个功能组件是否接口组件：根据5.2.3.3确定技术规格章节，分析确定关键的功能组件的非功能性要求；一一根据6.1章节中的设计原那么检查以上设计内容；根据“6.1章节中的技术路线和架构决策检查以上设计内容。6.5.3.3定义公共组件确定系统使用的公共组件，并描述每个公共组件的职责、来源、开放的方法及分布在哪些逻辑层级。定义公共组件可以参考如下要点：根据5和5.2.3.3确定技术规格章节，分析需要的公共组件，整理形本钱工程的公共组件清单；公共组件分为可以重用的功能组件和质量属性相关的组件。可以重用的功能组件来自上一节定义功能组件中的功能组件清单可能是清单中的某些组件，也可能是提炼出来的可以为某些功能组件提供效劳的组件。这类公共组件所实现的业务逻辑本身一般具有通用性，适用面比拟广，而且
