后端技术面试38讲
李智慧
同程艺龙交通首席架构师,前Intel&阿里架构师,《大型网站技术架构》作者
立即订阅
3682 人已学习
课程目录
已更新 16 讲 / 共 38 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 掌握软件开发技术的第一性原理
免费
软件的基础原理 (8讲)
01丨程序运行原理:程序是如何运行又是如何崩溃的?
02丨数据结构原理:Hash表的时间复杂度为什么是O(1)?
03丨Java虚拟机原理:JVM为什么被称为机器(machine)?
04丨网络编程原理:一个字符的互联网之旅
05丨文件系统原理:如何用1分钟遍历一个100TB的文件?
06丨数据库原理:为什么PrepareStatement性能更好更安全?
07丨编程语言原理:面向对象编程是编程的终极形态吗?
答疑丨Java Web程序的运行时环境到底是怎样的?
软件的设计原理 (6讲)
08丨软件设计的方法论:软件为什么要建模?
09丨软件设计实践:如何使用UML完成一个设计文档?
10 | 软件设计的目的:糟糕的程序员比优秀的程序员差在哪里?
11丨软件设计的开闭原则:如何不修改代码却能实现需求变更?
12 | 软件设计的依赖倒置原则:如何不依赖代码却可以复用它的功能?
13丨软件设计的里氏替换原则:正方形可以继承长方形吗?
不定期加餐 (1讲)
加餐 | 软件设计文档示例模板
后端技术面试38讲
登录|注册

加餐 | 软件设计文档示例模板

李智慧 2019-12-11
上一篇文章中,我讲了每种 UML 模型图的画法,以及这些画法分别适用于什么样的设计阶段,我们也可以将不同阶段输出的模型图放在一个文档中,对每张模型图配以适当的文字说明,构成一篇设计文档。
对于规模不太大的软件系统,我们可以将概要设计文档和详细设计文档合并成一个设计文档。这一篇文章中,我会展现一个设计文档示例模板,你可以参考这个模板编写你的设计文档。
文档开头是设计概述,简单描述业务场景要解决的核心问题领域是什么。至于业务场景,应该在专门的需求文档中描述,但是在设计文档中,必须要再简单描述一下,以保证设计文档的完整性,这样,即使脱离需求文档,阅读者也能理解主要的设计。
此外,在设计概述中,还需要描述设计的非功能约束,比如关于性能、可用性、维护性、安全性,甚至开发和部署成本方面的设计目标。
然后就是具体的设计了,第一张设计图应该是部署图,通过部署图描述系统整个物理模型蓝图,包括未来系统长什么样。
如果系统中包含几个子系统,那么还需要描述子系统间的关系,可以通过子系统序列图,子系统活动图进行描述。
子系统内部的最顶层设计就是组件图,描述子系统由哪些组件组成,不同场景中,组件之间的调用序列图是什么样的。
每个组件内部,需要用类图进行建模描述,对于不同场景,用时序图描述类之间的动态调用关系,对于有复杂状态的类,用状态图描述其状态转换。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《后端技术面试38讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • 许童童
    这个加餐不错,直接上干货,这个设计文档只要稍做修改,就可以在公司内部直接使用了,老师牛啊。
    2019-12-11
    1
    6
  • 天天向上
    老师 您好!类似文档丰富的Java开源项目,您能否推荐一个?
    2019-12-11
    3
  • 丁丁历险记
    给markdown 打个广告,我现在blog 全是md 格式了。
    2019-12-18
  • 几点了
    终于理解公司的设计文档的章节了,学习到了
    2019-12-17
  • 靠人品去赢
    这个mark一下,设计文档之前一个公司都是A复制B换个图,换个描述,也不知道对不对。这个最起码是模版,到时候用的时候可以拿出来。
    2019-12-16
  • qpm
    干货!谢谢老师
    2019-12-16
  • Jonathan Chan
    优秀,学习了
    2019-12-16
  • Geek_d048e4
    干货。。,
    2019-12-13
  • 探索无止境
    喜欢这种有落地的方案,老师辛苦了
    2019-12-12
  • hanlimo
    像我大学时的软件工程作业,从实践中回顾理论,发现理论真的是很重要。
    2019-12-12
  • 北天魔狼
    🙏🙏🙏直接上模板。以前一直都是确定一下功能逻辑就开始,规范化的东西一直没有,谢谢老师
    2019-12-11
  • 老男孩
    一个很好的设计文档模板。看了这个我才知道,之前的一些文档有些地方就是胡写了。很多公司,而且是有一定规模的公司,设计文档也是后补的,为了应付领导或者甲方。产品和开发也不看,就盯着产品原型图死磕。关于一个核心问题域,有时候连名词都没统一。project,你说的是项目管理,他说的是工程管理,或者一会儿工程一会儿项目。这样的文档写了也没人看,然后就真的成了软件系统的“遗产”了。
    2019-12-11
  • 尹宗昌
    加餐真是优秀!!!
    2019-12-11
  • 你的美
    老师辛苦了,感谢!
    2019-12-11
收起评论
14
返回
顶部