Checkpoints: Software Architecture Document（译）

 

Checkpoints: Software Architecture Document

 

General

大体上，这个系统是基于良好架构的，因为：

                     架构看起来比较稳定。

稳定性需求是由构建阶段的本性控制的：在构建时，典型地，项目扩大范围，增加并行工作的开发者，以及在他们生产产品的时候彼此自由通信。在构建时，如果架构不稳定的话，独立和并行要求的程度不能完全达到。

架构稳定的重要性不能被过分强调。不要被误导而认为“完美的结束就足够好了”——不稳定就是不稳定，令架构正确并且延迟开始构建是比继续下去更好的做法。相同的问题包括当开发者正在依赖于架构开发时，试图去纠正架构，这将很容易抹杀可加快进度的明显的好处。在构建时对架构的改变有着深远的影响：代价趋于昂贵、混乱和令人沮丧。

评估架构的稳定性的真正的难点是“你不知道什么是你不知道的”；稳定性的衡量是相对于预期的改变的。结果，稳定性本质上是一个主观的衡量标准。然而，我们基于这个主观性好过基于猜测。架构本身是出于考虑到“架构上重大的”场景——系统必须支持那些代表着最多技术挑战行为的用例的子集，而开发的。评估架构的稳定性包括确保此架构有着广的覆盖率，确保在架构进行中没有令人感到“惊讶”的东西。

以往架构上的经验也会是一个好的指导：如果架构的改变速度是缓慢的，而且在新场景下仍然是缓慢的，那就有足够的理由相信此架构是稳定的。相反，如果每个新的场景都导致架构改变，则它仍然处于发掌中且基线仍然不能批准。

                     系统的复杂性和其提供的功能相匹配。

                     对于赋予了技能和经验的用户、操作者和开发者，概念上的复杂性是合适。

                     系统有一个单一的，一致的和连贯的架构。

                     组件的数量和类型是合理的。

                     系统有一个系统级的安全工具。所有的安全组件系统工作去保护系统的安全。

                     系统达到其可用性目标。

                     在故障事件中，架构能使系统在限定的时间内被恢复。

                     系统基于的产品和技术和预期的生命周期相符：

                                   一个临时的只有很短的生命周期的系统可以使用旧的技术去构建，因为不久它就会被丢弃。

                                   一个拥有较长的平均寿命的系统（大多数系统）应该使用最近的技术和方法，因为它会被维护和扩展以支持未来的需求。

                     架构提供清晰界定的接口，以使得并行开发的小组能很好地分工。

                     模型元素的设计者能从架构获得足够的认识去成功地设计一个模型元素。

                     通过划分包去减少复杂性，让人更加易于理解。

                     包应当是高内聚的，包之间则是低耦合的。

                     通用应用软件领域中的类似的解决方案是被考虑过的。

                     对于具有相关领域的一般性认识的人能够很容易地理解被提议的解决方案。

                     所有组员共享同一个架构视图，此视图和架构师提交的架构图相同。

                     软件架构文档是最新的。

                     遵循了架构设计规范。

                     所有的技术风险要么被降低要么在紧急情况计划中做了说明。新的风险被记载到文档中且分析了其潜在的影响。

                     关键的性能需求（已确定的预算）是令人满意的。

                     测试用例、测试工具和测试配置都已经确定。

                     架构没有被“过度设计” 。

                                   装置足够简单且易于使用。

                                   装置的数量是适度的且，且与系统范围和问题域的要求相一致。

                                   为当前迭代定义的所有用例实现能被架构执行，作为由图表描述的范例：对象间的交互、任务和进程间的交互、物理结点间的交互。

Models

Architectural Analysis Considerations

Overall

                     子系统和包的划分与层在逻辑上相一致。

                     所有的分析装置已经被定义和描述。

Subsystems

                     子系统的服务（接口）在上层层中被定义。

                     子系统和包之间的依赖和所包含类之间的依赖关系相一致。

                     子系统中的类支持为子系统定义的服务。

Classes

                     关键的实体类和它们之间的关系被定义。

                     每个类的命名和描述清晰地反映其扮演的角色。

                     每个类的描述精确地说明了其职责。

                     实体类被映射到合适的分析装置。

                     聚合和关联的角色名正确地描述了类之间的关系。

                     正确地使用关系。

                     关键的实体类以及它们之间的关系和业务模型（如果存在的话）、域模型、需求和术语表实体相一致。

