文档介绍：蒇由于本书是关于软件构建的,因此本节不会告诉你如何开发一个软件的架构;它关注是如何确定一个业已存在的架构的质量。因为架构比需求离构建活动又近了一步,所以对架构的讨论也会比对需求的讨论更详细一些。蒆膂为什么要把架构作为前期准备呢?因为架构的质量决定了系统的“概念完整性”。后者继而决定了系统的最终质量。一个经过慎重考虑的架构为“从顶层到底层维护系统的概念完整性”提供了必备的结构和体系,它为程序员提供了指引——其细节程度与程序员的技能和手边的工作相配。它将工作分为几个部分,使多个开发者或者多个开发团队可以独立工作。薈艿好的架构使得构建活动变得更容易。糟糕的架构则使构建活动几乎寸步难行。图3-7显示了糟糕的架构的另一个问题。膅节罿图3-7离开了良好的软件架构,你可能瞄准了正确的问题,但却使用了错误的解决方案。也许完全不可能有成功的构建蚇羄在构建期间或者更晚的时候进行架构变更,代价也是高昂的。修复软件架构中的错误所需的时间与修复需求错误所需的时间处于同一数量级——即,多于修复编码错误所需的时间(BasiliandPerricone1984,Willis1998)。架构变更如同需求变更一样,看起来一个很小的改动,影响也许是非常深远的。无论为了修正错误还是改进设计而引发架构变更,越早识别出变更越好。ponents螃蒂架构的典型组成部分螁袆很多组成部分是优秀的系统架构所共有的。如果你自己构建整个系统,那么在架构工作会与更详细的设计工作有重叠部分。在这种情况下,你至少应该思考架构的每个组成部分。如果你目前从事的系统的架构是别人做的,你应该能够不费力地找出其中重要的组成部分(无须戴上猎鹿帽、牵着猎犬、手拿放大镜)。在这两种情况中,你都需要考虑以下的架构组成部分。anization袇薈程序组织薄蚂系统架构首先要以概括的形式对有关系统做一个综述。如果没有这种综述,要想将成千的局部图片(或十多个单独的类)拼成一幅完整的图画是相当伤脑筋的。如果系统是小小的只有12块的智力拼图玩具,你那一岁的小孩也能在眨眼功夫解决它。不过把12个子系统拼到一起要困难一些,而且如果你不能将它们拼起来,那么就无法理解你正在开发的那个类对系统有何贡献。芈肆在架构中,你应该能发现对那些曾经考虑过的最终组织结构的替代方案的记叙,找到之所以选用最终的组织结构,而不用其他替代方案的理由。如果对某个类在系统中的角色没有一个清晰的构思,那么编写这个类就是一件令人灰心丧气的工作。描述其他组织结构,才能说明架构最后选定的这种系统组织结构的缘由,并且表明各个类都是慎重考虑过的。有一份对设计实践的综述发现,“维护‘设计的缘由’”至少与“维护设计本身”一样重要(Rombach1990)。芃螂架构应该定义程序的主要构造块(buildingblocks)。根据程序规模不同,各个构造块可能是单个类,也可能是由许多类组成的一个子系统。每个构造块无论是一个类还是一组协同工作的类和子程序,它们共同实现一种高层功能,诸如与用户交互、显示Web页面、解释命令、封装业务规则、访问数据,等等。每条列在需求中的功能特性(feature)都至少应该有一个构造块覆盖它。如果两个或多个构造块声称实现同一项功能,那么它们就应该相互配合而不会冲突。虿螈应该明确定义各个构造块的责任。每个构造块应该负责某一个区域的事情,并且对其他构造块负责的区域知道得越少越好。通过使各个构造块对其他构造块的了解达到最小,你能将设计的信息局限于各个构造块之内。莆螁肀膆肅应该明确定义每个构造块的通信规则。对于每个构造块,架构应该描述它能直接使用哪些构造块,能间接使用哪些构造块,不能使用哪些构造块。袁蒁MajorClasses袈袄主要的类羁薈架构应该详细定义所用的主要的类。它应该指出每个主要的类的责任,以及该类如何与其他类交互。它应该包含对类的继承体系、状态转换、对象持久化等的描述。如果系统足够大,它应该描述如何将这些类组织成一个个子系统。莆蚃架构应该记述曾经考虑过的其他类设计方案,并给出选用当前的组织结构的理由。架构无须详细说明系统中的每一个类。瞄准80/20法则:对那些构成系统80%的行为的20%的类进行详细说明(Jacobsen,Booch,andRumbaugh1999;Kruchten2000)。肁罿DataDesign肇蚆数据设计膁荿架构应该描述所用到的主要文件和数据表的设计。它应该描述曾经考虑过的其他方案,并说明做出选择的理由。如果应用程序要维护一个客户ID的列表,而架构师决定使用顺序访问的列表(sequential-accesslist)来表示该ID表,那么文档就应该解释为什么顺序访问的列表比随机访问的列表(random-accesslist)、堆栈、散列表要好。在构建期间,这些信息让你能洞察架构师的思想。在维护阶段,这种洞察力是无价之宝。