软件架构设计模板讲解.doc

上传人:牧羊曲112 文档编号:4090190 上传时间:2023-04-03 格式:DOC 页数:17 大小:126KB
返回 下载 相关 举报
软件架构设计模板讲解.doc_第1页
第1页 / 共17页
软件架构设计模板讲解.doc_第2页
第2页 / 共17页
软件架构设计模板讲解.doc_第3页
第3页 / 共17页
软件架构设计模板讲解.doc_第4页
第4页 / 共17页
软件架构设计模板讲解.doc_第5页
第5页 / 共17页
点击查看更多>>
资源描述

《软件架构设计模板讲解.doc》由会员分享,可在线阅读,更多相关《软件架构设计模板讲解.doc(17页珍藏版)》请在三一办公上搜索。

1、架构设计说明书产品发布标识填写说明:模板中用方括号括起来并以蓝色斜体显示的文本,用于向作者提供指导,在文档编辑完成后应该将其删除。文档正文应使用常规、黑色、五号字体即系统设置的“正文”样式文档页眉处的”xxxx系统”和“版本号”仅为示例,请注意更新封页与页眉符合实际情况。此处的版本号指的是产品版本号封页简要表中的产品名,如无可以不填写。当某一章/节没有内容时,必须注明N/A,同时标注理由。例如:本章/节内容无需考虑。特别说明:当某章/节内容参见其它文档时,不能注明N/A,而应该写明参见某文档的具体章节。文档版本号:文档编号:文档密级:归属部门/项目:产品名:子系统名:编写人:编写日期:华为科技

2、(深圳)有限公司 版权所有内部资料 注意保密修订记录:版本号修订人修订日期修订描述V1.0A王巍2004-5-11创建初稿V1.0B周昀2006-4-23根据CMMI新流程予以修订V1.0CENG-TWG2006-8-9根据CMMI要求予以修订派发清单: 发文人/部门日期电话/传真受文人/部门动作类型*日期电话/传真动作类型:批准、审核、通知、归档、参与会议,其它(请说明)目 录1 简介61.1 目的61.2 文档范围61.3 预期的读者和阅读建议61.4 参考文档81.4.1 包含文档81.4.2 相关文档81.5 缩略语和术语82 总体设计思路92.1 设计方法92.2 设计可选方案93

3、系统逻辑结构103.1 总体结构103.2 子系统定义103.2.1 子系统一113.2.2 子系统二113.3 接口设计113.3.1 产品外部接口113.3.2 子系统间接口113.4 主要数据模型114 系统物理结构124.1 总体结构124.2 组件定义124.2.1 组件一124.3 组件接口设计124.4 组件与子系统对应关系125 系统部署135.1 网络结构图135.2 部署模式136 关键技术及公用机制136.1 关键技术设计136.2 公用机制说明137 系统重用设计137.1 第三方硬件设备说明157.2 第三方软件说明158 系统非功能特性设计158.1 可扩展性158

4、.2 可维护性158.3 安全168.4 容错性168.5 可移植性168.6 可部署性168.7 169 总体约束169.1 遵循标准169.2 文件约定179.3 目录约定179.4 对后续设计的约束179.5 1710 风险1711 附录171 简介1.1 目的描述本架构设计文档的主要目的。架构文档从构架方面对系统进行综合概述,描述了系统最高层次上的逻辑结构、物理结构以及各种指南。它用于记录并表述已在构架方面对系统作出的重要决定,并对相关子系统的设计起总体上的指导作用。1.2 文档范围简要说明此文档的范围:它的相关项目以及受到此文档影响的任何其它事物例如,本文档适用的产品、模块,覆盖的范

5、围等,受这份文档影响的相关产品、模块等,不在该文档覆盖范围内的但可能引起疑义的问题。1.3 预期的读者和阅读建议说明此文档的阅读对象,简要说明此文档中其它章节包含的内容与文档组织方式,对于不同读者的阅读方式建议。如:XXX系统开发过程的各角色:产品角色、系统分析架构角色、项目管理角色、代码角色、测试角色、文档角色XXX系统的部署角色、培训角色、维护角色;XXX公司售前技术支持角色此文档的第2章描述.系统体系结构图例如:本文档组织方式:第一章 简介,描述文档的目的;第二章 描述总体设计思路,包括设计方法及备选设计方案和方案的选择;第三章 描述系统的逻辑结构。从最高层次上描述系统的逻辑组成;第四章

