《软件项目名称架构设计书》由会员分享，可在线阅读，更多相关《软件项目名称架构设计书（15页珍藏版）》请在金锄头文库上搜索。
1、软件项目名称架构设计书说明： 1. 本文件中“”中内容为举例和说明文字，请在文件拟制时替换或删除；2. 若文中某章节内容可省略、不需要或适用，请保留该标题，并根据实际在内容部分写明“略”、“勿需”或“不适用”等，同时适当说明原因 错误!未指定书签。当前版本0.0.1 密级机密文档编号总页数正文页数附录页数编制人评审人批准人编制日期评审日期批准日期模板文档编号147d4642bbae1d6f65cde8a81a9c07b16.doc修改履历序号状态版本修改内容修改位置修改人日期评审人日期批准人日期1C0.0.1新建全文文艺2010/11/8234567891011121314151617状态：C
2、创建文档，A增加内容，M修改内容，D删除内容目 录1. 文档概述41.1. 目标41.2. 范围41.3. 术语和缩略语42. 整体说明42.1. 方案42.2. 架构约束52.3. 整体概要52.3.1系统上下文52.3.2整体架构63. 应用层63.1. 设计思路63.2. 结构视图63.2.1结构框架63.2.2外部服务63.3. 配置视图63.3.1 配置视图73.3.2 配置描述73.4. 行为视图73.4.1关键问题的技术解决方案73.4.2部署视图73.4.3核心架构模式及设计模式83.4.4典型用例流程83.5. 进程视图83.6. 升级注意事项83.7. 集成方案84. 虚拟
3、平台层85. 应用基础层85.1. 固化在平台中的机制95.2. 自定义机制95.3. 软件要求96. 企业服务层.96.1. 配置视图96.2. 升级注意事项97. 计算&存储层97.1. 升级注意事项118. 网络基础层118.1. 配置视图119. 设备1110. 服务级别需求1110.1. 列举服务级别需求1110.1.1性能、吞吐量和可伸缩性1210.1.2可用性和可靠性1210.1.3安全性1210.1.4可管理性1210.1.5易用性1210.1.6可维护性1210.1.7扩展性和灵活性1310.1.8可重用性1311. 容灾设计1311.1. 容灾目标值1311.2. 容灾环境
4、1311.3. 关联系统容灾要求1411.4. 其他补充说明1412. 风险1412.1. 技术风险列表1412.2. 风险识别141. 文档概述建立上下文，提出所有读者在下面章节期望看到的内容。1.1. 目标请说明此系统完成后，达到什么架构目标，产生什么架构意义。或者对别的系统架构可以提供什么借签.例如，构建XX J2EE应用的开发框架，使所有系统能规范开发组件，提高开发效率，易于统一升级和维护1.2. 范围 列出本系统支持的业务范围，包括时间使用年限，业务需求范围，包括已确定支持的业务需求和未明确确定的业务需求。如果有未明确的业务需求，需要说明如果需求变更的话，采取什么措施列出所有和当前架
5、构有关的参考文档，包括每一个确定的标题、版本、日期以及发布组织。详细说明资料的出处，也可以通过一个附件或另一个文档提供。需求分析可参看需求分析文档1.3. 术语和缩略语 定义本文档中所有的术语和缩略语。序号术语/缩略词说明12345表 错误!文档中没有指定样式的文字。1 术语表2. 整体说明2.1. 方案概述架构设计的方法，包括简要的方法论描述。定义系统中不同的视图，然后叙述本系统架构说明书中使用到的那些视图。的架构方案是基于Sun Tone的架构方法论，由可伸缩性、安全性、可维护性等服务级别需求所驱动。依次分析逻辑层tier和技术层layer，如下图的图示：图1 架构框架系统描述是通过一组架
6、构视图来组织的，每一个视图都是从不同观点描绘系统特征的一个方面。系统层由大量的视图组织起来。以每个或组服务级别需求作为一个次标题，加入架构设计中如何达到其需求的描述，需要的话引用其它视图；最后用一个总的服务级别需求视图把这些内容串联起来。视图对读者是很有帮助的。不同的读者在特定的时间可能只对部分的视图感兴趣。以下章节描述架构建立目标和约束，以及高层次系统整体概要。本节也描述后续章节从不同侧面检验系统架构的上下文环境。2.2. 架构约束本节需描述四方面的内容。1）本系统最受关注的前几个服务级别需求对架构的要求。（详细的服务级别需求可以在服务级别需求部分表述）2）是否是基于外购系统。（全部基于或部
7、分基于外购系统或全部自主研发）3）本系统的架构适用范围。（只适用本系统还是可以适用于其余系统或者部分可适用于其余系统。如果是部分可适用于其余系统，则需要描述架构模式） 4）本系统的技术约束（需依赖的技术），对团队成员的约束（如成员需要掌握的技能），软硬件约束等。2.3. 整体概要提供一个架构的整体性说明。因为在后续的章节中，都是按层（layer）来组织该层（layer）的视图，本概述章节就更适合把所有层（layer）作为一个整体来考虑，而不是分层（layer）来描述。通常，划分层(tier)是很有用的，突出（加亮）每级的关键点，这些关键点包括主要的外部实体（如终止用户访问的节点和遗留系统）。主
8、要的架构特征列表，如：独立供应商、一致的行业标准、产物的构思等。同一类架构特征应该放进整体说明中描述。2.3.1系统上下文描述本系统与参与者（内部、外部）的关联关系2.3.2整体架构描述系统整体架构3. 应用层本节在均衡考虑架构统一原则的基础上,通过分解对应用层的功能进行讨论。从概要地描述应用层各独立视图开始，例如：分别对比静态和动态的结构视图，分别对比静态和动态的配置视图。3.1. 设计思路整体描述应用层整体的设计思路,例如使用SSH架构作为基础框架代码;cache缓存在app Server及其原因等.3.2. 结构视图当需要进行开发时，描述架构上重要的包和它们之间编译时的静态依赖关系。选择
9、的分解应该详细阐述每条定义明确的分解规则，例如：分层、分类、概括等。一旦包括各等级的小节，就可以用一个等级分层的概要图表作为开始，然后用更加详细的图表描述架构上比较重要的部分。所有的图表中对每个包的描述，应该包括它们的职责和资源（自定义的、可重用的、成本等）的描述。本小节可以放到本节开头部分，但是要先于各小节提出。无论是放在此处还是其他地方，推荐保留次级标题，即使内容是空的，也要作为详尽阐述的占位符。3.2.1结构框架 描述XX系统的所有代码框架结构3.2.2外部服务 描述调用的外部接口或对外提供的外部接口3.2.2.1使用关联系统的服务描述使用关联系统的服务3.2.2.2为关联系统提供的服务
10、描述为关联提供提供的服务,可以参见接口文档的服务3.3. 配置视图逐条描述各应用模块的配置，包括这些模块的物理位置、运行时的交互。为此，可以使用模块结构图覆盖展开图。为不同的配置提供适合的多样的图表，可能需要产品的例子、或配置于不同环境中的产品的例子、决定支持配置与交易配置不同之处的例子。当描述各种配置时，应当定义为每项配置所选的配置策略。注明底层的详细信息将在稍后的独立配置视图中获取，所以最好在此赘述一下相关的视图信息。3.3.1 配置视图3.3.2 配置描述 如果有需要，可以在视图后加入对配置的描述3.4. 行为视图当某些架构设计对子系统的功能有影响，而不是影响子系统的划分时，本节描述对子
11、系统的功能有影响的架构设计；这些设计不会影响子系统的划分。以下小节可以使用，也可以适当的删减。 本节是下面小节的代表。推荐保留次级标题，即使内容是空的，也要作为详尽阐述的占位符。3.4.1关键问题的技术解决方案 描述架构上在各层的关键决定和架构设计方案在系统各层的考虑，以及架构重要用例涉及的技术解决方案,也包括可重用组件设计方案。下面是一个简单的格式例子。3.4.1.1解决方案的分层描述下表通过分层概述通用的设计方法，每行对应一个架构上的决定和在各层的解决方案。关键问题/组件表示层业务层资源层DOM 表示集合处理查询API导航API完整性管理事务控制表 1 关键问题技术解决方案3.4.1.2解
12、决方案详述如果有需要，可以详细描述关键问题的解决方案和思路。对于可重用组件，需要描述详细解决方案。3.4.2部署视图3.4.2.1部署逻辑图3.4.2.2部署注意事项3.4.3核心架构模式及设计模式3.4.3.1核心架构模式描述系统特有的架构模式，例如使用AJAX架构等3.4.3.2核心架构模式中使用到的设计模式描述架构模式中使用到的设计模式3.4.4典型用例流程描述所有保留的典型的或比较有价值的系统里动态（基于时间）相互作用的例子的详细设计。典型用例的目的是让设计人员可以参考典型用例来对其他用例进行详细设计。例如抽取报表模块中的一个典型的用例进行详细设计，其他报表详细设计可以参考此用例。架构
13、重要用例必须在典型用例流程中有详细描述.3.5. 进程视图说明贯穿系统的交互流程同步和异步的方式，焦点是影响质量上的（如：吞吐量、可靠性、实用性等）宏命令。本节是小节中的典型。推荐保留次级标题，即使内容是空的，也要作为详尽阐述的占位符。3.6. 升级注意事项描述系统升级时应用层的架构应该随之做出的改进。例如，可能预先增加一项参数或增加对另一个系统的接口，将功能性从中分离出来。3.7. 集成方案描述系统内部和外部需要集成的组件；集成的顺序；集成的工具等4. 虚拟平台层如果存在为独立供应商访问应用基础架构层而提供的标准层，应当描述标准层。最好的例子使J2EE，但也可以包括其他的标准，如基于SNMP、LDAP和XML的标准。（需要说明的是，应用程序可能以任何格式提供服务器，但是这些应该放在应用层里进行描述，本节的焦点仅仅是应