General Model Considerations

                     模型具有合适的粒度。

                     对于在建立阶段的业务模型、需求模型或者设计模型，不过分强调于实现问题。

                     对于构建阶段的设计模型，有跨过模型元素的良好平衡，使用相对简单的元素的组合去构建一个复杂的设计。

                     模型以适用于问题域的完整范围的模型概念说明了熟知和能力；建模技术被正确运用于手边的问题。

                     概念被以尽可能简单的方法模型化。

                     模型是易于发展的，能很容易地适应预期的改变。

                     同时，在损害简单性和理解性的情况下，模型不可被过度地构造以适应不太可能发生的变化。

                     模型背后的关键的假设是文档化的且对模型的检查者可见。如果假设对于给定的迭代是合适的，那么模型应当能够在那些假定下被进化，但是对于其它假定则是没有必要的。在反复迭代过程中，分析出所有的需求，定义一个能处理每个未来的需求的模型是不可能的。

Diagrams

                     图表的目的是清晰地陈述和易于理解。

                     图层是清晰的且能清楚地传达主旨。

                     图表只表达能完成目标所需要的东西。

                     封装被用来有效地隐藏细节和提高透明性。

                     抽象被用来有效地隐藏细节和提高透明性。

                     模型元素的布局有效地转达关系，相似或者紧密耦合的元素被组织在一起。

                     模型元素之间的管理易于理解。

                     模型元素的标签能帮助理解。

Documentation

                     每个模型元素有一个清晰和单独的目标。

                     没有冗余的模型元素，每个都扮演一个系统中基本的角色。

Error recovery

                     对于每个错误或者异常，有一个策略去定义了系统如何恢复到正常状态。

                     对于每个可能的来自用户的或者错误的外部系统的输入类型，有一个策略定义了系统如何恢复到正常状态。

                     有一个一致的异常情况处理策略。

                     有一个一致的处理数据库中数据损坏 的策略。

                     有一个一致的处理数据库不能使用的策略，包括是否数据仍然能进入系统和稍后进行存储。

                     如果需要在系统间交换数据，有一个策略去处理如何同步这些数据的视图。

                     在利用冗余处理器或者结点去提供容错或者高可用性的系统中，有一个策略去确保没有两个处理器或节点能认为他们是首要的，或者没有处理其或节点是首要的。

                     已确定分布式系统的故障模型且为处理故障定义了策略。

Transition and Installation

                     不会造成数据丢失和丧失工作能力的，对已有系统的升级过程，是有详细说明的且经过测试的。

                     为转换由前一个版本的系统使用的数据的过程，是有详细说明的且经过测试的。

                     了解升级和安装产品所需的时间和资源的数量，并且写入文档。

                     系统的功能在可以每次被一个用例激活。

Administration

                     当系统运行时，磁盘空间可以被重组或者恢复。

                     已定义和文档化系统配置的职责和步骤。

                     访问操作系统或者管理功能是受限制的。

                     满足许可证需求。

                     在系统运行时可以运行诊断程序。

                     系统自己监控操作性能（比如容量上限，临界性能上限，资源耗尽）。

                     定义了在达到上限时执行的动作。

                     定义了警报处理策略。

                     定义了警报处理装置，并且制作出原型，做过测试。

                     警报处理装置可防止错误或冗余的警报。

                     定义了网络（局域网，广域网）监控策略和步骤。

                     网络上的故障可以被隔离。

                     有事件跟踪工具可以用来帮助处理故障。

                     工具的管理费用是能被接收的。

                     管理人员可以懂得知识去有效地使用工具。

                     对于恶意者，他不能进入系统、破坏重要数据和使用资源。

Performance

                     性能上的需求是合理的并且反映出真实的问题域中的约束；其规格说明不是武断的。

                     存在（需要使用工作量分析模型来模型化）对系统性能的评估，并且性能需求不是主要风险。

                     使用系统架构原型验证系统性能评估，尤其对于有严格性能要求的需求。

Memory Utilization

                     定义了应用程序的预估内存使用量。

                     有措施去检测和防止内存泄漏。

                     有一贯的应用策略定义了虚拟内存系统如何被使用、监测和调整。

Cost and Schedule

                     迄今开发的实际的代码行数和当前里程碑预估的代码行数相一致。

                     预定的时程被检查过，并且保持正确。

                     使用最近的实际项目经验和工作能力来重新计算花费和时程的估计。

Portability

                     满足可移植性需求。

                     编码规范提供了在创建可移植的代码上的详细指导。

                     设计规范提供了在设计可移植应用上的详细指导。

                     做了“测试点”去验证可移植性。

Reliability

                     满足品质（MTBF，明显的错误数量）标准。

                     架构有从灾难时间或者系统故障中恢复的能力。

