软件架构————架构核对表

架构的典型组成部分

一、程序组织：

1.系统架构首先要以概括的形式对有关系统做一个综述。如果没有这种综述，要想将成千的局部图片拼成一幅完整的图画是相当伤脑筋的。

2.在架构中，应该发现对那些曾经考虑过的最终组织结构的替代方案的记叙，找到之所以选用最终的组织结构，而不用其他替代方案的理由。

3.架构应该定义程序的主要构造块。根据程序规模不同，各个构造块可能是单个类，也可能是有许多类组成的一个子系统。

4.应该明确定义各个构造块的责任。每个构造块应该负责某一个区域的事情，并且对其他构造块负责的区域知道得越少越好。通过使各个构造块对其他构造块了解达到最小，你能将设计的信息局限于各个构造块之内。

5.应该明确定义每个构造块的通信规则。对于每个构造块，架构应该描述他能直接使用那些构造块，能间接使用那些构造块，不能使用哪些构造块。

二、主要的类

架构应该详细定义所用的主要的类。它应该指出每个主要的类的责任，以及该类如何与其他类交互。它应该包含对类的继承体系、状态转换、对象持久化等的描述。架构无须详细说明系统中的每一个类，瞄准80/20原则。对那些构成系统80%的行为的20%类进行详细说明。

三、数据设计

1.架构应该描述所用的主要文件和数据表的设计。它应该描述曾经考虑过的其他方案，并说明做出选择的理由。

2.数据通常只应该由一个子系统或一个类直接访问。

3.架构应该详细定义所用数据库的最高层组织结构和内容。架构应该解释为什么单个数据库比多个数据库要好（反之亦然），解释为什么不用平坦文件而要用数据库，指出与其他访问同一数据的程序的可能交互方式，说明会创建哪些数据视图等等。

四、业务规则

如果架构依赖于特定的业务规则，那么它就应该详细描述这些规则，并描述这些规则对系统设计的影响。

五、用户界面设计

1.用户界面常常在需求阶段进行详细说明。如果没有，就应该在软件架构中进行详细说明。

2.架构应该模块化，以便在替换为新用户界面时不影响业务规则和程序的输出部分。

六、资源管理

架构应该描述一份管理稀缺资源的计划。稀缺资源包括：数据库连接、线程、句柄等。

七、安全性

架构应该描述实现设计层面和代码层面的安全性的方法。在定制编码规范的时候应该把安全性牢记在心，包括处理缓冲区的方法、处理非受信数据的规则、加密、错误消息的细致程度、保护内存中的秘密数据，以及其他事项。

八、性能

1.如果需要关注性能，就应该在需求中详细定义性能目标。

2.架构应该提供估计的数据，并解释为什么架构师相信能达到性能目标。如果某些部分存在达不到性能目标的风险，那么架构也应该指出来。如果为了满足性能目标，需要在某些部分使用特定的算法或数据类型，架构也应该说清楚。架构中也可以抱括各个类或各个对象的空间和时间预算。

九、可伸缩性

可伸缩性是指系统增长以满足未来需求的能力。架构应该描述系统如何应对用户数量、服务器数量、网络节点数量、数据库记录数、数据库记录的长度、交易量等的增长。

十、互用性

如果预计这个系统会与其他软件或硬件共享数据或资源，架构应该描述如何完成这一任务。

十一、国际化/本地化

对交互系统，国际化问题值得在架构中关注。大多数交互式系统包含几十上百条提示、状态显示、帮助信息、错误信息、等等。应该估算这些字符串所用的资源。如果这是一个在商业中使用的程序，架构应该表现出已经考虑过典型的字符串问题和字符集问题，包括所用的字符串类型，如果无须更改代码就能维护这些字符串，如何将这些字符串翻译为另一种语言而又尽量不影响代码和用户界面。

十二、输入输出

架构应该详细定义读取策略是先做、后作还是即时做。而且应该描述在那一层测I/O错误：在字段、记录、流，或者文件的层次。