6、 描述系统的物理结构。从最高层次上描述系统的物理组成;第五章 描述系统的部署情况;第六章 对系统架构中的关键技术及公用设计机制进行描述;第七章 如何重用以往设计产物及现有设计如何对将来重用产生影响进行描述;第八章 对系统中重要的用例或者有技术难度的部分进行功能实现的描述,以方便设计人员在进行设计、开发时进行参考;第九章 对系统依赖的第三方软硬件进行描述;第十章 对系统的非功能特性设计进行描述;产品经理应当关注该部分的描述是否与产品需求中产品的非功能性需求一致;开发人员应当在后续设计过程中对这部分设计进行关注,避免遗漏;测试人员应当根据这部分的描述制定测试案例,验证是否可以达到产品需求的要求。第

7、十一章 描述系统架构设计中的约束条件;第十二章 描述架构设计中识别的风险,产品经理、设计人员、开发人员和测试人员都应当随时关注这些风险,避免风险发生并及时采取规避、减轻措施。第十三章 附录1.4 参考文档架构设计的参考文档应当包括但不限于:产品需求说明书等;同时,文档中说明为引用、参考的文档也应该在这里列出。参考文档需要按包含、相关的关系分别在下面的小节中列出。1.4.1 包含文档当本文有包含文档时,需要提供相关的包含文档列表。包含文档:作为本架构设计的一部分,是不可分割的组成部分,读者阅读本架构设计时必须同时也阅读的文档。如当架构设计非常复杂而有分册时,则分册就属于本文档的包含文档。1.4.

8、2 相关文档当本文有相关文档时,需要提供相关文档列表。 相关文档:具有关联关系的文档。读者在阅读架构说明书时如果有必要可以参考阅读的文档。1.5 缩略语和术语适当时,提供与此文档相关的术语及缩略语的定义。缩略语/术语全 称说 明2 总体设计思路2.1 设计方法本软件系统所采取的设计方法,以及主要的设计原则。设计方法可包括但不限于:1)采用RUP的设计方法论;2)采用从业务而下的系统分解,从技术至上的系统抽象方法以及具体应用系统的特定设计方法等。2.2 设计可选方案对本系统的几种设计方案进行分析、比较,并确定所采用的方案。可选方案不仅是对同一需求的不同处理方式,也可以是需求与设计元素之间配置的不

9、同思考,包括新研发的技术,或者是不同应用的成熟技术及维持现有方法,目标是将整体的解决方案最佳化,而非个别设计的优劣。可选解决方案涵盖可接受的成本、计划、效能的范围。产品关键需求与设计问题、限制及准则一起用于开发备选方案。评选的准则通常必须强调成本(例如:时间、人员、费用)、效益(例如:性能、有效性)及风险(例如:技术、成本、计划)。详细的可选解决方案及评选的准则可包括但不限于:成本(研发、购买、支持、产品生命周期)技术性能技术限制产品的扩展及成长性需求与技术的演进最终用户及操作者的能力与限制构建方法与材料的敏感度风险以上为最基本的考虑因素,研发团队应该开发与目标一致的备选方案节选准则,以缩小可

10、选清单,并可以通过决策分析的方法来进行评估选择。例如:1)可选方案一 2)可选方案二 3)方案的评选策略及准则 需要包括决策分析单。4)最佳化的方案 3 系统逻辑结构本章描述系统的总体逻辑结构,包括子系统的划分与依赖关系定义、子系统之间的接口定义、子系统功能定义。3.1 总体结构本节定义系统的总体逻辑结构,定义子系统划分以及子系统之间的依赖关系。为了统一与便于理解,当用图形化表示子系统、子系统之间的依赖关系时,建议采用UML的符号与表示方法。3.2 子系统定义本节明确定义各个子系统的功能以及子系统的设计思路,本节通常按照子系统进行组织。3.2.1 子系统一包括:子系统概述子系统功能子系统设计思