Security

                     满足系统安全需求。

Organizational Issues

                     小组是良构（well-structured）的吗？小组中职责明确吗？

                     有行政上的、组织上的或者管理上的问题限制了小组的效力吗？

                     有个人冲突吗？

The Logical View

软件架构文档的逻辑视图：

                     精确和完整地说明了架构上重要的设计元素的总体概括。

                     呈现了完整的用于设计的架构装置，连同其各个部分的基本原理。

                     呈现了分层的设计，连同分层的基本原理。

                     说明了设计中使用的任何基础框架或者模式，连同选择它们的基本原理。

                     架构上重要的模型元素的数量和系统的大小和范围是成合适比例的，并且仍然表现出的运转于系统的同等大小的主要概念是易于理解的。

The Process View

Topics

Resource Utilization

                     明确潜在的竞态条件（对重要资源的争用），并且定义了避免和解决它策略。

                     定义了处理“I/O队列”或者“缓冲区满”情况的策略。

                     系统能自我监测（比如容量上限，临界性能上限，资源耗尽），有能力在检测到问题后采取正确的动作。

Performance

                     定义了每条消息的响应时间。

                     有一个系统诊断模式，它允许测量消息的响应时间。

                     为重要的操作定义了正常和最大性能要求。

                     有一系列的性能测试以测量是否满足性能需求。

                     性能测试覆盖到系统的“非正常”行为（启动和停止，用例的分支和异常事件流，系统故障模式）。

                     定义了架构中的潜在成为性能瓶颈的缺点。尤其强调：

使用了一些有限的共享资源，比如旗语、文件句柄、锁、共享内存等等。

进程间通信。进程间通信比进程内通信代价昂贵得多。

处理器间通信。处理器间通信比进程内通信代价昂贵得多。

物理和虚拟内存使用；在系统用完物理内存并且开始使用虚拟内存的点是性能通常急速下降的点。

Fault Tolerance

                     在有首要和备份进程的地方，可能有一个以上（或者一个也没有）的进程认为自己是首要进程，要考虑过这样的潜在的问题，并且有设计说明了如何解决这个冲突。

                     当一个进程发生故障而偏离一致的状态这样的事件发生时， 有外部进程将系统恢复到一个稳定的状态。

                     系统容错，比如当错误或者异常发生时，系统能回复到稳定状态。

                     当系统运行时，可以执行诊断测试。

                     如果需要，系统可以在运行时升级（硬件，软件）。

                     有一个一贯的策略来处理系统中的警报，并且此策略被贯彻下去。警报策略处理：警报报表装置的灵敏性；防止错误和冗余的警报；对于那些使用警报报表装置的人的培训和用户界面需求。

                     评估了警报报表装置对性能的影响，以及其该当的可接收的性能极限都在性能需求中确定下来。

                     检查了和满足了工作量/性能需求。在性能需求是不切实际的情况下，它们应该被重新商定。

                     内存预算，就其存在而言，已经被确定并且验证表明软件满足这些需求。有检测和防止内存泄漏的措施。

                     有使用虚拟内存系统的策略，包括如何监测和调整其使用。

Modularity

                     进程是充分彼此独立的，以至于在需要的时候可以被部署到不同的处理器或者节点。

                     确定出必须联合部署（由于性能和吞吐量需求，或者进程间通信装置（比如旗语或者共享内存））的进程，并且考虑了不能分配工作量所带来的影响。

                     定义出那些可以在资源更加可用时再处理的异步消息。

The Deployment View

                     通过节点间的部署过程满足吞吐量需求，并且详细说明潜在的性能瓶颈。

                     在信息在多个节点间分发和复制的地方，要确保信息完整性。

                     可靠地传输消息的需求——如果存在这样的需求的话，要能被满足。

                     安全地传输消息的需求——如果存在这样的需求的话，要能被满足。

                     分布于节点间的进程，比如被最小化的网络通信和响应时间，要服从于连贯性和资源的限制。

                     系统可用性需求——如果存在这样的需求的话，要能被满足。

                     在服务器或者网络故障的事件中，确定最大系统当机时间，并且位于由需求定义的可接受的限制内。

                     清楚地规定了冗余和备份服务器，不会有多个服务器被委派为“首要”服务器。

                     所有潜在的故障模式都被记载到文档中。

                     网络中的故障可以被隔离、诊断和解决。

                     详细说明了CPU的使用上限，以及测量的方法。

                     当超出了最大CPU的使用上限，有策略说明了该采取什么动作。