十三、错误处理

错误处理已被证实为现代计算机科学中最棘手的问题之一。错误处理牵连到整个系统，因此最好在架构层次上对待他。

1.错误处理是进行纠正还是仅仅进行检测？如果是纠正，程序可以尝试从错误中恢复过来。

2.错误检测是主动的还是被动的？系统可以主动滴预测错误。

3.程序如何传播错误？程序一旦检测到错误，它可以立刻丢弃引发该错误的数据；也可以把这个错误当成一个错误，并进入错误处理状态；或者可以等到所有处理完成，再通知用户说在某个地方发现了错误。

4.错误消息的处理有什么约定？如果架构没有详细定义一个一致的处理策略，那用户界面看起来非常糟。

5.如何处理异常？架构应该规定代码何时能够抛出异常，在什么地方捕获异常，如何记录这些异常，以及如何在文档中描述异常，等等。

6.在程序中，在什么层次上处理错误？

7.每个类在验证其输入数据的有效性方面需要负何种责任？

8.是希望运行环境中内建的错误处理机制，还是想建立自己的一套机制？

十四、容错性

架构还应该详细定义所期望的容错种类。容错是增强系统可靠性的一组技术，包括检测错误；如果可能的话从错误中恢复；如果不能从错误中恢复，则包容其不利影响。

十五、架构的可行性

设计师多半会关注系统的各种能力，例如是否达到性能目标，能够在有限的资源下运转，实现环境是否有足够的支持。架构应该论证系统的技术可能性。如果在任何一个方面不可行都会导致项目无法实施，那么架构应该说明“这些问题是如何经过研究的”——通过验证概念的原型、研究、或其他手段。必须在全面开展构建之前解决掉这些风险。

十六、过度工程

健壮性是指“系统在检测到错误后继续运行”的能力。通常架构详细描述的系统会比需求描述的系统更健壮。理由之一是，如果组成系统的各个部分都只在最低限度上满足健壮性要求，那么系统整体上是达不到所要求的健壮程度的。在软件中，链条的强度不是取决于最薄弱的一环，而是等于所有薄弱环节的乘积。架构应该清楚地指出程序员应该“为了谨慎起见宁可进行过度工程”，还是应该做出最简单的能工作的东西。

详细定义一种过度工程的方法尤其重要，因为许多程序员会处于专业自豪感，对自己编写的类做过度工程。通过在架构中明确地设立期望目标，就能避免出现“某些类异常健壮，而其他类勉强够健壮”的现象。

十七、关于“买”还是“造”的决策

采购IP进行整合还是自己进行设计，都应该给出详细的分析。

十八、关于复用的决策

关于开发计划提倡使用已存在的软件、测试用例、数据歌会或其他原料。架构应该说明：如何对复用的软件进行加工，使之符合其他架构目标。

十九、变更策略

要面对开发过程中产品的变化，软件架构师所遇到的挑战是，让架构灵活，能够适应核能出现的变化。

架构应当清楚地描述处理变更的策略。架构应该列出已经考虑过的有可能会有所增强的功能，并说明“最有肯能增强的功能同样也是最容易实现的”。如果变更很可能出现输入输出格式、用户交互的风格、需求的处理等方面，那么架构就应该说明：这些变更已经被预料到了，并且任何单一的变更都只会影响少数几个类。

二十、架构的总体质量

1、架构的目标应该清楚地表述。

2、架构应该描述所有主要决策的动机。

3、优秀的软件架构很大程度上是与机器和编程无关的。

4、架构应该踏在对系统”欠描述“和”过度描述“之间的那条分界线上。

5、架构应该明确地指出有风险的区域。他应该解释为什么这些区域是有风险的，并说明已经采取了哪些步骤以使风险最小化。

6、架构应该包含多个视角。

7、不应该担忧架构的任何部分。它不应该任何对你而言很难理解的东西。