构架思考--我们为什么需要构架
在一个典型的系统的开发过程中,首先是客户提出需求,设计人员根据需求进行分析和设计,程序员根据设计进行编程,最后是系统的测试和系统的分发。在整个软件过程中,参与到系统的角色各不相同,各种角色之间的关系是既合作又敌对的。系统的客户总希望花更少的前,获取更多的功能。开发公司则相反。开发人员讨厌无停止的改动,客户则认为开发出来的东西总是不满足自己的要求。在开发的过程总需要一个能够折中体现参与到系统的不同角色的不同要求。一套详细的设计说明?如果时间和金钱上允许的话,也许可以这么做,而且客户也许会没有耐心和你讨论关于函数接口的问题。或者是什么都不做,加快时间把系统做出来再讨论。实践证明了此路不通。我们需要的模糊和过分的详细之间找到一个平衡点。我们把它称之为构架。构架体现了不同风险承担者的要求的综合,借助于构架,设计师就可以分析众多风险承担者所提出的各种要求的优先级别,并且将这些要求转化为系统的各个特性,针对这些的特性,系统要在结构上做一些的妥协。
在上面我们提到系统特性,在《软件系统和软件构架》中也提到两个概念,原则(principle)和质量属性(Quality attributes)。这三个是相互关联的概念,
我个人认为系统特性是质量属性的具体的体现。软件的质量属性是指软件的性能,安全性,可用性,功能性和使用性等。系统的具体的某个需求大多数可以归纳为某个种
类的质量属性。在SEI的Architecture Tradeoff Analysis (ATA)中就讨论了如何将系统的需求归纳整理为不同的质量属性。原则在某种程度上等同于质量属性,比如说某套系统的开发过程中的技术原则是要能实现互操作性,在质量属性中也有类似的概念。基本上来说原则更为工程化一些,也就是在不同的系统中,你可以制定不同的原则。而质量属性相对更为抽象一些。在SEI方面的软件构架文章中,我们常看到的是质量属性,而在IEEE 1470-2000以及TOGAF8中,都是用原则(principle)来表示。无论是质量属性还是原则,都是作为评审软件构架的标准。在以后的文章中,我们就统一采用质量属性这个称呼。
由于构架综合体现了不同的风险承当者的要求,不同的风险承当的所关心的问题肯定是不一样的,所以在进行构架描述的时候,我们需要从多角度的来进行描述。就象建筑设计中一样,把所有的东西,比如外观设计,受力设计,水电设计等都放到一起肯定是不可行的,但这些分开的设计也不是都毫不相干的,它们之间既相对的独立,又相互联系,形成对一座建筑的完整的描述,不同的参与人员只关心他们要关系的时间,如结构工程师关注受力设计,水电工程师关注水电设计,建筑设计师负责整体统筹规划。在软件构架设计中也是一样,通过多个相对的独立又相互联系的视图来对构家架进行一个完整的描述,关于构架描述的权威性论述是IEEE 1470-2000,在SEI的《软件构架实践》中用软件结构来表示类似于构架视图的概念。"Architectureal blueprints- the 4+1 view model of
software architecture"提出了一个被广为使用的构架描述的模型,RUP过程的构架描述模板和HP公司的软件描述模板都和这个有莫大的渊源。也正是因为通过多个不同的角度来描述说明构架。不同的风险承担者可以通过构架进行交流,并且找到解决方案。基本上来说,构架的重要性可以被归纳为以下三点:(1)构架是风险承担者进行交流的手段。(2)构架是早期决策的体现。(3)构架是可传递,可重用的模型。具体的说明参见《软件构架实践》中的‘什么是软件构架’一章。由于构架如此的重要,在RUP过程中更是明确的说明整个的设计过程是以用例为驱动,以构架为核心的。