怎样算是一分优秀的架构规格书
架构的先决条件
架构的质量决定了系统的概念完整性。后者继而决定了软件的最终质量。
架构的典型组成部分
程序组织
- 系统架构首先要以概要的形式对有关系统做一个综述。
- 架构定义主要的构造块。根据程序规模的不同，各个构造块可以由单个类或者多个类组成的子系统。每条列在需求中的功能特性至少有一个构造块覆盖到。
- 明确定义各个构造块的责任。构造块之间的关系和接口。各个构造块之间应该知道的越少越好。明确层次关系，对于每个构造块，可以调用哪些构造块，可以间接调用哪些构造块，不可以调用哪些构造块。
主要的类
定义20%完成80%的需求的类。
数据设计
明确使用什么样的数据形式，为什么不用其它的形式。使用文件还是数据库，为什么？
业务规则
如果架构须要依赖于特定的业务，那么要主细描述这么规则。
用户界面设计
架构中应当说明使用哪种UI，什么格式，是桌面的，WEB的，命令行接口还是其它的形式。
变更策略
明确的需求发生变更时，应当执行什么样的策略，怎样管理。
资源管理
一些有限的资源像线程，句柄，内存，硬盘。应当如何合理的使用，统一使用的方式。在嵌入式中，资源短缺的情况下，更应该注重资源的管理。
安全性
架构应该描述实现设计层面和代码层面的安全性的方法。
性能
明确性能目标，性能要达到什么样的程度。
可伸缩性
可伸缩性是指系统增长满足未来需求的能力
输入输出
架构应该详细定义读取策略，而且应该描述在哪一层检测IO错误。
错误处理
架构应该清楚的说明一种“一致处理错误错误”的策略 * 错误处理是进行纠正还是仅仅检测 * 错误检测是主动还是被动 * 程序的错误如何传播 * 错误消息的处理有什么约定 * 如何处理异常 * 程序在什么层次上处理错误 * 每个类的错误处理上负什么样的责任。是每个类负责处理错误，还是由一组类来处理整个系统的错误 * 使用运行环境中的内部支持的错误处理机制还是自己编写错误处理机制
容错性
架构应该定义所期望的容错种类。
架构的可行性
应该认证系统的技术可行性
架构的总体质量
- 优秀的架构规格书的特点在于讨论了系统中的类，每个类背后的隐藏信息，讨论了“采纳或排斥所有替代方案的理由”
- 架构的目标应该清楚的表述
- 架构在很大程度止是与机器和编程语言无关的
- 架构应该描述所有决策的主要动机
- 架构应该明确的指出有风险的区域
- 架构应该在“欠描述”和“过度描述”之间的那条分界线上
- 架构不应该包含很难理解的东西
摘自代码大全