11、路3.2.2 子系统二3.3 接口设计定义接口设计的策略,识别接口,以及接口完成的功能,具体接口定义另行定义文档承载,采用接口设计说明书模板。3.3.1 产品外部接口描述产品对外接口的相关定义。3.3.2 子系统间接口描述产品内部子系统间接口的相关定义。3.4 主要数据模型 本节在逻辑层面上定义系统所包含的主要数据模型,通常以E-R图形式来表现。具体的数据字典及数据结构在数据库设计文档中定义,在高层设计阶段完成。4 系统物理结构定义系统总体物理结构、包括组件划分及依赖关系定义,每个组件中要完成的功能及组件间接口。如功能已经在前面的子系统分解中有描述,则重点描述本组件完成了哪些子系统的哪些功能。

12、组件是物理上的运行结构元素。例如:进程、线程等。4.1 总体结构本节定义系统的总体物理结构,定义组件划分以及组件之间的关系。4.2 组件定义4.2.1 组件一包括:组件名称组件类型组件功能4.3 组件接口设计定义接口设计的策略,组件间的接口主要是描述一些共享内存,协议数据,消息等,具体接口如有需要可另行定义文档承载,采用接口设计说明书模板4.4 组件与子系统对应关系定义组件与子系统的关系,即各组件实现哪些子系统功能,可通过列表的形式定义,如有需要,可通过图示的形式加以说明。5 系统部署本章描述系统部署,说明用来部署并运行该系统的一种或多种物理网络(硬件)配置。对于每种配置,应该指出执行该系统的

13、物理节点(计算机、网络设备)配置情况(包括硬件、操作系统、支撑软件)、节点之间的连接方式、采用何种通信协议、网络带宽。另外还要包括各进程到物理节点的映射。5.1 网络结构图描述系统所处的整体网络结构。5.2 部署模式描述系统几种可能的部署模式,并解释在定义配置时要遵循的一般映射规则。例如:在不同的业务规模情况下,存在的不同部署模式。6 关键技术及公用机制6.1 关键技术设计描述系统的关键技术设计,以解决重要或高风险的问题6.2 公用机制说明描述系统实现所需要的公用机制,例如采用的中间件技术、通用缓存等7 系统重用设计软件重用是指通过对已有软件的各种有关知识来建立新的软件,这些知识包括:领域知识

14、、开发经验、设计经验、设计决定、体系结构、需求、设计、编码、测试和文档等。这个定义蕴含着软件重用所必须包含的两个方面: 1. 系统地开发可重用的软件产品。2. 系统地使用这些软件产品作为构筑新的软件产品,来建立新的系统。 软件重用目的是降低软件开发和维护的成本,提高软件开发效率,提高软件的质量。软件重用的过程一般包括,抽象、选取、特化、集成:抽象,对已有软件产品的概念描述,从中抽取该产品的本质信息(即可重用部分)。选取:用户根据已有软件产品的抽象,寻找、比较和选择最适合需要的软件产品(可重用件)。特化:对已有软件产品(可重用件)的修改或形成它的一个实例(实例化后的重用件)。集成:将实例化后的重

15、用件集成到应用系统。软件重用的形式,常用的为垂直式重用和水平式重用:垂直式重用:指在一类具有较多公共性的应用领域之间进行软件重用,由于存在许多共性或相似性,因此重用面较广,且有助于获得系统的通用模型。 首先进行领域分析,根据应用领域的特征及相似性预测软件的可重用性;然后进行相应的软件开发。一旦确认了软件的重用价值,即可进行通用化,以便能够适应新的类似的应用领域;最后,对软件及其文档进行管理,成为可供后续项目使用的可重用资源。水平式重用:重用不同应用领域中的软件元素,例如数据结构、分类算法、人机界面构件等。标准函数库是一种典型的原始的水平式重用机制。软件重用的粒度主要有以下几种: 1. 源代码模

