系统总体方案通用模板48页.docx
- 文档编号:3625227
- 上传时间:2022-11-24
- 格式:DOCX
- 页数:39
- 大小:825.02KB
系统总体方案通用模板48页.docx
《系统总体方案通用模板48页.docx》由会员分享,可在线阅读,更多相关《系统总体方案通用模板48页.docx(39页珍藏版)》请在冰豆网上搜索。
系统总体方案通用模板48页
1系统总体方案-通用模板
2技术架构
2.1.1系统技术原则
系统实现过程中,应该遵循如下技术原则:
1、先进性
系统的实现应参考国际标杆并结合现状,采用先进可靠的设备和技术,确保系统的先进性和成熟性,保证投资的有效性和延续性。
2、安全可靠性
系统必须要达到较高的安全标准,提供良好的安全可靠性策略,支持多种安全可靠性技术手段,制定严格的安全可靠性管理措施。
3、开放性
系统应基于国内外业界开放式标准,进行全国统一规划,为未来的业务发展奠定基础。
4、可扩展性
系统应具备灵活的可扩展性,具备方便地适应业务需求的变化、迅速地支持新业务的能力。
5、可伸缩性
系统应具备良好的可伸缩性,系统性能及并发处理能力对主机设备具备平滑的扩展能力,支持业务量快速发展的需要。
6、易使用性
系统应易于使用与维护,具备良好的用户操作界面、人性化的管理工具和完备的帮助信息。
7、IT与业务协同
在企业信息化能力建设的过程中,不仅要重视IT技术体系建设,同时要高度重视对端到端业务管理流程、规则的理解和梳理,有效实现对流程和规则的固化,保证对企业业务运营和经营管理的有效支撑和高效原则。
2.1.2系统架构技术原则
在技术原则的指导和约束下,系统设计实施必须遵循以下总体设计思路与原则,保证系统在性能、可靠性、易使用性等质量要素间的综合平衡,保证技术原则各项目标的顺利实现。
1)面向服务的模块化系统架构
服务接口定义稳定:
应充分考虑服务间接口稳定性,建议使用XML或者类似的结构,以保证接口传输参数与内容的可扩展性。
服务粒度合理确定:
应综合考虑系统性能、扩展性等方面的因素,同时兼顾系统在部署、维护和管理等方面的要求,合理确定服务粒度。
多实例运行:
应该尽量满足对每一个服务都可以同时运行多个服务实例的需求,以保证系统的高可靠性与可伸缩性。
2)分布式、面向服务访问
每个服务均可以承担服务提供者和服务使用者两种角色,服务使用者通过访问服务提总线的接口获取相应的服务。
系统必须实现服务的分布透明机制。
组成系统的服务实例可以部署在一台或多台主机上。
服务总线提供的服务访问对分布地点、位置透明,服务使用者通过服务的逻辑名称即可获取服务而与服务所在主机的物理位置无关。
3)松耦合、高内聚原则
系统设计须遵循松耦合、高内聚原则。
服务之间保持松耦合状态,服务的具体实现方式对服务使用者透明。
在服务内部所实现的功能与结构保持高度逻辑相关性的同时,保证服务间的相互独立性。
4)业务流程与业务组件分离、应用与展现分离
应综合考虑业务流程与组件实现的分离的原则,建议利用流程管理、规则管理和门户技术,动态地定义系统的行为以实现系统功能。
在应用此种技术获得灵活性与可扩展性的同时,也要充分考虑到其对系统性能带来的影响。
业务流程的实现往往会涉及多个系统的多个功能模块,为了降低系统间耦合程度,提高流程管理的灵活性,应该实现分层次的流程管理机制,各系统内部实现自己的工作流管理服务。
5)数据与功能分离
系统必须提供独立于业务的信息存取层,信息存取层遵循企业的数据模型规范。
外部系统通过对业务服务的访问来使用信息存取层的功能。
2.1.3基本概念
在技术架构中,会涉及到以下一些概念,先分别做描述。
2.1.3.1业务组件
组件是实现特定功能,遵循某一个组件模型的约定并可独立部署与运行的软件单元。
Ø业务组件代表了一组业务逻辑相关的,高内聚的业务功能,如图2-1中层次一所述;
Ø它实现了人机界面无关的业务逻辑相关的处理功能;
Ø业务组件的功能可以被封装为业务服务,如图2-1中层次一可以直接封装为服务,也可以为层次二中封装为服务。
图2-1组件层次示意图
2.1.3.2业务服务
服务是组件实现并对外提供的功能与操作集合。
Ø每个服务均可以承担服务提供者和服务使用者两种角色,服务使用者通过访问服务提供给总线的接口获取相应的服务;
Ø组成系统的服务实例可以由一个或者多个业务组件的功能进行封装;
Ø业务服务有标准的接口;
Ø可以被注册到服务总线上被其它业务服务调用;
Ø在服务内部所实现的功能与结构保持高度逻辑相关性的同时,保证服务间的相互独立性。
图2-2服务组件关系图
2.1.3.3面向服务的体系架构SOA
SOA面向服务的体系结构,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口联系起来。
接口是采用中立的方式进行定义的,它独立于实现服务的硬件平台、操作系统和编程语言,这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
Ø从业务人员角度来看,它使得我们能够更加容易地对客户和合作伙伴提供业务服务;
Ø从架构师角度来看,它提出了更加松耦合、更强调重用性、可封装性的一种架构风格;
Ø从开发人员角度来看,它提出了一些编程模型以及相应的一些规范,包括标准、工具、方法;
Ø从运维人员角度来看,存在于服务请求方和服务提供方之间的一套协定和契约,它们规定了服务的质量。
商业创新和优化服务
开发服务
IT服务管理
基础结构服务
合作伙伴服务
商业应用
程序服务
访问服务
交互服务
流程服务
信息服务
连接性服务---企业服务总线
图2-3SOA架构图
2.1.3.4业务对象
系统用业务对象来表示业务逻辑和业务流程中涉及的实体(例如订单、客户、用户);业务对象以面向对象的方式进行设计,是一组属性和操作的集合;业务对象相关的数据可以以库表的方式存放在数据库中,系统通过数据存取的方式来完成业务对象和库表数据之间的双向转换。
2.1.3.5业务流程
业务流程特指为了完成特定的业务功能,通过相应的规则与流程技术,将一个或多个服务进行编排而形成的业务流;例如订单调度流程、故障处理流程等。
对于一些易变的应用逻辑,也可以流程化,例如客户认证与鉴权就是一个业务流程,它是通过业务流程组合了客户查询、客户认证、用户信息查询、客户信息过滤、燃气销售查询、推荐信息查询等多个业务服务。
2.1.3.6界面集成
界面集成是对不同界面展现组件之间的集成。
通过合理的规划和设计,界面集成可以重用已有的企业内外界面资源、提高开发部署效率、迅速满足客户和业务的需求,从而提高界面开发的灵活性和简易性。
2.1.4分层技术架构
系统采用分层结构开发和设计,将界面、业务流程、服务、数据分离,实现系统内部松耦合,以灵活、快速地响应业务变化对系统的需求。
系统层次结构划分为信息资源层、信息存取层、业务服务层、业务流程层、展现层,各层次间通过直接调用或者通过ESB进行调用,实现系统功能。
原则上信息资源层不允许信息存取层之外的层次对其进行调用,信息存取层不允许业务服务层之外的层次对其进行调用。
各层的应用组件利用系统支撑服务框架所提供的基础服务实现系统公共设计、运行与管理机制。
以下各小节将分别对这些系统内部层次进行说明。
图2-4系统技术架构图
2.1.4.1前台界面展示层
展现层是系统与用户进行信息交互的平台,通过界面集成将界面展现组件组合成用户界面。
用户通过用户界面调用业务流程来实现业务功能。
即系统的服务对象层,包括各类通过该系统获取服务的人员,如港华燃气的客户,营销人员,系统管理人员,高层决策人员,合作伙伴,渠道服务人员等,各类服务对象可以通过多种接入方式获取服务,包括面对面的方式,呼叫中心方式,Internet登录方式,自助终端等方式。
不同角色,不同岗位的服务对象在接入系统后将获得不同的服务功能视图。
⏹界面展现组件
界面展现组件由一组基本并紧密相关的界面展现单元组成,并通过这些界面单元调用与之有较强内聚性的业务服务实现一个独立的、带人机交互界面的业务功能。
⏹界面集成
界面集成是对不同界面展现组件之间的集成。
通过合理的规划和设计,界面集成可以重用已有的企业内外界面资源、提高开发部署效率、迅速满足客户和业务的需求,从而提高界面开发的灵活性和简易性。
界面集成有静态和动态两种集成方式。
静态集成方式:
开发人员以固化的方式集成各类界面展现组件,提供人机操作界面,实现系统的业务功能。
动态集成方式:
采用界面集成工具,通过简单灵活的配置来定义各个界面组件之间的关系,组成用户界面,并定义界面的流程。
在规则管理和流程管理的控制下,在系统运行过程中动态地决定界面的外观、行为和人机交互过程。
动态集成方式的实现有利于提升系统的配置能力、界面的个性化、可扩展性,保证系统迅速适应业务需求的变化和发展。
系统建设时应尽可能实现动态集成方式。
2.1.4.2业务流程层
业务逻辑层将主要本系统中的商业逻辑的实现和业务流程的控制集中,将表示层和数据层从业务逻辑中解耦出来,而专注于其所擅长的界面表示和数据存储访问。
业务逻辑层采用基于组件模型的面向对象的设计思想,并基于成熟的应用服务器平台而实现和运行。
⏹业务流程
业务流程特指为了完成特定的业务功能,通过相应的规则与流程技术,将一个或多个服务进行编排而形成的业务流;系统业务流程可以作为子流程被其它业务流程调用,也可以被展现层直接调用。
⏹实施建议
将业务需求中易变的业务逻辑及相关的业务规则剥离出来,通过流程与规则技术进行编排整合,保证系统的灵活性、可配置性、可管控性.
对数据量大、实时性高的业务流程可通过业务服务层进行封装,可以不通过动态的业务流程实现。
2.1.4.3业务服务层
业务服务以面向服务的方式对一个或者多个业务组件的功能进行封装,它具有明确的接口描述,可以被其它业务服务调用,也可以被业务流程或展现层调用。
业务服务是展现层、业务流程层和ESB调用的对象。
业务服务的功能由业务组件来实现,服务原子服务和复合服务,某个服务也可调用其它服务来完成更复杂的业务功能。
业务服务具有高内聚、可重用的特征,可通过标准的、明确的服务接口描述将具体的一个或多个组件中的功能按一定的规则和标准进行封装,可以被发现、绑定和调用。
2.1.4.4后台处理层
涵盖了整个系统中的后台处理系统,其特征是不直接面向客户,客服人员和市场营销人员,其主要的使用和操作对象为系统管理员和业务管理员,后台系统的可靠运行是港华燃气业务能够正常运行,尤其是客户服务和各类营销活动能够正常展开的有效保障。
2.1.4.5信息存取层
是系统的数据存储中心,按照业务和功能将系统的数据划分为如下几个数据库,在实际部署和运行中,考虑到实际容量和性能等原因可以进行适当的调整。
●应用数据库
●港华燃气数据库
●日志数据库
⏹数据存取
数据存储层专为业务逻辑层中业务组件提供数据资源操作和访问功能,包括对关系型数据库的CURD操作和文件系统的读写操作等。
完成业务对象(BusinessObject)的封装,以及业务对象到底层数据库结构之间的转换,实现对原始数据的存取访问,从而帮助业务组件层实现对业务对象的处理,使得业务组件层对数据的访问不受数据库物理设计、物理分布的影响。
能对数据库、操作系统文件或其他形式存储的数据进行操作,保证数据的完整性、一致性和准确性。
屏蔽信息资源层上数据模型和数据格式方面的差别,例如当数据定义的语义和语法不同时,可以在必要时进行语法转换和语义解析。
数据集成功能,屏蔽信息资源层上数据分布的差异性和分散性,例如实现跨表、跨库、跨地域的数据操作和访问。
2.1.4.6信息资源层
信息资源层负责系统的数据存储及维护数据的完整性与一致性。
数据可以根据需要存储在数据库管理系统、文件、外部存储设备中。
信息资源层数据的组织按照企业业务概念模型在应用软件上优化实现的要求形成各个主题域,并支持《数据模型规范》中定义的概念模型和逻辑模型。
2.1.4.7外部接口层(统一接口平台ESB)
系统的统一接口平台,面向不同外部系统的特征和要求提供不同的接口模式,包括实时接口模式,文件模式,基于消息的接口模式等。
面向的外部系统主要包括财务系统,港华燃气TCIS系统,各支付接口,其他合作伙伴系统等。
服务总线的概念是从面向服务体系架构发展而来的,是所有基于面向服务的体系结构解决方案的核心组成部分,是SOA架构中应用整合的骨干。
服务总线功能如下:
Ø服务总线是所有跨系统服务的注册中心,各系统的业务服务层甚至业务流程层提供的服务都可以在ESB上进行注册,从而对企业各系统的所有服务进行统一管理和查询;解耦域内各个子系统之间的调度。
Ø实现对所有服务的管控,包括对服务调用权限的定义和控制以及对服务全生命周期的管理,即管理每个服务从需求提出-〉开发-〉发布-〉部署上线-〉维护更新-〉下线的全过程。
2.1.5基于J2EE的软件层次结构
●客户端
在基于J2EE平台的系统架构中,这里的客户端目前仅指Internet浏览器。
●Web层
运行于WebServer上,用于实现各类静态,动态页面展现,页面跳转控制等,在网站Web层主要采用MVC的设计模式。
View
视图。
实现各类信息的展现,接受客户端的输入,并将输出信息通过页面反馈。
在J2EE应用中,View层的表现形式一般为各类htm,jsp文件,以及各类资源和属性文件。
Controller
控制器。
是MVC中的枢纽。
用户各种类型的HTTP请求都将通过Controller进行处理,并将处理结果通过JSP(view)推向前端,因此控制器也可以说是控制了各类页面之间的流转。
Controller以Servlet的方式来实现。
MVCFramework
这是实现了MVC模式的基础框架,可以采用目前较为成熟的struts,也可以自己开发。
具体框架选用可后续根据实际情况与用户讨论确定。
●业务层
在这一层实现了主要的业务逻辑和流程,其运行的主要上下文环境是EJB容器,并充分利用容器所提供的安全,事务,持久性,连接池等基础服务,按照功能的不同又可以分为如下几个层次:
Model
是MVC中负责业务逻辑访问和实现的层次,也是对业务封装并向应用的上层开放的层次,其一般的表现形式是JavaBean,通过bean来调用相关的业务逻辑实现。
业务控制层
系统的业务流程的实现层,其实现方式可以是根据业务流程对底层业务组件并行组合和包装形成更上层的应用组件;也可以是通过工作流引擎来驱动流程的实现。
业务组件层
实现了从系统中抽象出来的各类系统和业务基础组件,其基本特点是可重用,可扩展,相互之间耦合度小,可以采用JAVAClass的方式来实现,并向上层提供Interface以供调用。
数据访问层
对数据层访问的接口层,在J2EE平台中对数据库的访问可以通过JDBC直接建立连接或者通过连接池共享连接的方式进行数据访问。
对于一些简单的数据访问也可以在JDBC层次上通过实体Bean实现数据持久层,其好处是数据的持久性和事务的管理由容器来负责。
●数据层
存放系统中的各类数据,通过JDBC进行本地数据库的访问,与核心TIS系统的数据交互通过webservice方式获取。
2.1.6关键设计考虑
2.1.6.1可靠性设计
港华燃气系统是一个基于在线生产系统派生系统,直接关系到客户服务的质量以及企业运营的效率与收入,因此要求系统能够达到7X24小时不间断稳定运行。
由于港华燃气系统模块功能复杂,系统间结构与层次较多,在系统建设时需要对系统未来运行稳定型进行全面考虑与设计,并纳入系统设计的关键考量。
我们将主要从主机与平台软件的可靠性、网络可靠性、应用软件可靠性三个方面来考虑并设计:
⏹平台可靠性
平台是指整个系统运行的基础硬件与软件环境,包括主机、网络、数据库、交易中间件、J2EE应用服务器、流程引擎等基础软件。
平台是构造先进而实用的应用系统的物理基础。
江苏移动将几个方面来保证平台的可靠性:
A.从系统的先进性、业务容量、成熟性、实用性、可靠性出发,综合以上考虑与未来的扩展因素,同时考虑本期工程的资金投资,选择具有成熟应用案例与经验的软硬件平台,构造应用系统稳定的基础;
B.充分考虑系统关键网络节点、网络链路、关键应用平台等的在线热备份,包括核心交换机与路由器、数据库服务器、关键应用服务器等,适当考虑平台的冗余性,避免单点故障的产生,保证关键平台故障发生时的透明快速接管。
⏹应用软件可靠性
应用软件的可靠性是系统不间断运行的能力。
应用软件可靠性需要从软件架构设计部署与在线系统应用备份设计两个方面来考虑以提高系统的稳定性与容错性。
一、软件架构设计与部署
为了能够从软件体系架构上提高软件的可靠性,港华燃气系统采用了运行核心平台与上层业务系统分离的设计模式,所有的业务应用都基于稳定的基础业务运行平台而构建,基础业务运行平台独立于应用开发并统一演进,提供上层应用运行所必需的基础引擎与环境,以保证应用的稳定性与可靠性。
分布式应用软件的部署也是关系到系统稳定性的重要因素之一。
我们在进行本系统应用部署设计时将充分考虑一下原则与方法:
1.区分关键应用与非关键应用考虑部署,一方面减少应用间的相互影响,另一方面提高未来根据系统运行情况进行部署调整优化时的灵活性与伸缩性。
2.区分快速联机交易与批量业务考虑部署,这也是提高系统性能并保证核心业务稳定运行的主要策略。
3.考虑硬件平台的处理能力,并结合预计业务的发展情况,根据相关资源的消耗情况涉及足够的处理能力冗余,以降低由于出现性能瓶颈进而导致系统稳定性下降的可能性。
4.在系统上线之前将进行充分的、具有足够业务冗余的业务量测试,并根据测试结果合理调整应用的部署。
二、应用备份设计
为了能够降低系统故障导致应用处理中断给业务运营带来的影响,必须在系统规划与建设初期对应用软件的备份进行设计。
应用的备份根据是否存在人工干预、备份切换时间等可以分为在线热备与冷备份两种,而从应用的分布与层次则主要考虑各类应用服务器的备份,而应用服务器则又可以分为交易应用服务器、WEB应用服务器、后端处理应用服务器等类型,设计时需要结合应用的特点与重要性考虑不同种类应用备份的实现方式。
在本次系统建设中建议对关键应用包括计费应用、前台业务受理应用、服务开通进行在线热备份,保证系统故障时的自动切换;对其他应用采用独立服务器进行冷备份。
各种类型应用服务器的在线热备方式考虑如下:
●后台处理服务器
后台处理服务器采用基于主机的HAcluster方式进行,在平台或者应用故障中断运行时由备机快速接管应用,保证不间断运行。
考虑到业务量与投资规模,在本系统可以采用一台应用服务器备份多台机器的策略。
●交易应用服务器
交易应用服务器需要接收客户端的请求并进行业务逻辑的处理,因此该应用服务器的备份需要同时考虑远程客户端的接入切换与后台服务器的应用接管。
在港华燃气系统中,主要考虑以下可能的在线交易的应用备份策略:
1.IP映射技术。
这种方式通过网络设备(如交换机或者路由器)对内部的在线应用服务器与备份应用服务器位置进行映射,对客户端提供统一的IP地址。
并可以由网络设备自动检测应用的状态,在线应用发生故障时,可以自动把客户端请求转发至备份应用服务器,整个过程对客户端透明,同时这种方式在系统正常运行时也可由网络设备根据预定义的策略实现负载分担,且缺点是需要网络设备支持(需要四层交换功能)。
2.通过主机cluster集群软件进行。
这种方式采用浮动的IP网络地址来向客户端屏蔽内部服务器的位置,当在线系统失败时,集群软件无须人工干预即可自动启动备份应用服务器并对外提供服务,整个过程对客户端透明。
3.动态域名解析。
在线应用服务器与备份应用服务器各自保证应用的运行,客户端接入通过域名进行,在发生故障时,由域名解析服务器动态的将域名切换到备份应用服务器。
这种方式的缺点是需要实现应用检测并动态调整域名解析表的功能。
4.应用实现名字解析功能。
这种方式类似于J2EE中JNDI机制:
客户端不直接通过固定的IP地址访问特定的应用服务器,而是首先通过名字服务器获得对应应用逻辑的位置后再通过该调用该位置的应用逻辑。
这种方式的优点是可以灵活调整应用的分布而无需客户端做出任何改变,可以实现应用的“部分备份”;其缺点是名字服务器本身需要确保足够稳定。
5.利用应用服务器基础件本身的功能。
部分交易中间件具有客户端自动监测并切换后端应用的功能,当系统正常运行时,客户端通过轮换机制实现后台在线与备份应用服务器的自动分担;当系统发生故障时,客户端则根据相关的配置切换对应的后台应用,以达到不间断运行的目的。
在本期港华燃气系统的建设中,主要推荐1、2、5三种应用服务器的热备份策略。
●WEB应用服务器
WEB应用服务器的备份实现与交易应用服务器的备份实现具有较多的类似可参考之处,同时针对web应用及相关J2EE平台的特点,还可以考虑充分利用绝大部分J2EE应用服务器具有的软集群功能,同时在WEB应用服务器前侧增加专用的HTTP接入proxyserver来实现后端企业应用间的负载分担与灾难备份,在发生故障时,由HTTPproxyserver负责将请求转发到备份web应用服务器。
2.1.6.2灵活性与可扩展性设计
在建设港华燃气系统时不仅需要参考系统的设计容量,同时也需要充分考虑到未来随着业务的发展如何对现有的设备与软件进行扩展和平滑升级。
一般来说,一个软件的系统扩展需要从硬件和软件两个方面进行,因此在考虑系统的扩展性时硬件平台需要考虑相关网络与主机方面的处理能力扩展与延伸;软件则需要从功能与处理性能两个方面来进行系统的可扩展性设计,同时也需要考虑到保护投资、充分利旧等因素。
⏹网络与主机能力扩展
网络的升级扩展需要从多个方面综合考虑,并在系统建设初期根据相关原则,参考设计容量以及业务发展趋势对支撑网的影响,并结合以往系统的建设经验,合理规划具有良好扩展性与易于升级的网络建设方案。
A.网络接入能力的扩展:
接入能力是指交换机/路由器接入用户数的扩展能力,这种能力扩展一般出现在网络边缘,对于本次建设的港华燃气系统,则需要充分考虑未来港华燃气系统各种网络接入的终端数目的增加,因此在设计相关的网络方案时,充分考虑了接入部分的扩展能力,包括各类交换机端口数目的预留等。
B.处理能力扩展:
处理能力主要是指的核心网络设备的数据转发与处理能力。
这种要求主要出现在支撑网络的汇聚层与核心层。
随着业务量的增多、业务数据流量的逐渐增大,或者当出现较多的网络质量与安全控制策略时,这些核心网络设备处理能力的不足就可能影响到正常业务的运行。
在本项目方案中,江苏移动将根据设计容量并考虑未来必要的冗余,同时参考目前港华燃气TCIS系统中支撑网业务量的大小与网络设备的关系,并结合各主流网络设备的特点来综合设计各类核心网络设备的处理能力并选型,以保证未来业务需要时,能够尽快地通过模块增加、引擎升级、负载分担等手段快速的进行核心网络设备处理能力的扩展。
C.通信带宽的扩展:
随着数据量的增大以及各类应用功能的调整与增加,网络带宽将会有更高的要求,网络通信的带宽也是影响各类业务正常运行尤其是处理性能的重要因素之一。
在本系统的建设中将充分考虑业务的特点及网络数据交换量的大小,预留足够的网络带宽以适应未来的带宽需求。
主机服务器的可扩展性是指服务器(包括存储)的硬件配置可以根据需要灵活配置,如内存、适配器、硬盘、处理器等,因为服务器的硬件配置可能是根据不同时期的网络配置与业务容量而改变。
因此在设计本系统的主机相关配置时,将充分考虑本次设计容量、服务器所承载的数据或者应用特点考虑对应的硬件选型方案。
⏹软件能力扩展
软件扩展能力是应用适应未来业务量与业务需求变化的能力。
这些变化有的要求增加软件功能,有的要求应用处理能力能够实现良好的动态伸缩。
港华燃气系统作为业务运营的支撑系统,本身具有较大的业务需求覆盖度与软件规模,同时作为飞速发展的燃气行业应用软件,将会面临着用户规模与业务量的不断增大以及各种新业务的推出,这些都要求支撑系统能够快速的
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 总体方案 通用 模板 48