《软件架构设计文档模板.docx》由会员分享，可在线阅读，更多相关《软件架构设计文档模板.docx（23页珍藏版）》请在三一文库上搜索。
1、Version RevisionSoftware Architecture DocumentDateVersionDescriptionAuthor1. 文档简介41.1 文档目的41.2 文档范围41.3 定义、缩写词和缩略语41.4 参考资料42. 架构描述方式42.1 架构视图阅读指南42.2 图表与模型阅读指南53. 架构设计目标53.1 关键功能53.2 关键质量属性53.3 业务需求和约束因素54. 架构设计原那么64.1 架构设计原那么64.2 备选架构设计方案及被否原因64.3 架构设计对后续工作的限制详设,部署等65. 逻辑架构视图65.1 责任划分与责任确定75.2 接口设
2、计与协作机制85.3 重要设计包106. 开发架构视图116.1 Project 划分116.2 Project 1116.2.1 Project目录结构指导126.2.2 程序单元组织126.2.3 框架与应用之间的关系可选126.3 Project 2136.4 Project n 137. 运行架构视图137.1 限制流组织137.2 限制流的创立、销毁、通信137.3 加锁设计148. 物理架构视图148.1 物理拓扑148.2 软件到硬件的映射158.3 优化部署169. 数据架构视图169.1 持久化机制的选择169.2 持久化存储方案179.3 数据同步与复制策略1710. 关键
3、质量属性的设计原理171. 文档简介帮助读者对本文档建立根本印象,并为阅读后续内容扫清障碍.1.1 文档目的文档目的,非工程目的.否那么造成同一工程多个文档之间的内容重复,不利于文档维护.本 小节应指明文档针对的读者对象,最好列出各种读者角色,并说明每种读者角色应该重点阅读 的章节.1.2 文档范围文档的Scope ,非工程的Scope.否那么造成同一工程多个文档之间的内容重复,不利于文档 维护.1.3 定义、缩写词和缩略语集中列举文档中的定义、缩写词和缩略语.1.4 参考资料本工程经审核的方案书、合同、上级批文；本工程的其他已发表文件；本文档引用的文件资 料,如软件开发标准.具体而言,应包括
4、参考资料的题目必须、编号、版本号必须、 发表日期、发布方,必要时还可以说明如何使用这些资料.2. 架构描述方式为了让读者更好地理解?架构文档?,在本节应当说明文档涉及的架构视图,并指明为了描2.1述设计决策用到了哪些图表和模型.架构视图阅读指南以多视图的方式来组织?架构文档?是大势所趋.推荐的是经过优化的5视图方法,如下列图所示.2.2图表与模型阅读指南对后续文档内容中所用到的建模语言例如UML、表格例如目标-场景-决策表等进行说明.3. 架构设计目标功能、质量、约束,一个都不能少.3.1 关键功能对架构设计至关重要的功能,包括如下4类：核心功能、必做功能、高风险功能、独特功能.所谓独特功能,
5、指这个功能覆盖了上述3类功能没有涉及到的责任.3.2 关键质量属性人之所以痛苦,很多时候是由于追求错误的东西.下列图是确定关键质量的5大原那么的整体思路图.3.3 业务需求和约束因素创造性地提出约束需求的 4大类型,这是一种极为实用的分类方式.特别是业务需求对架构设计而言是一种约束的观点,解决了很多架构师的现实困惑.下列图标明了4类约束在“需求层次-需求方面矩阵中的位置,可以帮助我们理解产生约束需求的根源.4.广义功能用户需求行为需求质量r约束技末畦驯里I LI- 1 i I R if 三一业务环境后行期质量开发期质量分此实前号.争剧七苫争在/i An._bb、*f ,K彳 开发司E虐台程侪构
6、建环境琲护胄dnV JI架构设计原那么4.14.24.3架构设计原那么着重描述重大的权衡取舍考虑.备选架构设计方案及被否原因在概念架构一级,对备选架构设计方案进行描述,并阐述它们未被采用的原因.这有利于团 队了解当前架构设计方案的来龙去脉,提升团队对当前架构设计方案的认可度.架构设计对后续工作的限制详设,部署等架构设计不仅应该包含“指导,也应该包含重要的“限制.例如,一份只是说明“性能 和可扩展性都重要的?架构文档?,实际上无视了 “可扩展性和性能之间存在的矛盾关 系.此时,最有效的方法就是在?架构文档?中明确说明“任何提升可扩展性的架构设计和 详细设计,都应通过架构团队的评审才能引入,以保证
7、性能目标不受重大影响.投标时经常讲“架构设计原那么,但到了?架构文档?,这些着眼大局的考虑却“丢了. 推荐的本文档模板,认为应当把它们“找回来.5.逻辑架构视图关注点：此架构设计视图的关注点是责任划分.注意：逻辑架构视图无疑是最重要的,但同时也应防止“架构=模块+接口等以偏概全的熟悉.参考：任何复杂系统的架构设计都不是一蹴而就的,所以架构师需要理性思维过程的指导.针对逻辑架构设计这个关键环节,?一线架构师实践指南?一书给出了2条建议：一是“以质疑驱动的螺旋思维,二是相对别离地考虑“结构方面的切分和“行为方面的定义.下列图所示即为推荐的逻辑架构设计理性思维过程.5.1责任划分与责任确定内容：将系
8、统切分成更小的单元,并明确这些单元的责任.具体而言,责任单元可以是层、 子系统、模块、关键类等.意义：一句话,责任划分不合理,功能和质量都会受到影响.也就是说,功能需求和质量需 求无一不和责任划分相关：一方面,每个功能都是由一条责任协作链完成的；另一方面,责任 划分方式也影响着质量,于是需要责任模型针对特定质量属性要求做出相应调整和优化.很多 人认为架构设计就是责任划分的艺术,虽略显片面,但足以说明责任划分的重要性.参考：基于对业界大量案例的研究,梳理出了 “模块划分的3种必用手段,如下列图所示,更多内容可参考?一线架构师实践指南?一书.5.2分层的如化责任分制原那么接口设计与协作机制内容：本
9、节描述接口的定义,以及协作的方式和标准.意义：恰恰是由于有了各模块之间“未来合作的契约,分头开发各模块才有了根本保证.参考：推荐利用“包-接口图,来识别接口.下列图为一个“包-接口图的例如.共享界面Windows外壳如屣1：M而 选项设置.进庾窗口 口区缩和解乐缩典周?1：热汴和好克犷悔共享的女用界面支持.压瑞支相“整也解曲端*命令描述进度展现回调接口能冲接口本隔拧制层用浙的地制解压的限制用右小缩区内容的抻名力法接口智能撒冲帆制内容班冲达软定仙喀k时相应接口边仃问屿七显出额定Tu 口容量的 内容进叮科加保“接口原文件读层用箫包配层压端实现层1 Li子列的JE不,就不说加上生琏不立尤值J0L的压
10、缩结堀接口亚缗包格式分费援冲以字苻沛方式读文件件成文件镶冲参考：推荐使用序列图,建议少用、甚至杜绝使用协作图.下列图为一个序列图的例如.a1II1J1n 1Road /I1Zip( fTTH. 上?川及片.而111111IIWrite ： ? L灶)J11111ir cariradi ： isuniarwt ?-1PfOM 喇) lt_l111- SWe瞰 f 111IIIOutputf 知编川 SSXlX )|J111. 1L1Caiibad 上也; .V1一“鼠进座r111111111iII1ElpOMPII rile )Calite cm 4 )5.3重要设计包内容：对重要子系统的设计进
11、行“灰盒级描述.意义：“每个子系统在架构设计中都应保持黑盒子的观点,过于理想化了.对于业务层、 通用协作机制而言,经常需要在架构设计期间就引入“灰盒级描述.参考：类图和灰盒包图,在本节中较多出现.下列图为一灰盒包图例如.艇现层clt- intvrlautJGaiitiChartG5nttChartlmpI来自第三方的H.特图笠制包6.6.16.2开发架构视图关注点：此架构设计视图的关注点是程序单元组织.注意：此架构设计视图是必须的、不应“剪裁掉的.但实际情况却是,很多架构师不关注 开发架构视图,导致很多程序开发人员抱怨“架构师就知道高来高去,架构对编程工作没什么 指导性.Project 划分内
12、容：本节说明整个系统将划分成哪几个Project来开发,其中,Project指开发环境所感知到的“工程.意义：根本好处是,有利于开发的组织；而对一些大型的集成系统而言,由于同时涉及了Web应用、桌面应用、嵌入式应用等软件形态,所以此时Project划分其实是不得不做的；最后,我们推荐核心代码应主动地切分到单独的Project以进行独立的软件配置治理 SCM ,以降低核心代码外泄的风险. 参考：Project划分必然是属于“架构设计的工作,严格来讲仅靠“需求分析划分的业务 域Business Area 直接映射到Project经常意味着工作内容的遗漏.其实,业界不少有见地 的专家已经熟悉到 WB
13、S 工作分解结构做得太早太草率危害很大,就与“ Project划分不到 位不无关系.Project 1内容：对Project划分后的每个 Project进行目录结构、程序单元组织、框架与应用关系的说 明.6.2.1Project目录结构指导内容：关于该Project 一级目录、二级目录等根本目录结构的约定.意义：为团队并行开发提供必要根底,让不同程序小组看到自己应该负责的程序目录.参考：不要把所有程序目录的约定都定义得太细,否那么这份?架构文档?就要天天更新了.6.2.2程序单元组织内容：源码、程序库、框架、目标码等类型程序单元之间的编译依赖关系.意义：或许有人认为这没什么技术含量,但架构设计
14、本来就不是只关心技术含量最高问题的.君不见,很多软件工程师跳槽到新的企业之后,竟然连一个能正常编译源码的开发环境都建不起来其实,他们“不知道Project所依赖的Library有哪些是其中重要原因这本应在?架构文档?中给出明确描述的.6.2.3框架与应用之间的关系(可选)内容：框架(Framework ).意义：既然不适用 Framework的开发越来越少了,既然程序员犯的很多错误都和对Framework理解不到位有关,架构师就有责任明确说明Framework和待开发系统之间的关系.参考：下列图描述了 JGraph框架和待开发应用的关系.参考：下列图描述了Struts框架和待开发应用的关系.6
15、.3 Project 2 内容：对Project划分后的每个 Project进行目录结构、程序单元组织、框架与应用关系的说 明.6.4 Project n 内容：对Project划分后的每个 Project进行目录结构、程序单元组织、框架与应用关系的说 明.7. 运行架构视图关注点：此架构设计视图的关注点是限制流组织.注意：进程和线程是广为人知的限制流实现技术,但在架构设计思维当中,对于系统软件和嵌入式软件极为重要的中断效劳程序也是限制流,这样利于架构师统一利用不同限制流手段设计并行和并发.1. 1 限制流组织内容：限制流有哪些,每条限制流各是何种形式例如进程、线程、中断效劳程序,哪些 软件单
16、元是限制流的起点,整条限制流中分别调用了哪些软件单元.意义：这是对系统运行时结构的刻画,主要反映系统的动态结构.2. 2限制流的创立、销毁、通信内容：描述进程、线程和中断效劳程序的创立和销毁,以及多条限制流之间的通信关系的定义.意义：一旦引入了多条限制流,附加工作就产生了一一此时限制流的创立和销毁、以及限制流之间的通信关系往往是必须考虑的.7.3 加锁设计内容：系统中有多条限制流在同时运行的情况下,一个经典问题是多于一条限制流可能会同时修改某些数据结构,而造成数据的不一致.为此,架构师需要关注加锁设计,合理引入临界区或同步机制.意义：加锁设计事关系统的正确性.值得注意的是,忽略加锁设计造成的问
17、题往往以“不易重现的Bug的形式出现,困惑的程序员会对测试人员说,“你看你报的Bug在我机器上根本就不存在呀.参考：对通用组件、通用模块的设计而言,加锁设计应予以专门关注,思维要点是研究未来通用模块的各种可能使用场景.8. 物理架构视图关注点：此架构设计视图的关注点是物理节点 Node分布,以及软件到硬件的具体映射关 系.注意：物理节点即可以是 PC机或效劳器,也可以是单片机、单板机或专用机,从而物理架构 视图既适用于描述企业信息系统,也适合于描述嵌入式软件系统.8.1 物理拓扑内容：一为硬件选型,二为硬件之间的拓扑连接关系.意义：对于分布式系统的设计,此节极为重要、而且是必须的.参考：下列图
18、是某企业级系统的物理拓扑图.数据层CTierJ参考：下列图是某嵌入式系统的物理拓扑图.8.2软件到硬件的映射内容：明确每个物理节点上有哪些一到多个软件的目标单元,并说明具体的“映射方式是安装、是部署、还是烧写、抑或是下载. 意义：如果把此节漏了,就无法说明本文档的主题一一软件系统一一和上述硬件、硬件拓扑 的关系.参考：下列图所示为设备调试系统中,软件到硬件的映射关系.8.3优化部署O 0/0喏架构里维架枸肺最终目标投资与维护成 本6理特定柱能目标 的满足思维要点计尊和通信开销小此外b真报通信时 对?硬盘心PW 融备中突设出勺容节点选择/分布柘扑软件单元和数据单 元的责任与分布阊等垓计经济性按木
19、力行性场维护性性能通信开销网络争用持续可用性可伸缩性计算开销内亨争用硬盘争用CFLJ争用蜕据争用软件单元数据单元物理千点目标层j田 I P lX I:昌,结1果内容：为达降低本钱、提升性能和可靠性等等目标,应特别关注的部署考虑. 意义：物理架构设计的优劣,造成的本钱差异和质量差异,可能是天壤之别.所以必须重 视. 参考：下列图展示的,是 ADMEMS方法重点推荐的“物理架构设计思维要点,更多内容可参 考?一线架构师实践指南?一书. 9. 数据架构视图关注点：此架构设计视图的关注点是持久化.具体而言,场景化可以借助扁平文件、关系数据库、实时数据库、Flash等方式中的一种或多种完成.注意：本视图
20、单独归档时,请在此节注明其文档名称等信息.9.1Flash o 持久化机制的选择内容：如下持久化机制的一种或多种：扁平文件、关系数据库、实时数据库、意义：不要假设在你的系统中,持久化只需一种机制；随着如今的系统变得越来越复杂,我们经常需要综合利用不同持久化机制.9.1 持久化存储方案内容：持久化数据的格式定义.意义：统一定义表、文件格式、Flash数据结构等内容.9.2 数据同步与复制策略内容：由于数据分布所引起的,包含数据分布、同步、复制等内容的重要设计决策.意义：在数据分布的情况下,此节为必须.参考：在实际中,数据分布的策略绝大多数情况下不会超越下列图所示的6种手段,更多内容可参考?一线架
21、构师实践指南?一书.非复制方式复制方式Schema相同Schema不同10. 关键质量属性的设计原理内容：因软件系统的不同,性能、平安性、可伸缩性、互操作性、可扩展性、可测试性、可 重用性、可维护性等质量属性,都可以是本系统的关键质量属性.本文档的前面局部已经涉及 了关键质量属性的设计决策,而本节更集中、更全面地描述这些架构设计决策,并且阐述“为 什么这么设计.意义：只描述架构设计决策本身,不利于读者理解“为什么这么设计.而且,描述设计原 理有利于在整个软件企业层面促进团队的架构设计水平.参考：关于描述“为什么这么设计,目标-场景-决策表是此方面的卓越工具.下列图为例如,更多内容可参考?一线架构师实践指南?一书.目标场景决策性能客户谛,重得请求页面,W时效劳器请求 数多贪裁压力大代理效劳器奔户端,重复请我贝回,仄间生成逻辑 重复执行出ml静态化客户请求,来自不同二尔,页面照网络传 递慢内容分发网络客户端,大量请求图片资源,照b效劳器 压力大客户端,大量请求图片资源,W&效劳器 无法专门优优匿片效劳器程序1大量申请数强；变执0压力大程序,申请不同效据,DM缓存低效数据库拆分环境；部署安个DBMS实例?程序,更新数据,数据复制开销大数据库读写别离盛年不重来,一日难再晨.及时宜自勉,岁月不待人.