16、块或者类一级的重用。这是最基本的软件重用形式。 2. 二进制形式的重用。如组件重用。 3. 组装式重用。比如:把好几个应用程序的功能集成在一起。例如,要建立一个门户站点应用,登陆用户既可以查询天气情况,又可以查看股市行情,还可以在线购物。这些功能由不同网络应用服务供应商提供,通过这种组装式重用,就可以非常容易地把上述功能都集成到新的门户站点中。 4. 分析级别重用。 5. 设计级别重用。 6. 软件文档重用。 软件重用技术 软件重用技术包括: 库函数,模板,面向对象、设计模式、构件、体系架构、体系架构模式/风格等。 1. 库函数对于库函数的使用者,只要知道函数的名称,返回值的类型, 函数参数和

17、函数功能就可以对其进行调用。 2. 面向对象面向对象技术通过方法、消息、类、继承、封装、和实例等机制构造软件系统,并为软件重用提供强有力的支持。如VC+中的MFC。 3. 模板模板相当于工业生产中所用的“模具”。有各种各样的模板(如文档模板,网页模板等),利用这些模板可以比较快速地建立对应的软件产品。模板把不变的封装在内部,对可能变化本号,运行环境,参数以及简要描述7.1 第三方硬件设备说明描述系统可使用的第三方硬件需求,以及第三方硬件的简要描述。例如:需要加密卡提供高速逻辑加密功能;需要网络交换机提供四层交换功能等。7.2 第三方软件说明描述系统可使用的第三方软件需求,以及第三方软件的简要描

18、述。8 系统非功能特性设计本章描述系统的整体性能、安全性、可用性、可扩展性、容错等非功能特性设计。8.1 可扩展性描述系统可扩展性设计与实现方案。需要对性能、功能、网管/审计、报表的可扩展性进行描述。例如:考虑组件化设计,以使系统能够适应将来可能出现的新业务和可能出现的一些变化。新增业务功能时不应需要改造原软件系统,可通过动态加载新增组件的方式实现。 描述系统性能设计与实现方案。例如:采用多种数据/对象的缓存机制;采用并发处理机制;采用异步处理方式等。8.2 可维护性描述系统可维护性设计与实现方案。系统可维护性包括系统监控与告警、系统配置、数据备份及清理。例如:考虑在线修改配置信息,而不中断业

19、务的设计机制。8.3 安全描述系统安全性设计与实现方案。系统安全性包括网络安全、系统安全、数据安全、交易安全等。例如:IP地址鉴权;各类数据加密机制;各类通讯加密机制;身份识别及认证等。8.4 容错性描述系统容错处理机制,以及各类错误的处理要求。例如:数据库双机热备容错机制;应用错误捕获及保护机制等。8.5 可移植性描述系统可移植性设计与实现方案。例如:应用软件对多种第三方硬件及软件的无依赖性设计等。8.6 可部署性描述系统可部署性设计与实现方案。例如:考虑应用及数据的加载策略,降低系统故障恢复时间等。8.7 描述未列在上述分类的产品非功能特性设计。9 总体约束本章给出设计人员与编码人员必须遵

20、循的设计要求与编码要求,包括各种代码的命名、配置文件、日志文件格式定义。可以通过引用的方式来写本章节。9.1 遵循标准描述本软件所遵循的标准、规范。9.2 文件约定规定系统的所有配置、日志等文件命名方式与格式。9.3 目录约定规定系统的目录结构,包括运行目录、源文件目录、配置目录、日志目录、数据目录等9.4 对后续设计的约束规定后续设计中必须遵循的约束条件。9.5 定义未列在上述分类中的总体设计约束。10 风险指明架构设计过程中遇到的或者考虑过的技术风险,说明减少潜在风险的策略,可通过列表的形式进行描述。例如:编号风险严重程度规避措施1对数据库表/视图做了修改,新增多个字段、表,升级工作量大。中规划升级方案;选择业务最少时段升级;11 附录定义需要列在架构设计文档中的附加性信息等。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 生活休闲 > 在线阅读


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号