软件项目名称架构设计书

1 软件项目名称架构设计书 说明： 1. 本文件中“ ”中内容为举例和说明文字，请在文件拟制时替换或删除； 2. 若文中某章节内容可省略、不需要或适用，请保留该标题，并根据实际在内容部分写明“略”、“勿需”或“不适用”等，同时适当说明原因 错误 !未指定书签。 当前版本 密级 机密 文档编号 总页数 正文页数 附录页数 编制人 评审人 批准人 编制日期 评审日期 批准日期 模板文档编号 1 页，共 15 页 修改履历 序号 状态 版本 修改内容 修改位置 修改人 日期 评审人 日期 批准人 日期 1 C 建 全文 文艺 2010/11/8 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 状态： C 创建文档， A 增加内容， M 修改内容， D 删除内容 2 页，共 15 页 目 录 1. 文档概述 . 4 目标 . 4 范围 . 4 术语和缩略语 . 4 2. 整体说明 . 4 方案 . 4 架构约束 . 5 整体概要 . 5 统上下文 . 5 体架构 . 6 3. 应用层 . 6 设计思路 . 6 结构视图 . 6 构框架 . 6 部服务 . 6 配置视图 . 6 置视图 . 7 置描述 . 7 行为视图 . 7 键问题的技术解决方案 . 7 署视图 . 7 心架构模式及设计模式 . 8 型用例流程 . 8 进程视图 . 8 升级注意事项 . 8 集成方案 . 8 4. 虚拟平台层 . 8 5. 应用基础层 . 8 固化在平台中的机制 . 9 自定义机制 . 9 软件要求 . 9 6. 企业服务层 . . 9 配置视图 . 9 升级注意事项 . 9 7. 计算 &存储层 . 9 升级注意事项 . 11 8. 网络基础层 . 11 配置视图 . 11 9. 设 备 . 11 3 页，共 15 页 10. 服务级别需求 . 11 列举服务级别需求 . 11 能、吞吐量和可伸缩性 . 12 用性和可靠性 . 12 全性 . 12 管理性 . 12 用性 . 12 维护性 . 12 展性和灵活性 . 13 重用性 . 13 11. 容灾设计 . 13 容灾目标值 . 13 容灾环境 . 13 关联系统容灾要求 . 14 其他补充说明 . 14 12. 风险 . 14 技术风险列表 . 14 风险识别 . 14 4 页，共 15 页 1. 文档概述 建立上下文，提出所有读者在下面章节期望看到的内容。 目标 请说明此系统完成后，达到什么架构目标，产生什么架构意义。或者对别的系统架构可以提供什么借签 . 例如，构建 2用的开发框架，使所有系统能规 范开发组件，提高开发效率，易于统一升级和维护 范围 列出本系统支持的业务范围，包括时间使用年限，业务需求范围，包括已确定支持的业务需求和未明确确定的业务需求。如果有未明确的业务需求，需要说明如果需求变更的话，采取什么措施 列出所有和当前架构有关的参考文档，包括每一个确定的标题、版本、日期以及发布组织。详细说明资料的出处，也可以通过一个附件或另一个文档提供。需求分析可参看需求分析文档 术语和缩略语 定义本文档中所有的术语和缩略语。 序号 术语 /缩略词 说明 1 2 3 4 5 表 错误 !文档中没有指定样式的文字。 1 术语表 2. 整体说明 方案 概述架构设计的方法，包括简要的方法论描述。定义系统中不同的视图，然后叙述本系统架构说明书中使用到的那些视图。 的架构方案是基于 架构方法论，由可伸缩性、安全性、可维护性等服务级别需求所驱动。依次分析逻辑层 技术层 下图的图示： 5 页，共 15 页 图 1 架构框架 系统描述是通过一组架 构视图来组织的，每一个视图都是从不同观点描绘系统特征的一个方面。系统层由大量的视图组织起来。 以每个或组服务级别需求作为一个次标题，加入架构设计中如何达到其需求的描述，需要的话引用其它视图；最后用一个总的服务级别需求视图把这些内容串联起来。 视图对读者是很有帮助的。不同的读者在特定的时间可能只对部分的视图感兴趣。 以下章节描述架构建立目标和约束，以及高层次系统整体概要。本节也描述后续章节从不同侧面检验系统架构的上下文环境。 架构约束 本节需描述四方面的内容。 1）本系统最受关注的前几个服务级别需求对架构 的要求。（详细的服务级别需求可以在服务级别需求部分表述） 2）是否是基于外购系统。（全部基于或部分基于外购系统或全部自主研发） 3）本系统的架构适用范围。（只适用本系统还是可以适用于其余系统或者部分可适用于其余系统。如果是部分可适用于其余系统，则需要描述架构模式） 4）本系统的技术约束（需依赖的技术），对团队成员的约束（如成员需要掌握的技能），软硬件约束等。 整体概要 提供一个架构的整体性说明。因为在后续的章节中，都是按层（ 组织该层（ 视图，本概述章节就更适合把所有层（ 作为一个整体来考虑，而不是分层（ 描述。通常，划分层 (很有用的，突出（加亮）每级的关键点，这些关键点包括主要的外部实体（如终止用户访问的节点和遗留系统）。主要的架构特征列表，如：独立供应商、一致的行业标准、产物的构思等。同一类架构特征应该放进整体说明中描述。 统上下文 描述本系统与参与者（内部、外部）的关联关系 6 页，共 15 页 体架构 描述系统整体架构 3. 应用层 本节在均衡考虑架构统一原则的基础上 ,通过分解对应用层的功能进行讨论。从概要地描述应用层各独立视图开始， 例如：分别对比静态和动态的结构视图，分别对比静态和动态的配置视图。 设计思路 整体描述应用层整体的设计思路 ,例如使用 构作为基础框架代码 ;存在 其原因等 . 结构视图 当需要进行开发时，描述架构上重要的包和它们之间编译时的静态依赖关系。选择的分解应该详细阐述每条定义明确的分解规则，例如：分层、分类、概括等。一旦包括各等级的小节，就可以用一个等级分层的概要图表作为开始，然后用更加详细的图表描述架构上比较重要的部分。所有的图表中对每个包的描述，应该包括它们的职责和 资源（自定义的、可重用的、成本等）的描述。 本小节可以放到本节开头部分，但是要先于各小节提出。无论是放在此处还是其他地方，推荐保留次级标题，即使内容是空的，也要作为详尽阐述的占位符。 构框架 描述 统的所有代码框架结构 部服务 描述调用的外部接口或对外提供的外部接口 用关联系统的服务 描述使用关联系统的服务 关联系统提供的服务 描述为关联提供提供的服务 ,可以参见接口文档的服务 配置视图 逐条描述各应用模块的配置 ，包括这些模块的物理位置、运行时的交互。为此，可以使用模块结构图覆盖展开图。为不同的配置提供适合的多样的图表，可能需要产品的例子、或配置于不同环境中的产品的例子、决定支持配置与交易配置不同之处的例子。当描述各种配置时，应当定义为每项配置所选的配置策略。 注明底层的详细信息将在稍后的独立配置视图中获取，所以最好在此赘述一下相关的视图信息。 7 页，共 15 页 置视图 置描述 如果有需要，可以在视图后加入对配置的描述 行为视图 当某些架构设计对子系统的功能有影响，而不是影响子系统的划分 时，本节描述对子系统的功能有影响的架构设计；这些设计不会影响子系统的划分。以下小节可以使用，也可以适当的删减。 本节是下面小节的代表。推荐保留次级标题，即使内容是空的，也要作为详尽阐述的占位符。 键问题的技术解决方案 描述架构上在各层的关键决定和架构设计方案在系统各层的考虑，以及架构重要用例涉及的技术解决方案 ,也包括可重用组件设计方案。下面是一个简单的格式例子。 决方案的分层描述 下表通过分层概述通用的设计方法，每行对应一个架构上的决定和在各层的解决方案。 关键问题 /组件 表示层 业务层 资源层 示 集合处理 查询 导航 完整性管理 事务控制 表 1 关键问题技术解决方案 决方案详述 如果有需要，可以详细描述关键问题的解决方案和思路。对于可重用组件，需要描述详细解决方案。 署视图 署逻辑图 署注意 事项 8 页，共 15 页 心架构模式及设计模式 心架构模式 描述系统特有的架构模式，例如使用 构等 心架构模式中使用到的设计模式 描述架构模式中使用到的设计模式 型用例流程 描述所有保留的典型的或比较有价值的系统里动态（基于时间）相互作用的例子的详细设计。 典型用例的目的是让设计人员可以参考典型用例来对其他用例进行详细设计。例如抽取报表模块中的一个典型的用例进行详细设计，其他报表详细设计可以参考此用例。 架构重要用例必须在典型用例流程中有详细描述 . 进程视图 说明贯穿系统的交互流程同步和异步的方式，焦点是影响质量上的（如：吞吐量、可靠性、实用性等）宏命令。 本节是小节中的典型。推荐保留次级标题，即使内容是空的，也要作为详尽阐述的占位符。 升级注意事项 描述系统升级时应用层的架构应该随之做出的改进。例如，可能预先增加一项参数或增加对另一个系统的接口，将功能性从中分离出来。 集成方案 描述系统内部和外部需要集成的组件；集成的顺序；集成的工具等 4. 虚拟平台层 如果存在为独立供应商访问应用基础架构层而提供的标准层，应当描述标准层。最好的例子使 也可以包括其他的标准，如基于 标准。（需要说明的是，应用程序可能以任何格式提供服务器，但是这些应该放在应用层里进行描述，本节的焦点仅仅是应用程序使用什么到达下一层。） 选 2 的服务器平台。 开发多级企业应用软件的工业标准平台。它提供一个位于中间层机制的顶端的虚拟平台，解开很多机制的限制 ，同时简化和加快了整个开发过程。同时提供了对现有应用程序集成最强有力的支持，最大化将来变更的选择权。 5. 应用基础层 本章描述前面所述各层的基础层，但要注意是从前面没提到过的角度来描述。例如，供应商提供的产品架构上的描述，可能更有价值。 固化在平台中的机制 描述系统要求的各种机制。包括一个关于机制的列表 9 页，共 15 页 用程序中。对运行的机制、访问和管理应用程序接口的机制，如下的列表可以作为一个大致的轮廓。 容器 平台 接口 (管理接口(机制(客户端 表示层 业务层 集成层 资源层 图 5举所有机制 自定义机制 如果有任何自定义的机制上一节中没有说到，就在本节描述。为此，可以使用静态和动态的 描述各种机制，同时可以包含必要的改进注意事项。 软件要求 描述部署逻辑实体的软件版本信息 部署逻辑实体 软件版本信息 6. 企业服务层 . 描述支持与本系统相关的或依赖的服务器环境。 配置视图 描述在应用层下，直接或间接支持应用层的配置。包括应用层整合 不太明显的一些细节，如： 用配置图，随意地描绘一下架构上的重要过程或行为视图中的主线。 升级注意事项 描述架构预期到的改进 ,如何配合计算 &存储层预的架构升级做调整。 7. 计算 &存储层 列举计算设备和封装格式存储器等硬件 /系统级的组件 注意事项： 1. 评估指南参考基础架构资源需求评估单 A,础架构讨论再确定。 4. 除明确说明外 , 生产对应的灾备资源会由公式计算获得 . 详细的公式参考 基础架构资源需求评估单 5. 非平安标准的 软件版本需要特别说明，参考平台软件版本清单表 下表为系统运行的硬件 /软件组件 : 10 页，共 15 页 资源名称 适用范围 评估点 评估结果 评估依据 高端生产 001 普通 用的1)业务数据量 (2)索引数据量 ( 生产： 高端生产 002 性能要求较高的 磁盘组的整体 I/3 1)业务数据量 (2)索引数据量 ( 生产： 中端 001 普通文件的存放，非关键系统 1) 需 要 评 估 生 产 和个环境 2)业务所需的存储空间数量 ( 生产： 业务所需的存储空间数量( 中端 002 对性能和可用性要求较高的应用，如 B、) 需 要 评 估 生 产 和个环境 2)业务所需的存储空间数量 (生产： 001 归档应用，如邮件归档、影像归档、日志归档、备份归档等应用，配置 性能和可用性要求较低 1) 需 要 评 估 生 产 和个环境 2)业务所需的存储空间数量 (生产： 002 通用的 保存、 置光纤盘柜 1) 需 要 评 估 生 产 和个环境 2)业 务所需的存储空间数量 (生产： 生产 1)网络分区 2)需要的 3)非平安标准的 生产： 非 所使用的应用软件需要运行在 1)网络分区 2)依据厂商针对平安的业务规模提供的硬件配置要求，和资源负责人讨论后决定 3)非平安标准的 4)需要评估生产 ,灾备和个环境 生产： 灾备 : 1、应用以 22、服务器不进行大量消耗I/统主要资源需求为内存（ 1)网络分区 2)3)4)非平安标准的 生产： 非 1、应用架构中有外购软件需要部署在 、应用架构自行开发部分有非标准架构、或不符合 1)网络 分区 2)需要的 3)非平安标准的 1 1个 应用要求的 包含系统盘空间 生产： 升级注意事项 预期的改进明细表，例如：所选模块的扩展性或升级能力，或者系统在某些地方的设计更易于添部分加可复制的节点等等。 11 页，共 15 页 8. 网络基础层 配置视图 描述物理上的配置，包括运算和存储资源，以及它们之间相互连接的网络。细分应包括路由器、防火墙、子网、主要的 /次级的服务器等等。本视图应该补充应用层 /配置视图，以确保各组件在本视图中描绘得更加详 细。例如：用框图代替视图中的抽象概念。 9. 设备 论述设备要求，如：空间维度、马力、热量等环境要求，以及进入场地的安全要求（如身份技术鉴定）等。 10. 服务级别需求 本节包含所有和服务级别需求相关的因素，可以增加副标题分别列举各项。本节以下是选取格式的一个提纲。 列举服务级别需求 详细阐述各项重要的服务级别需求参数（像需求规格说明书中标识一样）。可以使用立体视图，附加一些文字描述。以下是各个服务级别需求参数都应当提到的几项。 直接需求和衍生需求。直接需求就是在需求规格说明书中列出的那些需求，在此只是对 这些信息必要的重复。衍生需求虽然没有在需求规格说明书中列出，但却是满足直接需求的技术上的必要条件。例如，架构里使用一个遗留组件时，一个直接的吞吐量需求可能隐藏着一个衍生的吞吐量需求。 使用的策略。架构怎样提出这些系统性能？参考其他视图，并避免对已提出的性能进行考证所产生的冗余。 将来的变更。确定为了支持版本预期的升级而在架构里合并的内容。例如，可伸缩性对吞吐量。 12 页，共 15 页 能、吞吐量和可伸缩性 求 构解决方案 进注意事项 用 性和可靠性 求 构解决方案 进注意事项 全性 求 构解决方案 进注意事项 管理性 求 构解决方案 进注意事项 用性 求 构解决方案 进注意事项 维护性 求 构解决方案 进注意事项 13 页，共 15 页 展性和灵活性 求 构解决方案 进注意事项 重用性 求 构解决方案 进注意事项 11. 容灾设计 本节描述本系统的容灾目标和容灾方案，容灾方案需列出支持本系统容灾的各支持环节的容灾要求，各环节容灾方案默认为 台容灾方案，不同于平台方案的地方要做说明。 容灾目标值 容灾环境 描述本系统依赖的环境容灾方案要求，如果同 台容灾方案要求一样可以填写同标准，需说明本系统不同于 台容灾方