在一个典型的系统的开发过程中,首先是客户提出需求,设计人员根据需求进行分析和设计,程序员根据设计进行编程,最后是系统的测试和系统的分发。在整个软件过程中,参与到系统的角色各不相同,各种角色之间的关系是既合作又敌对的。系统的客户总希望花更少的前,获取更多的功能。开发公司则相反。开发人员讨厌无停止的改动,客户则认为开发出来的东西总是不满足自己的要求。在开发的过程总需要一个能够折中体现参与到系统的不同角色的不同要求。一套详细的设计说明?如果时间和金钱上允许的话,也许可以这么做,而且客户也许会没有耐心和你讨论关于函数接口的问题。或者是什么都不做,加快时间把系统做出来再讨论。实践证明了此路不通。我们需要的模糊和过分的详细之间找到一个平衡点。我们把它称之为构架。构架体现了不同风险承担者的要求的综合,借助于构架,设计师就可以分析众多风险承担者所提出的各种要求的优先级别,并且将这些要求转化为系统的各个特性,针对这些的特性,系统要在结构上做一些的妥协。
在上面我们提到系统特性,在《软件系统和软件构架》中也提到两个概念,原则和质量属性(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公司的软件描述模板都和这个有莫大的渊源。也正是因为通过多个不同的角度来描述说明构架。不同的风险承担者可以通过构架进行交流,并且找到解决方案。基本上来说,构架的重要性可以被归纳为以下三点:构架是风险承担者进行交流的手段。构架是早期决策的体现。构架是可传递,可重用的模型。具体的说明参见《软件构架实践》中的‘什么是软件构架’一章。由于构架如此的重要,在RUP过程中更是明确的说明整个的设计过程是以用例为驱动,以构架为核心的。
我先说一下个人理解的OOP:
//1.“消息分发”是运行时对象的本质
在面对过程的程序的运行是以“函数调用”的形式驱动的;在OOP中程序的运行是以“消息分发”的形式驱动的
“消息分发”的主体是程序的运行时对象,它具有以下功能:
a.对象的业务状态
b.根据外界的消息改变自己的业务状态
c.根据业务语义在适当的时候发送消息
//2.类数据是源代码中的概念(类和实例的概念)
如果在程序运行时也保留类数据的话,类数据只是实例数据的“创建时的模板”,例如:你可以在创建一个通用控件后自己SetWindowLong(,GWL_WNDPROC,) 来改变实例数据对象“根据外界的消息改变自己的业务状态”的能力
运行时对象数据必须有独立的“根据外界的消息改变自己的业务状态”的能力,如果运行时出现了类数据的话,类数据必然有自己的状态成员,所以它是某种新的运行时对象
只有在源代码中才有类和实例的差异,否则就是对象概念不够清晰
我的运行时结构的要求将包括:
1.具有运行时对象的清单
2.具有每个运行时对象的状态变化图,指定状态成员变量的名字
3.指定每个运行时对象可以处理的消息,以及消息的格式
4.指定每个运行时对象可以产生的消息,以及消息的格式
5.运行时结构将类似一个原型软件,通过运行时对象间的交互协调能满足需求书的要求
6.这些是临时写的,可能还有其它扩展