软件架构设计说明书三篇
篇一：软件架构设计说明书
文档编号：
当前版本：
1.1
作    者：
编写日期：
评    审:
评审日期:
审    核：
审核日期：
批    准：
批准日期：
文档状态:
草稿/发布版
变更次数:
章节编号
版本号
修订内容简述
修订日期
作者
页面设计说明
1简介
1.1目的
该文档用以描述XX网银系统（以下简称“系统”或“本系统”）的整体结构，模块划分以及各个模块的范围和接口定义。
1.2范围
本系统的目标是为中小银行（如城市商行）提供以实现网银渠道业务。项目一期的范围主要是系统技术架构的实现和部分个人、企业和内部管理业务的实现。
本系统一期开发不实现网银用户需求中定义的全部功能（具体参见网银需求规格说明书系列文档）；不进行系统独立性的具体实现，但在设计时考虑各种操作系统、应用服务器以及数据库的全面支持；一期实现业务的GUI，但页面的美工风格不做要求。
1.3定义、首字母缩写词和缩略语
1.4参考资料
《网银内部管理用户需求说明书》
《网银个人用户需求说明书》
《网银企业用户需求说明书》
《网银软件需求规格说明书》
《网银个人软件需求规格说明书》
《网银内部管理软件需求规格说明书》
《网银企业软件需求规格说明书》
《XX网银产品架构选型分析报告》
2设计方案
2.1系统与外部系统关系
网银系统是神州数码金融解决方案XX的重要组成部分。它处于渠道层，是银行主要渠道之一。
XX 体系结构
系统涉及的外部系统主要是核心业务系统（包括基本业务系统、卡系统等），而这些系统都是通过XX系统统一接入。因此，网银系统的主要外部系统是渠道整合系统XX。
其次，网银系统需要依赖Banking Portals提供用户界面。因此，网银系统的外部系统也包括
另外，本系统必须与证书系统连接，以提供证书发放、认证等工作。本系统也必须使用加密系统保证安全。因此，网银涉及的外部系统还包括安全体系框架Security Framework。
综上所述，本系统作为银行渠道系统，其与外部系统的关系如下图所示：
2.2备选方案分析与选择
通过分析确认，确认了网银产品项目的系统架构采用XX加FSFrame的模式。具体参见《XX网银产品架构选型分析报告》一文。
2.3设计约束和原则
2.3.1设计遵循的标准
由于产品针对中小银行开发，因此必须遵循以下设计原则：
●先进性原则
作为整体解决方案，先进性将综合体现在业务与技术方面：
业务规划先进性：网上银行的建设绝不是技术产品的堆砌，技术解决方案仅仅为适应业务发展、实现经营目标的手段之一，本次网银产品开发在结合国外相关成功经验和国内具体实现的基础上，对网上银行及其相关业务做出领先国内的业务规划。
技术实现先进性：技术规划的先进性与前瞻性，是确保网上银行平台在今后相当一段的时
期内，不断适应业务和应用的发展要求，具备良好可用性的基础，本次网上银行系统解决方案参照领先的FFI产品架构特点，为中小银行建立具有国际技术水准的网上银行平台。
●实用性原则
在网上银行的规划中，无论是技术方案、业务模式、管理手段、经营方式，不仅应具备良好的前瞻性，同时应充分适应中小银行目前的具体情况，避免脱离实际的纸上谈兵，以切实可用、运行良好、效率优异的系统支撑中小银行经营目标的实现。
●稳定性原则
与传统银行业务系统不同，网上银行提供的是直接面对客户的，严格意义上的24×7小时不间断服务，任何原因导致的服务中断都有可能带来严重的问题，而由此可能导致客户信任度的下降对银行而言将是灾难性后果，因此，解决方案将在系统、平台、应用等多方面重点确保稳定性的实现。
●复用性原则
组件复用是网银系统设计中重点遵守的原则之一。本次设计将对可重用的组件进行统一包装，为网银系统提供坚实的服务组件平台基础。
网银系统的可复用组件主要包括系统级的应用组件和应用级的服务组件。其中，系统级的应用组件主要考虑应用服务器和数据库的广泛适用性，对各种企业级服务进行重新包装，以便于提高架构的平台独立性。系统级组件主要包括如：数据聚集服务组件、日值组件、消息组件等；应用级组件主要是为业务系统提供通用的服务组件，以使后续快速地网银业务实现开发。应用级组件主要包括：权限管理服务组件、审批流服务组件、业务配置管理服务组件、报表服务组件等。
●扩展性原则
网银系统必须具有良好地可扩展行，特别是针对中小银行。随着银行业务的不断发展，网银的业务需求也会不断提升。网银系统必须能顺应这种业务的急剧扩展而快速进行业务的扩展开发。这种扩展包括：解决方案的扩展和业务需求的扩展。由于银行服务对象的种类变化，网银必须能快速提供针对不通客户体的业务解决方案。如增加网上支付商户专用的网银解
决方案等；另外，在已有的解决方案上，随着银行新产品新业务的推出，网银系统能够及时地进行业务的调整和新业务的增加。这些需求都要求网银能够快速的进行扩展。
●安全性原则
网上银行带来了业务的扩展性，应用的延伸性、客户的方便性等优势的同时，也带来了风险的集中。网银系统架构的设计将在成熟稳定的硬件环境和应用软件基础上、通过网络、系统、应用、备份恢复、安全控制机制、运行管理监控等手段来保障系统的安全运行。
●平台独立性原则
网银架构的设计必须同时考虑平台独立性的原则。这主要包括：操作系统、应用服务器系统和数据库的广泛适用。
基于以上原则，并考虑系统与神码其他银行系统的集成原则，本系统将采用J2EE架构，用面向对象的原则进行设计和规划。系统的设计将严格遵循公司的有关规定和规范。
2.3.2硬件限制
鉴于目前平台硬件配置情况，本系统设计的硬件限制如下：
服务器类型：一期采用IBM IBM RS/6000 44P（2CPU、2G内存，36G硬盘）；
终端类型：DELL PC（CPU：Pentium4 2.8GH、1G内存，80G硬盘）；
网络环境：内部研发100M网络，服务器和终端位于同一网段，无路由跳转。
2.3.3技术限制
系统设计受到以下技术限制：
Portals技术限制：由于XX的Banking Portals目前采用了Weblogic Portals 8.1，因此，网银的应用服务器只能在Weblogic server上部署。
Integrator技术限制：XX目前的版本是2.0。但新版本并未发布，性能和技术方面存在未知缺陷，可能会对项目技术造成不可预估的影响。
2.3.4其他限制
由于开发项目时间短，人力资源短缺，因此本期主要的目标是：
实现架构体系，为后续开发奠定基础
实现本期指定的必做业务，验证架构的合理性
实现Integrator的业务实现、报文处理和后端接口
在后续的开发中，将逐步完善系统的各个部分，并逐步形成架构清晰，性能优越的网银系统体系架构。
2.4开发平台与技术架构
系统开发采用以下平台：
Eclipse 3.1
Weblogic 8.1
Oracle 9.2i
另外，页面和数据库设计开发可以采用一些辅助工具，不做强制限制。
系统代码的包结构按如下原则划分：
门户接口层：
通用服务接口层：
基础服务层：
业务适配层：
注：各层的定义参见下节内容。
3系统架构
3.1逻辑架构
3.1.1逻辑架构说明
系统的逻辑架构如下图所示：
上图是网银系统的逻辑架构示意图。网银系统从逻辑上分为三个主要模块：为Portals提供接口的门户接口模块；连接后台系统的业务适配器模块；提供基础服务的网银服务模块。
另一方面，从外部系统关系可以看出，网银至少系统需要与渠道整合平台和银行门户进行连接。因此，从逻辑架构上，系统必须有相应的逻辑功能层与之对应；同时，网银系统与其他渠道不同，需要相应的基础服务支撑其业务实现，因此，逻辑结构中也必须有一个专门的功能层提供这些基础服务组件。
另外，网银系统必须为用户提供可以进行业务二次快速开发的体系结构，从逻辑架构上也必须能够保证这一点。这就要求：系统能在具体业务实现上进行可控的扩展开发，而且这些开发不会影响系统的整体性能。
最后，为了最终客户二次开发的接口一致性期间，必须提供一个统一的服务接口层。这样，最终客户的开发将面对统一暴露的服务接口。这样势必简化用户的开发工作。
基于以上原因，系统逻辑架构按照功能范围划分为四层：
●Portal接口层
●通用服务接口层
●基础服务层
●业务适配器层
其中，Portal接口层和通用服务接口层共属于Portal接口模块，另外两层分属于两个模块。
四层之间的关系如下图所示：
以上模块和层次划分的原则是依照2.3.1节设计原则进行的，主要为了保证系统的稳定性、复用性、扩展行和独立性。系统有区别地对各个层暴露不同程度的扩展接口，保证了系统核心的稳定；对通用服务组件统一设计、编写和部署，保证了这些组件的复用性；通用服务接口层的设计可以为用户的后续扩展开发提供保证；而业务适配器的分层设计，保证了系统的后台服务独立性。
以下分别对各层做详细描述，并阐述各个层之间的依赖关系。
3.1.2Portal接口层
3.1.2.1详细描述
门户（Portal）接口层（以下简称“接口层”）为Banking Portals（参见2.1节）提供业务逻辑调用接口。接口层根据不同解决方案的业务需要（参见3.3节的业务功能列表），为业务展现提供实现接口。通过调用业务层和服务层的功能，接口层能提供完整的网银前台业务。
接口层采用Stateless Session Beans实现所有网银前台业务，为Banking Portals提供业务服务，以保证系统性能。
业务展现通过Banking Portals（参见2.1节）实现。另外，由于Portal能提供中间数据的存储机制。因此，接口层的业务可以独立实现，无需考虑会话保持和业务间数据保持等问题。
独立的门户接口层可以保证前端业务扩展时的快速开发要求。在新交易开发中，仅仅需要增加交易的接口，在接口中调用后端业务或服务组件，就能快速提供业务支持，而无需关心业务的具体位置和实现逻辑等。
3.1.2.2依赖关系
Portal接口层只与通用服务接口层和Banking Portals层有关，具体如下：
Portal接口层调用通用服务接口层的服务逻辑接口实现网银服务，因此，Portal接口层依赖于通用服务接口层的功能接口。
Portal接口层为Banking Portals提供业务接口，因此，Portal接口层被Banking Portals层依赖。
3.1.3通用服务接口层
3.1.3.1详细描述
通用服务接口层是为了方便最终客户二次快速开发而提供的服务统一接口层。有了该层，最终用户的二次开发将仅仅面对这一统一的接口进行，而无需了解业务或基础服务的调用关系和顺序。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。