A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document.
构架需求指的是指对构架层次上有重要意义的需求，任何高风险，高优先级别和不稳定的需求都可以看成是对构架有重要意义的需求。在《Capturing Architectural Requirements》一文中对什么是构架需求和如何捕获构架需求进行了一个详细的描述，这里就不多加说明了。关于软件质量属性的描述可以参见《软件构架实践》中质量属性一章，SEI网站上的ATA方面的文章论述了如何将用户需求归纳整理为不同的质量属性，更为明确的路径是用户需求->构架需求->质量属性。归纳的目的是希望能够有更为一致的方法来进行构架设计的指导，同样在《软件构架实践》中的单元操作一章说明了不同的操作是如何的影响构架最终对不同的质量属性的满足程度。
我一直认为构架的原则就是在构架需求上整理总结出来的对系统的质量属性要求，包括技术上的要求和一些商业上的要求。这些的要求最终影响构架的设计。
另外一个需要进行讨论的是构架原则的表述，在描述系统需求的时候，我们经常会看到这样的话：“系统要求有良好的可扩展性和可更改性。”，包括在一些电子政务的需求说明书中也是这样。基本上来说，这句话说了等于没说，谁也不知道到底什么才算是良好可扩展性。在构架原则描述中有很多的时候就会涉及到诸如这中可扩展性等的质量属性问题，我个人认为在描述一个构架原则的时候必须包含以下的部分：原则的名称，选择该原则的原因说明，重新描述过的归属于该原则的构架需求。
47 个解决方案
#1
To walkcamel (虫子):
俺对构架没基础没概念
拜托介绍本好书先
搬个凳子
坐第一排
听课
俺对构架没基础没概念
拜托介绍本好书先
搬个凳子
坐第一排
听课
#2
很不错的，关注并支持！
#3
To zhuma(竹马):
《软件构架实践》
《软件构架实践》
#4
人说：“系统要求有良好的可扩展性和可更改性。”，women
换句话说，就是Time-friendly。和User-friendly相类似，只是要对时间友好。换句话说，在软件需求随着时间流逝发生变化的时候，系统可以进化。
软件工业的历史很短，从196*年算起，只有不到50年的时间。但是建筑设计行业少说也有几千年了，从金字塔的年代开始算的话。如果我们把历史遗留下来的建筑物进行比较的话，会发现有一些规律（为避免麻烦，考察的都是外国建筑，特此声明）。我打算大体上把他们分成三类：
（1）宗教建筑。永不进化。这类建筑从设计的时刻开始，就是要给人一种永恒的感觉，所以是绝对不打算进化甚至改作他用的。只是时间不饶人，现在大多只有一种用途：吸引游客。
3000年前的古埃及的法老Akhnaten曾经一度废止了古埃及的宗教，改信太阳教，宣告自己和皇后Nefertiti为神。那个时候做的第一件事，就是放弃沿袭了几百年的都城，在沙漠中另立新都。老的都城指以老的宗教为中心建立的，新的都城则以新的宗教信仰为中心建立。
当Akhnaten病死，Nefertiti被暗杀，埃及恢复老的宗教之后，第一件事业就是放弃新的都城，回到老都城。
在美国随处可见的天主教堂是另一个例子。前一阵子有一个天主教神职人员涉及猥亵幼童，教会被告，教堂破产。当时面临的一个问题，就是如何拍卖教堂资产，主要就是教堂。可是谁会买一座教堂？比如你是开餐馆的，开杂货铺的，开旅馆的，你买一个教堂干什么？那个教堂的样子和结构是特
由此可见，宗教建筑师以永恒为目标的。
我说的宗教建筑在近代包括了很多准宗教性建筑，比如美国的越战纪念碑，林肯纪念堂等。这些建筑根本就没打算改为其他用途，也根本没法改为其他用途。
（2）*建筑。所有的*建筑都是如同宗教建筑一样，打出一个永不变化的旗号，
换句话说，就是Time-friendly。和User-friendly相类似，只是要对时间友好。换句话说，在软件需求随着时间流逝发生变化的时候，系统可以进化。
软件工业的历史很短，从196*年算起，只有不到50年的时间。但是建筑设计行业少说也有几千年了，从金字塔的年代开始算的话。如果我们把历史遗留下来的建筑物进行比较的话，会发现有一些规律（为避免麻烦，考察的都是外国建筑，特此声明）。我打算大体上把他们分成三类：
（1）宗教建筑。永不进化。这类建筑从设计的时刻开始，就是要给人一种永恒的感觉，所以是绝对不打算进化甚至改作他用的。只是时间不饶人，现在大多只有一种用途：吸引游客。
3000年前的古埃及的法老Akhnaten曾经一度废止了古埃及的宗教，改信太阳教，宣告自己和皇后Nefertiti为神。那个时候做的第一件事，就是放弃沿袭了几百年的都城，在沙漠中另立新都。老的都城指以老的宗教为中心建立的，新的都城则以新的宗教信仰为中心建立。
当Akhnaten病死，Nefertiti被暗杀，埃及恢复老的宗教之后，第一件事业就是放弃新的都城，回到老都城。
在美国随处可见的天主教堂是另一个例子。前一阵子有一个天主教神职人员涉及猥亵幼童，教会被告，教堂破产。当时面临的一个问题，就是如何拍卖教堂资产，主要就是教堂。可是谁会买一座教堂？比如你是开餐馆的，开杂货铺的，开旅馆的，你买一个教堂干什么？那个教堂的样子和结构是特
由此可见，宗教建筑师以永恒为目标的。
我说的宗教建筑在近代包括了很多准宗教性建筑，比如美国的越战纪念碑，林肯纪念堂等。这些建筑根本就没打算改为其他用途，也根本没法改为其他用途。
（2）*建筑。所有的*建筑都是如同宗教建筑一样，打出一个永不变化的旗号，
#5
好帖子。
#6
人说：“系统要求有良好的可扩展性和可更改性。”
换句话说，就是Time-friendly。和User-friendly相类似，只是要对时间友好。换句话说，在软件需求随着时间流逝发生变化的时候，系统可以进化。
软件工业的历史很短，从196*年算起，只有不到50年的时间。但是建筑设计行业少说也有五千年了，从金字塔的年代开始算的话。如果我们把历史遗留下来的建筑物进行比较的话，会发现有一些规律（为避免麻烦，考察的都是外国建筑，特此声明）。我打算大体上把他们分成三类：
（1）宗教建筑。永不进化。这类建筑从设计的时刻开始，就是要给人一种永恒的感觉，所以是绝对不打算进化甚至改作他用的。只是时间不饶人，现在大多只有一种用途：吸引游客，就跟搬进博物馆一样。
3000年前的古埃及的法老Akhnaten曾经一度废止了古埃及的宗教，改信太阳教，宣告自己和皇后Nefertiti为神。那个时候做的第一件事，就是放弃沿袭了几百年的都城，在沙漠中另立新都。老的都城指以老的宗教为中心建立的，新的都城则以新的宗教信仰为中心建立。
当Akhnaten病死，Nefertiti被暗杀，埃及恢复老的宗教之后，第一件事就是放弃新都城，回到老都城。
在美国随处可见的天主教堂是另一个例子。前一阵子有一个天主教神职人员涉及猥亵幼童，教会被告，教堂破产。当时面临的一个问题，就是如何拍卖教堂资产，主要就是教堂建筑。可是谁会买一座教堂？比如你是开餐馆的，开杂货铺的，开旅馆的，你买一个教堂干什么？那个教堂的样子和结构是特别为教堂设计的，根本干不了别的用途。
由此可见，宗教建筑师以永恒为目标的，不具备Time-friendliness。
我说的宗教建筑在近代包括了很多准宗教性建筑，比如美国的越战纪念碑，林肯纪念堂等。这些建筑根本就没打算改为其他用途，也根本没法改为其他用途。
（2）*建筑。所有的*建筑都如同宗教建筑一样，打出一个永不变化的旗号，但是它们总是在变化。你如果到过曼哈顿、纽约州首府Albany就会发现，建筑物不能说不雄伟，但是很不实用。特别是很多建筑已经几十年甚至一百年，里面的结构不能适应今天的需要，但是很难改变，因为当时的设计就是以不变为目标的。如果你到里面看一看的话，就会发现在那种建筑物里面工作是多么的痛苦，死建筑让活人受罪。
换言之，这种建筑物应当具备Time-friendliness，但是很遗憾，往往并不具备。
（3）住宅。这种建筑物变化缓慢，我的同事住在一座已经有一百年历史的石头楼房里面，除了佣人房间已改为他用，卫生间太小、厨房太小不合时宜之外，并没有明显的不便。
（4）商业建筑。这种建筑物变化最为迅速，从结构到内部各种服务设施，到建筑物外表，都以几年为周期迅速变化。
在华尔街上走一走就会发现，这个寸土寸金的金融中心，居然有豪华公寓散落其中。而这些公寓看上去和办公楼没有两样。这是为什么呢？原因很简单：这些建筑物本来就是办公楼，但是因为内部服务性的设施没有办法跟上时代的需求，建筑物已经无法继续作为办公楼使用。比如电梯间太小，而且房屋结构很难改造，电梯间也无法扩大，大量电脑通讯管线无法铺设等等原因，没有公司愿意租这样的楼。使得物主只好另寻其他办法，而改为住宅不失为一个好主意。
实际上，从八十年代开始的IT革命所带来的大量电脑管线淘汰了大批老旧的建筑物。大部分的办公楼只好推倒重来，像华尔街的那几座幸存者那么幸运的只是极少数。
没人能够预见将来，一百年前的物主没办法对建筑设计师说，请留出更多的空间给电梯，或者留出更多的空间给电脑管线，或者告诉设计师，说几十年后的住户将不需要佣人了，他们将需要把用人房改为他用，他们也没有办法预见到厨房、卫生间太小的问题。
软件设计与建筑物设计有惊人的相似之处，只是软件的淘汰比建筑物更快。客户没有办法对软件架构师说，请你给我留出一些可以向…方向上的扩展余地。
客户能要求的，其实就是软件的Time-friendliness。而这个问题难道不是最为困难的么？
换句话说，就是Time-friendly。和User-friendly相类似，只是要对时间友好。换句话说，在软件需求随着时间流逝发生变化的时候，系统可以进化。
软件工业的历史很短，从196*年算起，只有不到50年的时间。但是建筑设计行业少说也有五千年了，从金字塔的年代开始算的话。如果我们把历史遗留下来的建筑物进行比较的话，会发现有一些规律（为避免麻烦，考察的都是外国建筑，特此声明）。我打算大体上把他们分成三类：
（1）宗教建筑。永不进化。这类建筑从设计的时刻开始，就是要给人一种永恒的感觉，所以是绝对不打算进化甚至改作他用的。只是时间不饶人，现在大多只有一种用途：吸引游客，就跟搬进博物馆一样。
3000年前的古埃及的法老Akhnaten曾经一度废止了古埃及的宗教，改信太阳教，宣告自己和皇后Nefertiti为神。那个时候做的第一件事，就是放弃沿袭了几百年的都城，在沙漠中另立新都。老的都城指以老的宗教为中心建立的，新的都城则以新的宗教信仰为中心建立。
当Akhnaten病死，Nefertiti被暗杀，埃及恢复老的宗教之后，第一件事就是放弃新都城，回到老都城。
在美国随处可见的天主教堂是另一个例子。前一阵子有一个天主教神职人员涉及猥亵幼童，教会被告，教堂破产。当时面临的一个问题，就是如何拍卖教堂资产，主要就是教堂建筑。可是谁会买一座教堂？比如你是开餐馆的，开杂货铺的，开旅馆的，你买一个教堂干什么？那个教堂的样子和结构是特别为教堂设计的，根本干不了别的用途。
由此可见，宗教建筑师以永恒为目标的，不具备Time-friendliness。
我说的宗教建筑在近代包括了很多准宗教性建筑，比如美国的越战纪念碑，林肯纪念堂等。这些建筑根本就没打算改为其他用途，也根本没法改为其他用途。
（2）*建筑。所有的*建筑都如同宗教建筑一样，打出一个永不变化的旗号，但是它们总是在变化。你如果到过曼哈顿、纽约州首府Albany就会发现，建筑物不能说不雄伟，但是很不实用。特别是很多建筑已经几十年甚至一百年，里面的结构不能适应今天的需要，但是很难改变，因为当时的设计就是以不变为目标的。如果你到里面看一看的话，就会发现在那种建筑物里面工作是多么的痛苦，死建筑让活人受罪。
换言之，这种建筑物应当具备Time-friendliness，但是很遗憾，往往并不具备。
（3）住宅。这种建筑物变化缓慢，我的同事住在一座已经有一百年历史的石头楼房里面，除了佣人房间已改为他用，卫生间太小、厨房太小不合时宜之外，并没有明显的不便。
（4）商业建筑。这种建筑物变化最为迅速，从结构到内部各种服务设施，到建筑物外表，都以几年为周期迅速变化。
在华尔街上走一走就会发现，这个寸土寸金的金融中心，居然有豪华公寓散落其中。而这些公寓看上去和办公楼没有两样。这是为什么呢？原因很简单：这些建筑物本来就是办公楼，但是因为内部服务性的设施没有办法跟上时代的需求，建筑物已经无法继续作为办公楼使用。比如电梯间太小，而且房屋结构很难改造，电梯间也无法扩大，大量电脑通讯管线无法铺设等等原因，没有公司愿意租这样的楼。使得物主只好另寻其他办法，而改为住宅不失为一个好主意。
实际上，从八十年代开始的IT革命所带来的大量电脑管线淘汰了大批老旧的建筑物。大部分的办公楼只好推倒重来，像华尔街的那几座幸存者那么幸运的只是极少数。
没人能够预见将来，一百年前的物主没办法对建筑设计师说，请留出更多的空间给电梯，或者留出更多的空间给电脑管线，或者告诉设计师，说几十年后的住户将不需要佣人了，他们将需要把用人房改为他用，他们也没有办法预见到厨房、卫生间太小的问题。
软件设计与建筑物设计有惊人的相似之处，只是软件的淘汰比建筑物更快。客户没有办法对软件架构师说，请你给我留出一些可以向…方向上的扩展余地。
客户能要求的，其实就是软件的Time-friendliness。而这个问题难道不是最为困难的么？
#7
ting
#8
To walkcamel (虫子):
那是不是指
构架是对关键问题给出的清晰准确的回答？
而哪些问题是重要而又实际的呢？
To jeffyan77(jeffyan77):
Time-friendly
我喜欢这个词
出自哪本书？
那是不是指
构架是对关键问题给出的清晰准确的回答？
而哪些问题是重要而又实际的呢？
To jeffyan77(jeffyan77):
Time-friendly
我喜欢这个词
出自哪本书？
#9
拿建筑的观念和软件进行比较我个人觉得是软件工程研究犯的最大的错误，恰恰相反，现代的软件开发环境领先于建筑，发展的趋势是建筑设计变得越来越像软件而不是相反。架构只要知道分层就可以了，就足以解决任何的问题了，除非为了研究而不是制作软件。
#10
这些个大哥说了这么多等于什么都没说！楼下的，你认为呢？
#11
好文 跟进 我顶ing
#12
zhuma(竹马) :
构架是对关键问题给出的清晰准确的回答？
是的
而哪些问题是重要而又实际的呢？
没有统一的标准，不同类型的系统有不同的要求，有经验的工程师可能会根据他的过往经验给予你一些忠告，可我目前还只是个学生：（。
去看看软件质量属性相关的内容，会告诉你一个软件一般具有什么样的特征。等你明白后，剩下的就是具体问题具体分析了。
例外在在SEI的站点上，有不少关于如何分析的文章，有空可以去看看。
构架是对关键问题给出的清晰准确的回答？
是的
而哪些问题是重要而又实际的呢？
没有统一的标准，不同类型的系统有不同的要求，有经验的工程师可能会根据他的过往经验给予你一些忠告，可我目前还只是个学生：（。
去看看软件质量属性相关的内容，会告诉你一个软件一般具有什么样的特征。等你明白后，剩下的就是具体问题具体分析了。
例外在在SEI的站点上，有不少关于如何分析的文章，有空可以去看看。
#13
to jeffyan77(jeffyan77):
Time-friendly这个概念很好，不过也诚如你说的，说起来简单，做起来难。另外我也想知道这些材料出于什么地方。
to lynxliu(lynx):
其实建筑师是我最先的梦想，不过本科的时候却进了土木结构专业（没有美术功底），呵呵。下过几次工地，对工地中的施工管理的印象比较深，各工种间的协调施工，并行施工，感觉安排的很有条理，而且有很过的国家规范，计算工期呀，人工呀还有材料什么的，一套用就好了，有些差距但也不是很多。后面开始学习计算机专业，总也是希望也有着相建筑那边那样的规范手册就好了，呵呵，希望以后会有的哦，而且在做受力分析的时候也还都有公式套用，多少钢筋，多少水泥，大家算出来看看都差不多，在这点上目前的软件工程还相差很远。
软件工程研究的并不只是构架的问题，还有过程管理的问题，建筑行业开始大量的采用软件来出来，并且有的地方用的很成功是因为背后有成熟的理论和大量的规范化成果出来。这也是软件的CASE工具没有大规模使用的原因之一吧。
Time-friendly这个概念很好，不过也诚如你说的，说起来简单，做起来难。另外我也想知道这些材料出于什么地方。
to lynxliu(lynx):
其实建筑师是我最先的梦想，不过本科的时候却进了土木结构专业（没有美术功底），呵呵。下过几次工地，对工地中的施工管理的印象比较深，各工种间的协调施工，并行施工，感觉安排的很有条理，而且有很过的国家规范，计算工期呀，人工呀还有材料什么的，一套用就好了，有些差距但也不是很多。后面开始学习计算机专业，总也是希望也有着相建筑那边那样的规范手册就好了，呵呵，希望以后会有的哦，而且在做受力分析的时候也还都有公式套用，多少钢筋，多少水泥，大家算出来看看都差不多，在这点上目前的软件工程还相差很远。
软件工程研究的并不只是构架的问题，还有过程管理的问题，建筑行业开始大量的采用软件来出来，并且有的地方用的很成功是因为背后有成熟的理论和大量的规范化成果出来。这也是软件的CASE工具没有大规模使用的原因之一吧。
#14
软件项目和建筑项目的区别在于需求的变更，建筑在需求确定以后基本就稳定了，而软件不同，需求总是在变的，所以架构的出现也只是为了解决需求不断变化的这个问题，但是一个好的架构是远远不够的，还有有良好的项目管理（包括计划控制、需求变更管理、开发过程的优化等）
#15
小楼一夜听春雨.
#16
to twinsant124(蚂蚁的天空):
You can type Chinese now?
You can type Chinese now?
#17
软件的构建确实与建筑有相似之处，但我认为软件所覆盖的范围要远远大于建筑，建筑尽管有各种类型，但用途大体相似，五千年来也没怎么变过，你会要求一栋房子给你放音乐吗？但人们对于软件的要求却是多种多样的，软件无处不在，它帮你打电话，跟你玩游戏，还管着你的钱，股票……软件是一个广泛的东西，它会以各种形式存在，这就是为什么软件开发那么难的原因。
出于软件的这种特点，软件不可能有一个通用的建造方法，也不可能存在一个完全通用的软件架构的，因为它不可能满足所有人的需求，我的看法是应该对于软件这个行业进行进一步的细分，再针对细分的行业建立起相对稳定的架构，建立相应的制造流程，才谈得上项目管理的方法等等。构架的原则也需要首先建立在你的具体应用的特点上。
出于软件的这种特点，软件不可能有一个通用的建造方法，也不可能存在一个完全通用的软件架构的，因为它不可能满足所有人的需求，我的看法是应该对于软件这个行业进行进一步的细分，再针对细分的行业建立起相对稳定的架构，建立相应的制造流程，才谈得上项目管理的方法等等。构架的原则也需要首先建立在你的具体应用的特点上。
#18
to lynxliu(lynx):
在某种编程语言中实现统一个确定的功能，这算是一个有“硬指标”的问题吧？十个程序员写出的代码就可能有十种。
我曾经教过一个十二个人的班学习一门高级编程课，最后给出的课后作业是一个小型项目的设计。你猜怎么着？我收到了十三份答案。原来其中一位同学缴了两份不同的设计。
更何况软件设计这样一个没有确定“硬指标”的问题，本来就是见仁见智的事情，基本上谈不上对错。如果你说某种看法就是错的，就需要讲讲理由。如果你说这不仅是错的，而且是“软件工程研究犯的最大的错误”，这“最大”又从何而来，总的说明一下吧，呵呵？
在某种编程语言中实现统一个确定的功能，这算是一个有“硬指标”的问题吧？十个程序员写出的代码就可能有十种。
我曾经教过一个十二个人的班学习一门高级编程课，最后给出的课后作业是一个小型项目的设计。你猜怎么着？我收到了十三份答案。原来其中一位同学缴了两份不同的设计。
更何况软件设计这样一个没有确定“硬指标”的问题，本来就是见仁见智的事情，基本上谈不上对错。如果你说某种看法就是错的，就需要讲讲理由。如果你说这不仅是错的，而且是“软件工程研究犯的最大的错误”，这“最大”又从何而来，总的说明一下吧，呵呵？
#19
windancery(Java的真实拥护者!) 说“建筑在需求确定以后基本就稳定了”
不是，呵呵。近代中国变化剧烈，可能不易分辨建筑物在建成之后需求的变化和环境因素的变化。
在美国这个地方社会环境非常稳定，建筑业成熟的很早，大规模的建筑作业早就已经完成，在很多城市很少看到新的房子。建筑物常常建成后连续使用超过50年，甚至超过百年。这使得一些建筑设计师得以研究建筑物在建好之后发生了什么，是因为什么使得建筑物不断被整修、改造、最后被推倒重来的。
他们的结论是建筑物很少是因为濒于倒塌或者其他严重结构破损而被放弃的。相反，大多数的建筑物是因为无法满足物主的需求而被放弃的，这些房屋在被放弃的时候仍然是非常结实的建筑，根本没有结构损伤，正常使用的话，完全可以再持续200年到300年。
有一些设计师把老的建筑物照片找出来，从而可以清晰地看到十年后、二十年后、...，两栋一模一样、同时建造的房子，在建好之后放生了什么。
另有一些建筑师把Boston街区的照片找出来，研究这些建筑物是如何随着时间演变的。著名建筑学家Steward Brand说，好的建筑都是“为变化而建的”（Built for Change），从古至今，人类所建造的千千万万的建筑物，其成功与失败全在于是否能够适应需求的变化。英国皇家建筑学院院长Frank Duffy说，“我们的基本观点是根本就不存在‘一栋建筑’这样的概念。”为什么这样说呢？“一栋建筑”是一个固体的概念；而作为一个固体的建筑物并不存在，真正存在的是一个流体，它处在不断的流动和变化之中。
Time-friendly就是他们提出来的，我想把它借过来描述软件设计的类似问题。这也是我一直感兴趣的问题，就是需求曲线的一次导数曲线对软件设计的影响。我的基本观点是Design for Change，也就是“为变化而设计”。
一个类似的词汇是Timeless，由Alexander提出。我倾向于使用Time-friendly，因为。。。很简单，没有什么东西是永恒的。但是提出Time-friendly的建筑设计师Steward Brand实际上非常推崇Alexander，只是没有那么多的哲学思考而已。
参考文献
[BRAND94]Stewart Brand，How Buildings Learn: What Happens After They're Built, Viking, 1994（呵呵，那时候UML在哪里，设计模式在那里？）
不是，呵呵。近代中国变化剧烈，可能不易分辨建筑物在建成之后需求的变化和环境因素的变化。
在美国这个地方社会环境非常稳定，建筑业成熟的很早，大规模的建筑作业早就已经完成，在很多城市很少看到新的房子。建筑物常常建成后连续使用超过50年，甚至超过百年。这使得一些建筑设计师得以研究建筑物在建好之后发生了什么，是因为什么使得建筑物不断被整修、改造、最后被推倒重来的。
他们的结论是建筑物很少是因为濒于倒塌或者其他严重结构破损而被放弃的。相反，大多数的建筑物是因为无法满足物主的需求而被放弃的，这些房屋在被放弃的时候仍然是非常结实的建筑，根本没有结构损伤，正常使用的话，完全可以再持续200年到300年。
有一些设计师把老的建筑物照片找出来，从而可以清晰地看到十年后、二十年后、...，两栋一模一样、同时建造的房子，在建好之后放生了什么。
另有一些建筑师把Boston街区的照片找出来，研究这些建筑物是如何随着时间演变的。著名建筑学家Steward Brand说，好的建筑都是“为变化而建的”（Built for Change），从古至今，人类所建造的千千万万的建筑物，其成功与失败全在于是否能够适应需求的变化。英国皇家建筑学院院长Frank Duffy说，“我们的基本观点是根本就不存在‘一栋建筑’这样的概念。”为什么这样说呢？“一栋建筑”是一个固体的概念；而作为一个固体的建筑物并不存在，真正存在的是一个流体，它处在不断的流动和变化之中。
Time-friendly就是他们提出来的，我想把它借过来描述软件设计的类似问题。这也是我一直感兴趣的问题，就是需求曲线的一次导数曲线对软件设计的影响。我的基本观点是Design for Change，也就是“为变化而设计”。
一个类似的词汇是Timeless，由Alexander提出。我倾向于使用Time-friendly，因为。。。很简单，没有什么东西是永恒的。但是提出Time-friendly的建筑设计师Steward Brand实际上非常推崇Alexander，只是没有那么多的哲学思考而已。
参考文献
[BRAND94]Stewart Brand，How Buildings Learn: What Happens After They're Built, Viking, 1994（呵呵，那时候UML在哪里，设计模式在那里？）
#20
To fita(天外飞仙):
即便是建筑，也有住宅用房、商业用房、桥梁、公路等等很多种类，一点都不比软件逊色。
卡尔.马克思在《资本论》中说，蜘蛛的活动与织工的活动相似，蜜蜂建筑蜂房的本领使人间的许多建筑师感到惭愧。但是，最蹩脚的建筑师从一开始就比最灵巧的蜜蜂高明，因为他在建造真实建筑物以前，已经在自己的头脑中把它的结构建好了。
人造的所有工具不都是这样的吗？
在人造工具中，以建筑物为最早、最经久耐用，以软件为最新和最抽象。不同的人造工具有不同的功能（function），但是所有的人造工具都有同样的根本属性，就是它们必须满足人的需求。从这个角度上看，软件和建筑物、随身听、板凳桌椅并无本质区别。
参考文献
[MARX]Karl Marx,《资本论》（第一卷），中国社会科学出版社，1983年1月第一版。（大学毕业时同学扔下的，我一直带着，直到纽约，呵呵）
即便是建筑，也有住宅用房、商业用房、桥梁、公路等等很多种类，一点都不比软件逊色。
卡尔.马克思在《资本论》中说，蜘蛛的活动与织工的活动相似，蜜蜂建筑蜂房的本领使人间的许多建筑师感到惭愧。但是，最蹩脚的建筑师从一开始就比最灵巧的蜜蜂高明，因为他在建造真实建筑物以前，已经在自己的头脑中把它的结构建好了。
人造的所有工具不都是这样的吗？
在人造工具中，以建筑物为最早、最经久耐用，以软件为最新和最抽象。不同的人造工具有不同的功能（function），但是所有的人造工具都有同样的根本属性，就是它们必须满足人的需求。从这个角度上看，软件和建筑物、随身听、板凳桌椅并无本质区别。
参考文献
[MARX]Karl Marx,《资本论》（第一卷），中国社会科学出版社，1983年1月第一版。（大学毕业时同学扔下的，我一直带着，直到纽约，呵呵）
#21
又看了一遍，还是只看到一堆人在说废话。。。。。。
拜托，下次取帖子的名字是注意一点。所谓“构架思考（3）-构架的原则”？？？？？？？
拜托，下次取帖子的名字是注意一点。所谓“构架思考（3）-构架的原则”？？？？？？？
#22
确实写的不错！！！
再接再厉!!!
再接再厉!!!
#23
fita(天外飞仙)说的对极了，其实道理原本不难理解，其实建筑和软件的差别很大。能够和软件对比的是整个的制造工业，你不会要求制造工业有一个统一的制造规范吧。现在的软件工业把生产化妆品的人和生产拖拉机的人一视同仁，呵呵，还要什么统一的架构，标准，岂不是滑稽。其实，任何的逻辑都是可以软件化，也可以进一步硬件化的。使用不同的手段进行实现是因为那样作有利。所以，谈好的软件设计首先就要知道它为什么需要做成软件，为什么适合做成软件，为什么可以做成软件，没有这样的理解，只能是看看手里有什么，然后就开始做，和用锤子做汽车没什么不同。
不多说了，jeffyan77(jeffyan77)写的书把模式和哲学牵扯在一起有点类似把软件和建筑来比，看到了一点相似的地方，却不能够很好的说明问题。这也是我曾经提出过的。其实SA重要的能力就是对于系统进行恰当的对比，如何才能恰当则取决于SA本人的修养和能力了。
我和walkcamel(虫子)一样，曾经梦想做一名建筑师，大学学习城市规划，可惜后来也转向了软件，不过我仍然非常关注新的建筑。总体的感觉是建筑在向软件的方向发展，重视创造力，在满足力学需要的基础之上，满足人们的多重需求。整个发展是技术导向的，而不是什么管理，现有技术突破，后有技术应用，最后是管理规范。这就摆脱了重复的制造。所以，我觉得不是建筑向软件学习而是相反，所有的制造工业向IT行业学习，建立更加人性化的产品而不是功能化的产品。同时，建筑业也日益脱离劳动密集的价值模式，转移到智力密集的模式，从需求开始进行，这和软件又有何不同？模式，UML等等都提到了建筑，模式这样的词汇据说也是建筑师发明的，但是软件其实也在向其他的传统行业学习，这枚什么奇怪的。奇怪的是很多人非要软件的生产模式和建筑类似，比如发明软件蓝领这样的概念，不是说这样的说法肯定不对，而是指望这样就可以成为软件强国是不可能的，不符合软件发展的实际需要。这是我说用建筑来比软件是软件工程最大失败的原因。
又说了一大堆废话，呵呵，其实无论什么方法，客户满意，产品有市场才是最重要的。技术，管理都是为此服务的。结构化设计没什么不好，OO不正确的理解和使用的时候引起的问题更多，CBD，GP都是各有特点的方法，这些共同丰富了软件技术，却不是应该互相取代的。就像属于爬行动物的蛇可以吃掉哺乳动物一样，只要适应商业环境，技术就会存在和发展，反之才会淘汰。所以，掌握自己手里的技术，发挥它的长处，找一个适合的环境是我们首先需要考虑的。
不多说了，jeffyan77(jeffyan77)写的书把模式和哲学牵扯在一起有点类似把软件和建筑来比，看到了一点相似的地方，却不能够很好的说明问题。这也是我曾经提出过的。其实SA重要的能力就是对于系统进行恰当的对比，如何才能恰当则取决于SA本人的修养和能力了。
我和walkcamel(虫子)一样，曾经梦想做一名建筑师，大学学习城市规划，可惜后来也转向了软件，不过我仍然非常关注新的建筑。总体的感觉是建筑在向软件的方向发展，重视创造力，在满足力学需要的基础之上，满足人们的多重需求。整个发展是技术导向的，而不是什么管理，现有技术突破，后有技术应用，最后是管理规范。这就摆脱了重复的制造。所以，我觉得不是建筑向软件学习而是相反，所有的制造工业向IT行业学习，建立更加人性化的产品而不是功能化的产品。同时，建筑业也日益脱离劳动密集的价值模式，转移到智力密集的模式，从需求开始进行，这和软件又有何不同？模式，UML等等都提到了建筑，模式这样的词汇据说也是建筑师发明的，但是软件其实也在向其他的传统行业学习，这枚什么奇怪的。奇怪的是很多人非要软件的生产模式和建筑类似，比如发明软件蓝领这样的概念，不是说这样的说法肯定不对，而是指望这样就可以成为软件强国是不可能的，不符合软件发展的实际需要。这是我说用建筑来比软件是软件工程最大失败的原因。
又说了一大堆废话，呵呵，其实无论什么方法，客户满意，产品有市场才是最重要的。技术，管理都是为此服务的。结构化设计没什么不好，OO不正确的理解和使用的时候引起的问题更多，CBD，GP都是各有特点的方法，这些共同丰富了软件技术，却不是应该互相取代的。就像属于爬行动物的蛇可以吃掉哺乳动物一样，只要适应商业环境，技术就会存在和发展，反之才会淘汰。所以，掌握自己手里的技术，发挥它的长处，找一个适合的环境是我们首先需要考虑的。
#24
to:fita(天外飞仙):
关于构架分类的方法，在国外已经有人进行，而且已经有相当的成果了。很多的参考技术构架都上属于这范围的。不过目前国内这方面的工作比较少，也许有一些吧，也都当做公司的机密不发布的。
关于构架分类的方法，在国外已经有人进行，而且已经有相当的成果了。很多的参考技术构架都上属于这范围的。不过目前国内这方面的工作比较少，也许有一些吧，也都当做公司的机密不发布的。
#25
to samgol(堕落之洲)
这就是你的思考？
这就是你的思考？
#26
mark
#27
其实，我相信看待软件工程本身也有不同的角度。比方说，是做软件工程研究的，还是软件商业开发的。前者追求的是更为完美的形式，而后者呢，追求的是利润，而且很有可能是短期的利润。在这样的环境差别下，对于架构就会有不同的形式。就像建筑，村屋也是一种架构，它解决的是另一种问题，而大厦解决的就是另外一个问题了。所以我认为软件架构的问题应该是具体环境具体分析，只有当软件工程像建筑一样发展了几千年以后，也许就会趋于大的统一了吧。在下愚见，只想抛砖引玉。
#28
对于软件的构造,我来谈几句.
在经历了数个软件项目之后,我发现包括自己在内,都曾说过太多次数的一句:客户无法准确地提出需求来.这就让我们的工程进度一拖再拖,甚至到最后双方无法忍受而放弃了.我们再来看看建筑方法的:不论是商业建筑还是住宅,请问最终用户提出过需求吗?这里就存在一个明显的不同之处,建筑不是最终用户在提需求,而是中间服务商在提需求.
我在想,如果软件工程也采用这种思路,即最终客户并不是直接找软件公司来构建他自己的软件系统,而是找软件服务公司(与现在的管理咨询公司有些相同的功能,但内涵更深)来为其提供最恰当的系统.对软件开发公司,提需求的不再是客户,而是咨询服务公司.那么无论是从专业的深度,还是业务领域的精通,我想咨询公司都要比我们现在面对的最终客户要准确\恰当得多.我们构建的系统也将会如建筑一样,在局部调整时不会伤筋动骨了.
在经历了数个软件项目之后,我发现包括自己在内,都曾说过太多次数的一句:客户无法准确地提出需求来.这就让我们的工程进度一拖再拖,甚至到最后双方无法忍受而放弃了.我们再来看看建筑方法的:不论是商业建筑还是住宅,请问最终用户提出过需求吗?这里就存在一个明显的不同之处,建筑不是最终用户在提需求,而是中间服务商在提需求.
我在想,如果软件工程也采用这种思路,即最终客户并不是直接找软件公司来构建他自己的软件系统,而是找软件服务公司(与现在的管理咨询公司有些相同的功能,但内涵更深)来为其提供最恰当的系统.对软件开发公司,提需求的不再是客户,而是咨询服务公司.那么无论是从专业的深度,还是业务领域的精通,我想咨询公司都要比我们现在面对的最终客户要准确\恰当得多.我们构建的系统也将会如建筑一样,在局部调整时不会伤筋动骨了.
#29
软件服务公司
menliwxj(有缘)的观点很有意思
menliwxj(有缘)的观点很有意思
#30
但是它应该存在于哪种类型的软件中呢？
消费类？
企业类？
专业类？
都挺难切入的
希望 menliwxj(有缘) 进一步阐述
消费类？
企业类？
专业类？
都挺难切入的
希望 menliwxj(有缘) 进一步阐述
#31
zhuma(竹马):
我自己一直从事的企业类的软件系统设计,因此出发点主要是从企业类的信息管理角度出发来考虑的.至于如电信等领域我就不太清楚了.我的这个想法也是刚才在看了上面各位的讨论之后想到的.目前还无法更进一步地陈述.
我自己一直从事的企业类的软件系统设计,因此出发点主要是从企业类的信息管理角度出发来考虑的.至于如电信等领域我就不太清楚了.我的这个想法也是刚才在看了上面各位的讨论之后想到的.目前还无法更进一步地陈述.
#32
Menliwxj的想法很正常，而且现在也出现了这样的公司。我想menliwxj碰到的问题在于：可能企业本身的IT人员能力不强，或者企业政治的因素影响了系统的进展。所以对于大型的系统来说，可能面临的不仅仅是技术的问题，还有管理的问题，公关的问题，企业文化的问题。所以技术人员会感觉很无助。如何根本地解决这种现状呢？我认为，只有更多的技术人员进入核心管理层以后，整个软件业的发展才会有更大的提高。这就需要兄弟姐妹们多努力，成为“又红又专”的精英！
#33
一、人们不要求房子能放音乐……就象人们不要求作图软件能处理音乐。如果你说未来的智能化建筑其实也可以要求房子放音乐，那么，房子其实还是不能音乐，这其实是一个系统集成的问题，就象作图软件里可以处理音乐一样。…这由需求推动，但需求是分层次的，前一个需求没有达成时，后面的需求不会提出，或者不会表现得太过迫切，诚如：饱暖思淫欲…
二、对于软件和建筑的差别，其很大一个原因是来自于人这个物种自身的渺小，人的生命太短，假如从遮风避雨到智能通讯这个需求变化过程在一个月之内经历，那你会发现建筑和软件有更多的相似，——其实不只是建筑。再来一个其实吧……你看到现在的人住在一个古老的住房里，没有太多不便，就好象WORD升级到XP之后，写一句留言还是可以用“记事本”，这只是说明我做“留言”这件事时并无我办公时的需求，就好象住古老建筑的朋友最终还是得跑到写字楼去办公。死抱正版的人们还会出于成本考虑……去使用免费，这是另一话题。
二、对于软件和建筑的差别，其很大一个原因是来自于人这个物种自身的渺小，人的生命太短，假如从遮风避雨到智能通讯这个需求变化过程在一个月之内经历，那你会发现建筑和软件有更多的相似，——其实不只是建筑。再来一个其实吧……你看到现在的人住在一个古老的住房里，没有太多不便，就好象WORD升级到XP之后，写一句留言还是可以用“记事本”，这只是说明我做“留言”这件事时并无我办公时的需求，就好象住古老建筑的朋友最终还是得跑到写字楼去办公。死抱正版的人们还会出于成本考虑……去使用免费，这是另一话题。
#34
imafool的话反映了另外一个事实：建筑的需求变化速度要远远慢于软件的变化速度。
为什么会这样呢，我想也许是因为软件的制造比建筑的制造要容易得多，房子的设计很大程度上需要遵守自然规律，比如说承重结构等，人们对于房子的需求也是很大程度上受到这些限制的，提需求的人也接受了这一点，建筑的需求变化慢，自然建筑的建造方法、架构也能够保持相对稳定，管理起来也就容易得多。
与建筑相比，软件制造的限制要小得多，人们的需求实现得快，自然也就变化得快了（人真是一个不容易满足的动物）。jeffyan77提出的Time Friendly概念，我想对于软件来说，已经远远超出Friendly的要求了，也许应该说Timeless, 或Change Critically。
为什么会这样呢，我想也许是因为软件的制造比建筑的制造要容易得多，房子的设计很大程度上需要遵守自然规律，比如说承重结构等，人们对于房子的需求也是很大程度上受到这些限制的，提需求的人也接受了这一点，建筑的需求变化慢，自然建筑的建造方法、架构也能够保持相对稳定，管理起来也就容易得多。
与建筑相比，软件制造的限制要小得多，人们的需求实现得快，自然也就变化得快了（人真是一个不容易满足的动物）。jeffyan77提出的Time Friendly概念，我想对于软件来说，已经远远超出Friendly的要求了，也许应该说Timeless, 或Change Critically。
#35
各位楼上的思想都好深邃，我只能到‘明确需求，双方签字’，‘需求变动，掏钱’的层次，而不会去考虑time-friendly。看了你们的发言之后，就觉得你们追求的境界会更加有成就感，甚至‘使命感’。谢谢大家，我要向大家学习，要在工作的时候时时考虑这个问题。
#36
很深刻，
好像有点跑题，
我觉得，大家都不否认建筑业同软件业很有相同点，
结论是，软件业和建筑业很相似。
那么大家在讨论什么？
我想，对于力于阐明软件项目和建筑项目相似的朋友，
主要还是想把一些用于建筑的好的东西引入软件，
或者说，大家可以借鉴建筑领域的东西来进行软件开发，
我想到了软件模式，
其实说白了，三人行必有我师，
对于不同的领域，到了高处，很多东西也都是可以相互借鉴的吧。
好像有点跑题，
我觉得，大家都不否认建筑业同软件业很有相同点，
结论是，软件业和建筑业很相似。
那么大家在讨论什么？
我想，对于力于阐明软件项目和建筑项目相似的朋友，
主要还是想把一些用于建筑的好的东西引入软件，
或者说，大家可以借鉴建筑领域的东西来进行软件开发，
我想到了软件模式，
其实说白了，三人行必有我师，
对于不同的领域，到了高处，很多东西也都是可以相互借鉴的吧。
#37
软件的构架与设计模式的关系如何？
#38
To gg007(赵gg):
软件的架构设计有一些规律可循，有经验的人经过综合，发现了一些模式。这些模式称作架构模式，它们都是架构设计的范例。
软件模式可以分成架构模式、设计模式和代码模式，它们的尺度不同。
一般地讲，软件架构与设计模式没什么关系。有关系的是架构模式。
软件的架构设计有一些规律可循，有经验的人经过综合，发现了一些模式。这些模式称作架构模式，它们都是架构设计的范例。
软件模式可以分成架构模式、设计模式和代码模式，它们的尺度不同。
一般地讲，软件架构与设计模式没什么关系。有关系的是架构模式。
#39
swinging(山不在高)说：想把一些用于建筑的好的东西引入软件
这已经在发生了，只是大部分人没有察觉而已。软件架构设计有一个Layers模式（分层模式），这本就来自于建筑学，参见
参考文献
[BRAND94]Stewart Brand，How Buildings Learn: What Happens After They're Built, Viking, 1994（呵呵，那时候UML在哪里，设计模式在那里？）
那里对Layers模式的描述比我见过的所有软件著作都精辟得多。
这已经在发生了，只是大部分人没有察觉而已。软件架构设计有一个Layers模式（分层模式），这本就来自于建筑学，参见
参考文献
[BRAND94]Stewart Brand，How Buildings Learn: What Happens After They're Built, Viking, 1994（呵呵，那时候UML在哪里，设计模式在那里？）
那里对Layers模式的描述比我见过的所有软件著作都精辟得多。
#40
开了一个讨论架构的话题，没有人理我，放到这里，请大家看看
在总结前人的基础上给出了整体描述一个系统的7个架构
应用架构：从使用视角看架构。系统实现的功能，以及各功能模块间的关系。
业务架构：业务模型，流程模型，组织模型等企业本身
信息架构：企业的信息系统规划
体系架构：三层或N层体系
系统架构: 软硬件部署
安全架构：安全了
软件架构：此部分主要描述各个应用软件间的关系结构，如数据库，was，portal等
在用这个架构去描述一个大系统的时候感觉非常清楚，
其中信息架构，我给出的说明实际上是信息系统架构，有没有对信息架构专门有研究的同行详细说明一下，对信息架构还是不很把握
在总结前人的基础上给出了整体描述一个系统的7个架构
应用架构：从使用视角看架构。系统实现的功能，以及各功能模块间的关系。
业务架构：业务模型，流程模型，组织模型等企业本身
信息架构：企业的信息系统规划
体系架构：三层或N层体系
系统架构: 软硬件部署
安全架构：安全了
软件架构：此部分主要描述各个应用软件间的关系结构，如数据库，was，portal等
在用这个架构去描述一个大系统的时候感觉非常清楚，
其中信息架构，我给出的说明实际上是信息系统架构，有没有对信息架构专门有研究的同行详细说明一下，对信息架构还是不很把握
#41
好！好！好！
学习！
学习！
#42
建筑构架：门、窗、墙（柱）、顶（梁）、基、梯（如多层），任你千变万化，管他怎么用途。
车构架：*、驱动器、轮驱连接器，任你千变万化，管他怎么用途。
软件构架：？？？？？？？任你千变万化，管他怎么用途。
车构架：*、驱动器、轮驱连接器，任你千变万化，管他怎么用途。
软件构架：？？？？？？？任你千变万化，管他怎么用途。
#43
支持！
#44
个人觉得软件架构设计目的是为了能符合人思维模式。
软件架构能从比较高层次来抽象模型。使人有个总体的概念。就如同书目录一样，勾画出主题，把握方向。相对于底层复杂模型而言，人更易接受简单和全局的东西。而对于软件架构分类如应用架构，信息架构......那是思维和应用的多样化（把它们分类了，可能更加容易理解）对于复杂的东西，我们希望抽象，分解他们，变成我们容易理解的东东。
这几天在看设计模式（elements of reusable oo software）和doctor yan
（jeffyan77(jeffyan77)）的java 和模式。虽然不是很明白具体模式，其实说实在的，我也没有打算都明白每个模式，但是我觉得收益非浅。OO把问题域与解域的距离拉近，oo解决问题的思维与我们的思维模式相近。而设计模式可以说是许许多多软件应用领域设计思维的一种抽象。细细品，还真是那个味。
谈谈建筑和软件关系。我觉得没有必要牵扯太多。软件和建筑有许多相近的东西。只是思维的一种碰撞。但可以借助建筑学的东西来理解软件领域的内容，同样软件的发展是极其快的，（是时尚？活力？）也会影响建筑业的！
//（注释）在众多高手面前，瞎说！
软件架构能从比较高层次来抽象模型。使人有个总体的概念。就如同书目录一样，勾画出主题，把握方向。相对于底层复杂模型而言，人更易接受简单和全局的东西。而对于软件架构分类如应用架构，信息架构......那是思维和应用的多样化（把它们分类了，可能更加容易理解）对于复杂的东西，我们希望抽象，分解他们，变成我们容易理解的东东。
这几天在看设计模式（elements of reusable oo software）和doctor yan
（jeffyan77(jeffyan77)）的java 和模式。虽然不是很明白具体模式，其实说实在的，我也没有打算都明白每个模式，但是我觉得收益非浅。OO把问题域与解域的距离拉近，oo解决问题的思维与我们的思维模式相近。而设计模式可以说是许许多多软件应用领域设计思维的一种抽象。细细品，还真是那个味。
谈谈建筑和软件关系。我觉得没有必要牵扯太多。软件和建筑有许多相近的东西。只是思维的一种碰撞。但可以借助建筑学的东西来理解软件领域的内容，同样软件的发展是极其快的，（是时尚？活力？）也会影响建筑业的！
//（注释）在众多高手面前，瞎说！
#45
如何架构你的构架？我想这里有两个方面的讨论：
1、构架是个什么样子？它有什么基本特征？基本概念？作用是什么？构架应该是个目标、是个结果，最后以图纸的形式表现。
2、架构属于设计的方面，有什么方法？模式？用到什么工具？
我想构架的基本特征应该是一样的，只是通过你的架构，可以有不同的表现形式，就如同建筑：可以是钢结构、木结构、石结构等（这样说可能也不准确）。
而架构也应该有基本的方法、步骤等。
1、构架是个什么样子？它有什么基本特征？基本概念？作用是什么？构架应该是个目标、是个结果，最后以图纸的形式表现。
2、架构属于设计的方面，有什么方法？模式？用到什么工具？
我想构架的基本特征应该是一样的，只是通过你的架构，可以有不同的表现形式，就如同建筑：可以是钢结构、木结构、石结构等（这样说可能也不准确）。
而架构也应该有基本的方法、步骤等。
#46
具体的提出一个案例，看各位如何来运用上面所说的理论来分析，并提出方案：
本公司有5个办事处，总部有四十号人，其他四个分部各有五号人，都安装了宽带。因为从事物流行业，所以对于数据要求集中，格式要求严格，各办事处均需要报表打印的功能，有一定的安全措施，还有成本低（主要指硬件），希望系统的扩展性高，即不管谁负责系统，都能方便地增加或删除其中的功能。
向各位讨教，如何用理论来解决实际问题！
本公司有5个办事处，总部有四十号人，其他四个分部各有五号人，都安装了宽带。因为从事物流行业，所以对于数据要求集中，格式要求严格，各办事处均需要报表打印的功能，有一定的安全措施，还有成本低（主要指硬件），希望系统的扩展性高，即不管谁负责系统，都能方便地增加或删除其中的功能。
向各位讨教，如何用理论来解决实际问题！
#47
to jeffyan77(jeffyan77):
系统架构是不是系统分析师们的一部分工作？
系统架构是不是系统分析师们的一部分工作？
#1
To walkcamel (虫子):
俺对构架没基础没概念
拜托介绍本好书先
搬个凳子
坐第一排
听课
俺对构架没基础没概念
拜托介绍本好书先
搬个凳子
坐第一排
听课
#2
很不错的，关注并支持！
#3
To zhuma(竹马):
《软件构架实践》
《软件构架实践》
#4
人说：“系统要求有良好的可扩展性和可更改性。”，women
换句话说，就是Time-friendly。和User-friendly相类似，只是要对时间友好。换句话说，在软件需求随着时间流逝发生变化的时候，系统可以进化。
软件工业的历史很短，从196*年算起，只有不到50年的时间。但是建筑设计行业少说也有几千年了，从金字塔的年代开始算的话。如果我们把历史遗留下来的建筑物进行比较的话，会发现有一些规律（为避免麻烦，考察的都是外国建筑，特此声明）。我打算大体上把他们分成三类：
（1）宗教建筑。永不进化。这类建筑从设计的时刻开始，就是要给人一种永恒的感觉，所以是绝对不打算进化甚至改作他用的。只是时间不饶人，现在大多只有一种用途：吸引游客。
3000年前的古埃及的法老Akhnaten曾经一度废止了古埃及的宗教，改信太阳教，宣告自己和皇后Nefertiti为神。那个时候做的第一件事，就是放弃沿袭了几百年的都城，在沙漠中另立新都。老的都城指以老的宗教为中心建立的，新的都城则以新的宗教信仰为中心建立。
当Akhnaten病死，Nefertiti被暗杀，埃及恢复老的宗教之后，第一件事业就是放弃新的都城，回到老都城。
在美国随处可见的天主教堂是另一个例子。前一阵子有一个天主教神职人员涉及猥亵幼童，教会被告，教堂破产。当时面临的一个问题，就是如何拍卖教堂资产，主要就是教堂。可是谁会买一座教堂？比如你是开餐馆的，开杂货铺的，开旅馆的，你买一个教堂干什么？那个教堂的样子和结构是特
由此可见，宗教建筑师以永恒为目标的。
我说的宗教建筑在近代包括了很多准宗教性建筑，比如美国的越战纪念碑，林肯纪念堂等。这些建筑根本就没打算改为其他用途，也根本没法改为其他用途。
（2）*建筑。所有的*建筑都是如同宗教建筑一样，打出一个永不变化的旗号，
换句话说，就是Time-friendly。和User-friendly相类似，只是要对时间友好。换句话说，在软件需求随着时间流逝发生变化的时候，系统可以进化。
软件工业的历史很短，从196*年算起，只有不到50年的时间。但是建筑设计行业少说也有几千年了，从金字塔的年代开始算的话。如果我们把历史遗留下来的建筑物进行比较的话，会发现有一些规律（为避免麻烦，考察的都是外国建筑，特此声明）。我打算大体上把他们分成三类：
（1）宗教建筑。永不进化。这类建筑从设计的时刻开始，就是要给人一种永恒的感觉，所以是绝对不打算进化甚至改作他用的。只是时间不饶人，现在大多只有一种用途：吸引游客。
3000年前的古埃及的法老Akhnaten曾经一度废止了古埃及的宗教，改信太阳教，宣告自己和皇后Nefertiti为神。那个时候做的第一件事，就是放弃沿袭了几百年的都城，在沙漠中另立新都。老的都城指以老的宗教为中心建立的，新的都城则以新的宗教信仰为中心建立。
当Akhnaten病死，Nefertiti被暗杀，埃及恢复老的宗教之后，第一件事业就是放弃新的都城，回到老都城。
在美国随处可见的天主教堂是另一个例子。前一阵子有一个天主教神职人员涉及猥亵幼童，教会被告，教堂破产。当时面临的一个问题，就是如何拍卖教堂资产，主要就是教堂。可是谁会买一座教堂？比如你是开餐馆的，开杂货铺的，开旅馆的，你买一个教堂干什么？那个教堂的样子和结构是特
由此可见，宗教建筑师以永恒为目标的。
我说的宗教建筑在近代包括了很多准宗教性建筑，比如美国的越战纪念碑，林肯纪念堂等。这些建筑根本就没打算改为其他用途，也根本没法改为其他用途。
（2）*建筑。所有的*建筑都是如同宗教建筑一样，打出一个永不变化的旗号，
#5
好帖子。
#6
人说：“系统要求有良好的可扩展性和可更改性。”
换句话说，就是Time-friendly。和User-friendly相类似，只是要对时间友好。换句话说，在软件需求随着时间流逝发生变化的时候，系统可以进化。
软件工业的历史很短，从196*年算起，只有不到50年的时间。但是建筑设计行业少说也有五千年了，从金字塔的年代开始算的话。如果我们把历史遗留下来的建筑物进行比较的话，会发现有一些规律（为避免麻烦，考察的都是外国建筑，特此声明）。我打算大体上把他们分成三类：
（1）宗教建筑。永不进化。这类建筑从设计的时刻开始，就是要给人一种永恒的感觉，所以是绝对不打算进化甚至改作他用的。只是时间不饶人，现在大多只有一种用途：吸引游客，就跟搬进博物馆一样。
3000年前的古埃及的法老Akhnaten曾经一度废止了古埃及的宗教，改信太阳教，宣告自己和皇后Nefertiti为神。那个时候做的第一件事，就是放弃沿袭了几百年的都城，在沙漠中另立新都。老的都城指以老的宗教为中心建立的，新的都城则以新的宗教信仰为中心建立。
当Akhnaten病死，Nefertiti被暗杀，埃及恢复老的宗教之后，第一件事就是放弃新都城，回到老都城。
在美国随处可见的天主教堂是另一个例子。前一阵子有一个天主教神职人员涉及猥亵幼童，教会被告，教堂破产。当时面临的一个问题，就是如何拍卖教堂资产，主要就是教堂建筑。可是谁会买一座教堂？比如你是开餐馆的，开杂货铺的，开旅馆的，你买一个教堂干什么？那个教堂的样子和结构是特别为教堂设计的，根本干不了别的用途。
由此可见，宗教建筑师以永恒为目标的，不具备Time-friendliness。
我说的宗教建筑在近代包括了很多准宗教性建筑，比如美国的越战纪念碑，林肯纪念堂等。这些建筑根本就没打算改为其他用途，也根本没法改为其他用途。
（2）*建筑。所有的*建筑都如同宗教建筑一样，打出一个永不变化的旗号，但是它们总是在变化。你如果到过曼哈顿、纽约州首府Albany就会发现，建筑物不能说不雄伟，但是很不实用。特别是很多建筑已经几十年甚至一百年，里面的结构不能适应今天的需要，但是很难改变，因为当时的设计就是以不变为目标的。如果你到里面看一看的话，就会发现在那种建筑物里面工作是多么的痛苦，死建筑让活人受罪。
换言之，这种建筑物应当具备Time-friendliness，但是很遗憾，往往并不具备。
（3）住宅。这种建筑物变化缓慢，我的同事住在一座已经有一百年历史的石头楼房里面，除了佣人房间已改为他用，卫生间太小、厨房太小不合时宜之外，并没有明显的不便。
（4）商业建筑。这种建筑物变化最为迅速，从结构到内部各种服务设施，到建筑物外表，都以几年为周期迅速变化。
在华尔街上走一走就会发现，这个寸土寸金的金融中心，居然有豪华公寓散落其中。而这些公寓看上去和办公楼没有两样。这是为什么呢？原因很简单：这些建筑物本来就是办公楼，但是因为内部服务性的设施没有办法跟上时代的需求，建筑物已经无法继续作为办公楼使用。比如电梯间太小，而且房屋结构很难改造，电梯间也无法扩大，大量电脑通讯管线无法铺设等等原因，没有公司愿意租这样的楼。使得物主只好另寻其他办法，而改为住宅不失为一个好主意。
实际上，从八十年代开始的IT革命所带来的大量电脑管线淘汰了大批老旧的建筑物。大部分的办公楼只好推倒重来，像华尔街的那几座幸存者那么幸运的只是极少数。
没人能够预见将来，一百年前的物主没办法对建筑设计师说，请留出更多的空间给电梯，或者留出更多的空间给电脑管线，或者告诉设计师，说几十年后的住户将不需要佣人了，他们将需要把用人房改为他用，他们也没有办法预见到厨房、卫生间太小的问题。
软件设计与建筑物设计有惊人的相似之处，只是软件的淘汰比建筑物更快。客户没有办法对软件架构师说，请你给我留出一些可以向…方向上的扩展余地。
客户能要求的，其实就是软件的Time-friendliness。而这个问题难道不是最为困难的么？
换句话说，就是Time-friendly。和User-friendly相类似，只是要对时间友好。换句话说，在软件需求随着时间流逝发生变化的时候，系统可以进化。
软件工业的历史很短，从196*年算起，只有不到50年的时间。但是建筑设计行业少说也有五千年了，从金字塔的年代开始算的话。如果我们把历史遗留下来的建筑物进行比较的话，会发现有一些规律（为避免麻烦，考察的都是外国建筑，特此声明）。我打算大体上把他们分成三类：
（1）宗教建筑。永不进化。这类建筑从设计的时刻开始，就是要给人一种永恒的感觉，所以是绝对不打算进化甚至改作他用的。只是时间不饶人，现在大多只有一种用途：吸引游客，就跟搬进博物馆一样。
3000年前的古埃及的法老Akhnaten曾经一度废止了古埃及的宗教，改信太阳教，宣告自己和皇后Nefertiti为神。那个时候做的第一件事，就是放弃沿袭了几百年的都城，在沙漠中另立新都。老的都城指以老的宗教为中心建立的，新的都城则以新的宗教信仰为中心建立。
当Akhnaten病死，Nefertiti被暗杀，埃及恢复老的宗教之后，第一件事就是放弃新都城，回到老都城。
在美国随处可见的天主教堂是另一个例子。前一阵子有一个天主教神职人员涉及猥亵幼童，教会被告，教堂破产。当时面临的一个问题，就是如何拍卖教堂资产，主要就是教堂建筑。可是谁会买一座教堂？比如你是开餐馆的，开杂货铺的，开旅馆的，你买一个教堂干什么？那个教堂的样子和结构是特别为教堂设计的，根本干不了别的用途。
由此可见，宗教建筑师以永恒为目标的，不具备Time-friendliness。
我说的宗教建筑在近代包括了很多准宗教性建筑，比如美国的越战纪念碑，林肯纪念堂等。这些建筑根本就没打算改为其他用途，也根本没法改为其他用途。
（2）*建筑。所有的*建筑都如同宗教建筑一样，打出一个永不变化的旗号，但是它们总是在变化。你如果到过曼哈顿、纽约州首府Albany就会发现，建筑物不能说不雄伟，但是很不实用。特别是很多建筑已经几十年甚至一百年，里面的结构不能适应今天的需要，但是很难改变，因为当时的设计就是以不变为目标的。如果你到里面看一看的话，就会发现在那种建筑物里面工作是多么的痛苦，死建筑让活人受罪。
换言之，这种建筑物应当具备Time-friendliness，但是很遗憾，往往并不具备。
（3）住宅。这种建筑物变化缓慢，我的同事住在一座已经有一百年历史的石头楼房里面，除了佣人房间已改为他用，卫生间太小、厨房太小不合时宜之外，并没有明显的不便。
（4）商业建筑。这种建筑物变化最为迅速，从结构到内部各种服务设施，到建筑物外表，都以几年为周期迅速变化。
在华尔街上走一走就会发现，这个寸土寸金的金融中心，居然有豪华公寓散落其中。而这些公寓看上去和办公楼没有两样。这是为什么呢？原因很简单：这些建筑物本来就是办公楼，但是因为内部服务性的设施没有办法跟上时代的需求，建筑物已经无法继续作为办公楼使用。比如电梯间太小，而且房屋结构很难改造，电梯间也无法扩大，大量电脑通讯管线无法铺设等等原因，没有公司愿意租这样的楼。使得物主只好另寻其他办法，而改为住宅不失为一个好主意。
实际上，从八十年代开始的IT革命所带来的大量电脑管线淘汰了大批老旧的建筑物。大部分的办公楼只好推倒重来，像华尔街的那几座幸存者那么幸运的只是极少数。
没人能够预见将来，一百年前的物主没办法对建筑设计师说，请留出更多的空间给电梯，或者留出更多的空间给电脑管线，或者告诉设计师，说几十年后的住户将不需要佣人了，他们将需要把用人房改为他用，他们也没有办法预见到厨房、卫生间太小的问题。
软件设计与建筑物设计有惊人的相似之处，只是软件的淘汰比建筑物更快。客户没有办法对软件架构师说，请你给我留出一些可以向…方向上的扩展余地。
客户能要求的，其实就是软件的Time-friendliness。而这个问题难道不是最为困难的么？
#7
ting
#8
To walkcamel (虫子):
那是不是指
构架是对关键问题给出的清晰准确的回答？
而哪些问题是重要而又实际的呢？
To jeffyan77(jeffyan77):
Time-friendly
我喜欢这个词
出自哪本书？
那是不是指
构架是对关键问题给出的清晰准确的回答？
而哪些问题是重要而又实际的呢？
To jeffyan77(jeffyan77):
Time-friendly
我喜欢这个词
出自哪本书？
#9
拿建筑的观念和软件进行比较我个人觉得是软件工程研究犯的最大的错误，恰恰相反，现代的软件开发环境领先于建筑，发展的趋势是建筑设计变得越来越像软件而不是相反。架构只要知道分层就可以了，就足以解决任何的问题了，除非为了研究而不是制作软件。
#10
这些个大哥说了这么多等于什么都没说！楼下的，你认为呢？
#11
好文 跟进 我顶ing
#12
zhuma(竹马) :
构架是对关键问题给出的清晰准确的回答？
是的
而哪些问题是重要而又实际的呢？
没有统一的标准，不同类型的系统有不同的要求，有经验的工程师可能会根据他的过往经验给予你一些忠告，可我目前还只是个学生：（。
去看看软件质量属性相关的内容，会告诉你一个软件一般具有什么样的特征。等你明白后，剩下的就是具体问题具体分析了。
例外在在SEI的站点上，有不少关于如何分析的文章，有空可以去看看。
构架是对关键问题给出的清晰准确的回答？
是的
而哪些问题是重要而又实际的呢？
没有统一的标准，不同类型的系统有不同的要求，有经验的工程师可能会根据他的过往经验给予你一些忠告，可我目前还只是个学生：（。
去看看软件质量属性相关的内容，会告诉你一个软件一般具有什么样的特征。等你明白后，剩下的就是具体问题具体分析了。
例外在在SEI的站点上，有不少关于如何分析的文章，有空可以去看看。
#13
to jeffyan77(jeffyan77):
Time-friendly这个概念很好，不过也诚如你说的，说起来简单，做起来难。另外我也想知道这些材料出于什么地方。
to lynxliu(lynx):
其实建筑师是我最先的梦想，不过本科的时候却进了土木结构专业（没有美术功底），呵呵。下过几次工地，对工地中的施工管理的印象比较深，各工种间的协调施工，并行施工，感觉安排的很有条理，而且有很过的国家规范，计算工期呀，人工呀还有材料什么的，一套用就好了，有些差距但也不是很多。后面开始学习计算机专业，总也是希望也有着相建筑那边那样的规范手册就好了，呵呵，希望以后会有的哦，而且在做受力分析的时候也还都有公式套用，多少钢筋，多少水泥，大家算出来看看都差不多，在这点上目前的软件工程还相差很远。
软件工程研究的并不只是构架的问题，还有过程管理的问题，建筑行业开始大量的采用软件来出来，并且有的地方用的很成功是因为背后有成熟的理论和大量的规范化成果出来。这也是软件的CASE工具没有大规模使用的原因之一吧。
Time-friendly这个概念很好，不过也诚如你说的，说起来简单，做起来难。另外我也想知道这些材料出于什么地方。
to lynxliu(lynx):
其实建筑师是我最先的梦想，不过本科的时候却进了土木结构专业（没有美术功底），呵呵。下过几次工地，对工地中的施工管理的印象比较深，各工种间的协调施工，并行施工，感觉安排的很有条理，而且有很过的国家规范，计算工期呀，人工呀还有材料什么的，一套用就好了，有些差距但也不是很多。后面开始学习计算机专业，总也是希望也有着相建筑那边那样的规范手册就好了，呵呵，希望以后会有的哦，而且在做受力分析的时候也还都有公式套用，多少钢筋，多少水泥，大家算出来看看都差不多，在这点上目前的软件工程还相差很远。
软件工程研究的并不只是构架的问题，还有过程管理的问题，建筑行业开始大量的采用软件来出来，并且有的地方用的很成功是因为背后有成熟的理论和大量的规范化成果出来。这也是软件的CASE工具没有大规模使用的原因之一吧。
#14
软件项目和建筑项目的区别在于需求的变更，建筑在需求确定以后基本就稳定了，而软件不同，需求总是在变的，所以架构的出现也只是为了解决需求不断变化的这个问题，但是一个好的架构是远远不够的，还有有良好的项目管理（包括计划控制、需求变更管理、开发过程的优化等）
#15
小楼一夜听春雨.
#16
to twinsant124(蚂蚁的天空):
You can type Chinese now?
You can type Chinese now?
#17
软件的构建确实与建筑有相似之处，但我认为软件所覆盖的范围要远远大于建筑，建筑尽管有各种类型，但用途大体相似，五千年来也没怎么变过，你会要求一栋房子给你放音乐吗？但人们对于软件的要求却是多种多样的，软件无处不在，它帮你打电话，跟你玩游戏，还管着你的钱，股票……软件是一个广泛的东西，它会以各种形式存在，这就是为什么软件开发那么难的原因。
出于软件的这种特点，软件不可能有一个通用的建造方法，也不可能存在一个完全通用的软件架构的，因为它不可能满足所有人的需求，我的看法是应该对于软件这个行业进行进一步的细分，再针对细分的行业建立起相对稳定的架构，建立相应的制造流程，才谈得上项目管理的方法等等。构架的原则也需要首先建立在你的具体应用的特点上。
出于软件的这种特点，软件不可能有一个通用的建造方法，也不可能存在一个完全通用的软件架构的，因为它不可能满足所有人的需求，我的看法是应该对于软件这个行业进行进一步的细分，再针对细分的行业建立起相对稳定的架构，建立相应的制造流程，才谈得上项目管理的方法等等。构架的原则也需要首先建立在你的具体应用的特点上。
#18
to lynxliu(lynx):
在某种编程语言中实现统一个确定的功能，这算是一个有“硬指标”的问题吧？十个程序员写出的代码就可能有十种。
我曾经教过一个十二个人的班学习一门高级编程课，最后给出的课后作业是一个小型项目的设计。你猜怎么着？我收到了十三份答案。原来其中一位同学缴了两份不同的设计。
更何况软件设计这样一个没有确定“硬指标”的问题，本来就是见仁见智的事情，基本上谈不上对错。如果你说某种看法就是错的，就需要讲讲理由。如果你说这不仅是错的，而且是“软件工程研究犯的最大的错误”，这“最大”又从何而来，总的说明一下吧，呵呵？
在某种编程语言中实现统一个确定的功能，这算是一个有“硬指标”的问题吧？十个程序员写出的代码就可能有十种。
我曾经教过一个十二个人的班学习一门高级编程课，最后给出的课后作业是一个小型项目的设计。你猜怎么着？我收到了十三份答案。原来其中一位同学缴了两份不同的设计。
更何况软件设计这样一个没有确定“硬指标”的问题，本来就是见仁见智的事情，基本上谈不上对错。如果你说某种看法就是错的，就需要讲讲理由。如果你说这不仅是错的，而且是“软件工程研究犯的最大的错误”，这“最大”又从何而来，总的说明一下吧，呵呵？
#19
windancery(Java的真实拥护者!) 说“建筑在需求确定以后基本就稳定了”
不是，呵呵。近代中国变化剧烈，可能不易分辨建筑物在建成之后需求的变化和环境因素的变化。
在美国这个地方社会环境非常稳定，建筑业成熟的很早，大规模的建筑作业早就已经完成，在很多城市很少看到新的房子。建筑物常常建成后连续使用超过50年，甚至超过百年。这使得一些建筑设计师得以研究建筑物在建好之后发生了什么，是因为什么使得建筑物不断被整修、改造、最后被推倒重来的。
他们的结论是建筑物很少是因为濒于倒塌或者其他严重结构破损而被放弃的。相反，大多数的建筑物是因为无法满足物主的需求而被放弃的，这些房屋在被放弃的时候仍然是非常结实的建筑，根本没有结构损伤，正常使用的话，完全可以再持续200年到300年。
有一些设计师把老的建筑物照片找出来，从而可以清晰地看到十年后、二十年后、...，两栋一模一样、同时建造的房子，在建好之后放生了什么。
另有一些建筑师把Boston街区的照片找出来，研究这些建筑物是如何随着时间演变的。著名建筑学家Steward Brand说，好的建筑都是“为变化而建的”（Built for Change），从古至今，人类所建造的千千万万的建筑物，其成功与失败全在于是否能够适应需求的变化。英国皇家建筑学院院长Frank Duffy说，“我们的基本观点是根本就不存在‘一栋建筑’这样的概念。”为什么这样说呢？“一栋建筑”是一个固体的概念；而作为一个固体的建筑物并不存在，真正存在的是一个流体，它处在不断的流动和变化之中。
Time-friendly就是他们提出来的，我想把它借过来描述软件设计的类似问题。这也是我一直感兴趣的问题，就是需求曲线的一次导数曲线对软件设计的影响。我的基本观点是Design for Change，也就是“为变化而设计”。
一个类似的词汇是Timeless，由Alexander提出。我倾向于使用Time-friendly，因为。。。很简单，没有什么东西是永恒的。但是提出Time-friendly的建筑设计师Steward Brand实际上非常推崇Alexander，只是没有那么多的哲学思考而已。
参考文献
[BRAND94]Stewart Brand，How Buildings Learn: What Happens After They're Built, Viking, 1994（呵呵，那时候UML在哪里，设计模式在那里？）
不是，呵呵。近代中国变化剧烈，可能不易分辨建筑物在建成之后需求的变化和环境因素的变化。
在美国这个地方社会环境非常稳定，建筑业成熟的很早，大规模的建筑作业早就已经完成，在很多城市很少看到新的房子。建筑物常常建成后连续使用超过50年，甚至超过百年。这使得一些建筑设计师得以研究建筑物在建好之后发生了什么，是因为什么使得建筑物不断被整修、改造、最后被推倒重来的。
他们的结论是建筑物很少是因为濒于倒塌或者其他严重结构破损而被放弃的。相反，大多数的建筑物是因为无法满足物主的需求而被放弃的，这些房屋在被放弃的时候仍然是非常结实的建筑，根本没有结构损伤，正常使用的话，完全可以再持续200年到300年。
有一些设计师把老的建筑物照片找出来，从而可以清晰地看到十年后、二十年后、...，两栋一模一样、同时建造的房子，在建好之后放生了什么。
另有一些建筑师把Boston街区的照片找出来，研究这些建筑物是如何随着时间演变的。著名建筑学家Steward Brand说，好的建筑都是“为变化而建的”（Built for Change），从古至今，人类所建造的千千万万的建筑物，其成功与失败全在于是否能够适应需求的变化。英国皇家建筑学院院长Frank Duffy说，“我们的基本观点是根本就不存在‘一栋建筑’这样的概念。”为什么这样说呢？“一栋建筑”是一个固体的概念；而作为一个固体的建筑物并不存在，真正存在的是一个流体，它处在不断的流动和变化之中。
Time-friendly就是他们提出来的，我想把它借过来描述软件设计的类似问题。这也是我一直感兴趣的问题，就是需求曲线的一次导数曲线对软件设计的影响。我的基本观点是Design for Change，也就是“为变化而设计”。
一个类似的词汇是Timeless，由Alexander提出。我倾向于使用Time-friendly，因为。。。很简单，没有什么东西是永恒的。但是提出Time-friendly的建筑设计师Steward Brand实际上非常推崇Alexander，只是没有那么多的哲学思考而已。
参考文献
[BRAND94]Stewart Brand，How Buildings Learn: What Happens After They're Built, Viking, 1994（呵呵，那时候UML在哪里，设计模式在那里？）
#20
To fita(天外飞仙):
即便是建筑，也有住宅用房、商业用房、桥梁、公路等等很多种类，一点都不比软件逊色。
卡尔.马克思在《资本论》中说，蜘蛛的活动与织工的活动相似，蜜蜂建筑蜂房的本领使人间的许多建筑师感到惭愧。但是，最蹩脚的建筑师从一开始就比最灵巧的蜜蜂高明，因为他在建造真实建筑物以前，已经在自己的头脑中把它的结构建好了。
人造的所有工具不都是这样的吗？
在人造工具中，以建筑物为最早、最经久耐用，以软件为最新和最抽象。不同的人造工具有不同的功能（function），但是所有的人造工具都有同样的根本属性，就是它们必须满足人的需求。从这个角度上看，软件和建筑物、随身听、板凳桌椅并无本质区别。
参考文献
[MARX]Karl Marx,《资本论》（第一卷），中国社会科学出版社，1983年1月第一版。（大学毕业时同学扔下的，我一直带着，直到纽约，呵呵）
即便是建筑，也有住宅用房、商业用房、桥梁、公路等等很多种类，一点都不比软件逊色。
卡尔.马克思在《资本论》中说，蜘蛛的活动与织工的活动相似，蜜蜂建筑蜂房的本领使人间的许多建筑师感到惭愧。但是，最蹩脚的建筑师从一开始就比最灵巧的蜜蜂高明，因为他在建造真实建筑物以前，已经在自己的头脑中把它的结构建好了。
人造的所有工具不都是这样的吗？
在人造工具中，以建筑物为最早、最经久耐用，以软件为最新和最抽象。不同的人造工具有不同的功能（function），但是所有的人造工具都有同样的根本属性，就是它们必须满足人的需求。从这个角度上看，软件和建筑物、随身听、板凳桌椅并无本质区别。
参考文献
[MARX]Karl Marx,《资本论》（第一卷），中国社会科学出版社，1983年1月第一版。（大学毕业时同学扔下的，我一直带着，直到纽约，呵呵）
#21
又看了一遍，还是只看到一堆人在说废话。。。。。。
拜托，下次取帖子的名字是注意一点。所谓“构架思考（3）-构架的原则”？？？？？？？
拜托，下次取帖子的名字是注意一点。所谓“构架思考（3）-构架的原则”？？？？？？？
#22
确实写的不错！！！
再接再厉!!!
再接再厉!!!
#23
fita(天外飞仙)说的对极了，其实道理原本不难理解，其实建筑和软件的差别很大。能够和软件对比的是整个的制造工业，你不会要求制造工业有一个统一的制造规范吧。现在的软件工业把生产化妆品的人和生产拖拉机的人一视同仁，呵呵，还要什么统一的架构，标准，岂不是滑稽。其实，任何的逻辑都是可以软件化，也可以进一步硬件化的。使用不同的手段进行实现是因为那样作有利。所以，谈好的软件设计首先就要知道它为什么需要做成软件，为什么适合做成软件，为什么可以做成软件，没有这样的理解，只能是看看手里有什么，然后就开始做，和用锤子做汽车没什么不同。
不多说了，jeffyan77(jeffyan77)写的书把模式和哲学牵扯在一起有点类似把软件和建筑来比，看到了一点相似的地方，却不能够很好的说明问题。这也是我曾经提出过的。其实SA重要的能力就是对于系统进行恰当的对比，如何才能恰当则取决于SA本人的修养和能力了。
我和walkcamel(虫子)一样，曾经梦想做一名建筑师，大学学习城市规划，可惜后来也转向了软件，不过我仍然非常关注新的建筑。总体的感觉是建筑在向软件的方向发展，重视创造力，在满足力学需要的基础之上，满足人们的多重需求。整个发展是技术导向的，而不是什么管理，现有技术突破，后有技术应用，最后是管理规范。这就摆脱了重复的制造。所以，我觉得不是建筑向软件学习而是相反，所有的制造工业向IT行业学习，建立更加人性化的产品而不是功能化的产品。同时，建筑业也日益脱离劳动密集的价值模式，转移到智力密集的模式，从需求开始进行，这和软件又有何不同？模式，UML等等都提到了建筑，模式这样的词汇据说也是建筑师发明的，但是软件其实也在向其他的传统行业学习，这枚什么奇怪的。奇怪的是很多人非要软件的生产模式和建筑类似，比如发明软件蓝领这样的概念，不是说这样的说法肯定不对，而是指望这样就可以成为软件强国是不可能的，不符合软件发展的实际需要。这是我说用建筑来比软件是软件工程最大失败的原因。
又说了一大堆废话，呵呵，其实无论什么方法，客户满意，产品有市场才是最重要的。技术，管理都是为此服务的。结构化设计没什么不好，OO不正确的理解和使用的时候引起的问题更多，CBD，GP都是各有特点的方法，这些共同丰富了软件技术，却不是应该互相取代的。就像属于爬行动物的蛇可以吃掉哺乳动物一样，只要适应商业环境，技术就会存在和发展，反之才会淘汰。所以，掌握自己手里的技术，发挥它的长处，找一个适合的环境是我们首先需要考虑的。
不多说了，jeffyan77(jeffyan77)写的书把模式和哲学牵扯在一起有点类似把软件和建筑来比，看到了一点相似的地方，却不能够很好的说明问题。这也是我曾经提出过的。其实SA重要的能力就是对于系统进行恰当的对比，如何才能恰当则取决于SA本人的修养和能力了。
我和walkcamel(虫子)一样，曾经梦想做一名建筑师，大学学习城市规划，可惜后来也转向了软件，不过我仍然非常关注新的建筑。总体的感觉是建筑在向软件的方向发展，重视创造力，在满足力学需要的基础之上，满足人们的多重需求。整个发展是技术导向的，而不是什么管理，现有技术突破，后有技术应用，最后是管理规范。这就摆脱了重复的制造。所以，我觉得不是建筑向软件学习而是相反，所有的制造工业向IT行业学习，建立更加人性化的产品而不是功能化的产品。同时，建筑业也日益脱离劳动密集的价值模式，转移到智力密集的模式，从需求开始进行，这和软件又有何不同？模式，UML等等都提到了建筑，模式这样的词汇据说也是建筑师发明的，但是软件其实也在向其他的传统行业学习，这枚什么奇怪的。奇怪的是很多人非要软件的生产模式和建筑类似，比如发明软件蓝领这样的概念，不是说这样的说法肯定不对，而是指望这样就可以成为软件强国是不可能的，不符合软件发展的实际需要。这是我说用建筑来比软件是软件工程最大失败的原因。
又说了一大堆废话，呵呵，其实无论什么方法，客户满意，产品有市场才是最重要的。技术，管理都是为此服务的。结构化设计没什么不好，OO不正确的理解和使用的时候引起的问题更多，CBD，GP都是各有特点的方法，这些共同丰富了软件技术，却不是应该互相取代的。就像属于爬行动物的蛇可以吃掉哺乳动物一样，只要适应商业环境，技术就会存在和发展，反之才会淘汰。所以，掌握自己手里的技术，发挥它的长处，找一个适合的环境是我们首先需要考虑的。
#24
to:fita(天外飞仙):
关于构架分类的方法，在国外已经有人进行，而且已经有相当的成果了。很多的参考技术构架都上属于这范围的。不过目前国内这方面的工作比较少，也许有一些吧，也都当做公司的机密不发布的。
关于构架分类的方法，在国外已经有人进行，而且已经有相当的成果了。很多的参考技术构架都上属于这范围的。不过目前国内这方面的工作比较少，也许有一些吧，也都当做公司的机密不发布的。
#25
to samgol(堕落之洲)
这就是你的思考？
这就是你的思考？
#26
mark
#27
其实，我相信看待软件工程本身也有不同的角度。比方说，是做软件工程研究的，还是软件商业开发的。前者追求的是更为完美的形式，而后者呢，追求的是利润，而且很有可能是短期的利润。在这样的环境差别下，对于架构就会有不同的形式。就像建筑，村屋也是一种架构，它解决的是另一种问题，而大厦解决的就是另外一个问题了。所以我认为软件架构的问题应该是具体环境具体分析，只有当软件工程像建筑一样发展了几千年以后，也许就会趋于大的统一了吧。在下愚见，只想抛砖引玉。
#28
对于软件的构造,我来谈几句.
在经历了数个软件项目之后,我发现包括自己在内,都曾说过太多次数的一句:客户无法准确地提出需求来.这就让我们的工程进度一拖再拖,甚至到最后双方无法忍受而放弃了.我们再来看看建筑方法的:不论是商业建筑还是住宅,请问最终用户提出过需求吗?这里就存在一个明显的不同之处,建筑不是最终用户在提需求,而是中间服务商在提需求.
我在想,如果软件工程也采用这种思路,即最终客户并不是直接找软件公司来构建他自己的软件系统,而是找软件服务公司(与现在的管理咨询公司有些相同的功能,但内涵更深)来为其提供最恰当的系统.对软件开发公司,提需求的不再是客户,而是咨询服务公司.那么无论是从专业的深度,还是业务领域的精通,我想咨询公司都要比我们现在面对的最终客户要准确\恰当得多.我们构建的系统也将会如建筑一样,在局部调整时不会伤筋动骨了.
在经历了数个软件项目之后,我发现包括自己在内,都曾说过太多次数的一句:客户无法准确地提出需求来.这就让我们的工程进度一拖再拖,甚至到最后双方无法忍受而放弃了.我们再来看看建筑方法的:不论是商业建筑还是住宅,请问最终用户提出过需求吗?这里就存在一个明显的不同之处,建筑不是最终用户在提需求,而是中间服务商在提需求.
我在想,如果软件工程也采用这种思路,即最终客户并不是直接找软件公司来构建他自己的软件系统,而是找软件服务公司(与现在的管理咨询公司有些相同的功能,但内涵更深)来为其提供最恰当的系统.对软件开发公司,提需求的不再是客户,而是咨询服务公司.那么无论是从专业的深度,还是业务领域的精通,我想咨询公司都要比我们现在面对的最终客户要准确\恰当得多.我们构建的系统也将会如建筑一样,在局部调整时不会伤筋动骨了.
#29
软件服务公司
menliwxj(有缘)的观点很有意思
menliwxj(有缘)的观点很有意思
#30
但是它应该存在于哪种类型的软件中呢？
消费类？
企业类？
专业类？
都挺难切入的
希望 menliwxj(有缘) 进一步阐述
消费类？
企业类？
专业类？
都挺难切入的
希望 menliwxj(有缘) 进一步阐述
#31
zhuma(竹马):
我自己一直从事的企业类的软件系统设计,因此出发点主要是从企业类的信息管理角度出发来考虑的.至于如电信等领域我就不太清楚了.我的这个想法也是刚才在看了上面各位的讨论之后想到的.目前还无法更进一步地陈述.
我自己一直从事的企业类的软件系统设计,因此出发点主要是从企业类的信息管理角度出发来考虑的.至于如电信等领域我就不太清楚了.我的这个想法也是刚才在看了上面各位的讨论之后想到的.目前还无法更进一步地陈述.
#32
Menliwxj的想法很正常，而且现在也出现了这样的公司。我想menliwxj碰到的问题在于：可能企业本身的IT人员能力不强，或者企业政治的因素影响了系统的进展。所以对于大型的系统来说，可能面临的不仅仅是技术的问题，还有管理的问题，公关的问题，企业文化的问题。所以技术人员会感觉很无助。如何根本地解决这种现状呢？我认为，只有更多的技术人员进入核心管理层以后，整个软件业的发展才会有更大的提高。这就需要兄弟姐妹们多努力，成为“又红又专”的精英！
#33
一、人们不要求房子能放音乐……就象人们不要求作图软件能处理音乐。如果你说未来的智能化建筑其实也可以要求房子放音乐，那么，房子其实还是不能音乐，这其实是一个系统集成的问题，就象作图软件里可以处理音乐一样。…这由需求推动，但需求是分层次的，前一个需求没有达成时，后面的需求不会提出，或者不会表现得太过迫切，诚如：饱暖思淫欲…
二、对于软件和建筑的差别，其很大一个原因是来自于人这个物种自身的渺小，人的生命太短，假如从遮风避雨到智能通讯这个需求变化过程在一个月之内经历，那你会发现建筑和软件有更多的相似，——其实不只是建筑。再来一个其实吧……你看到现在的人住在一个古老的住房里，没有太多不便，就好象WORD升级到XP之后，写一句留言还是可以用“记事本”，这只是说明我做“留言”这件事时并无我办公时的需求，就好象住古老建筑的朋友最终还是得跑到写字楼去办公。死抱正版的人们还会出于成本考虑……去使用免费，这是另一话题。
二、对于软件和建筑的差别，其很大一个原因是来自于人这个物种自身的渺小，人的生命太短，假如从遮风避雨到智能通讯这个需求变化过程在一个月之内经历，那你会发现建筑和软件有更多的相似，——其实不只是建筑。再来一个其实吧……你看到现在的人住在一个古老的住房里，没有太多不便，就好象WORD升级到XP之后，写一句留言还是可以用“记事本”，这只是说明我做“留言”这件事时并无我办公时的需求，就好象住古老建筑的朋友最终还是得跑到写字楼去办公。死抱正版的人们还会出于成本考虑……去使用免费，这是另一话题。
#34
imafool的话反映了另外一个事实：建筑的需求变化速度要远远慢于软件的变化速度。
为什么会这样呢，我想也许是因为软件的制造比建筑的制造要容易得多，房子的设计很大程度上需要遵守自然规律，比如说承重结构等，人们对于房子的需求也是很大程度上受到这些限制的，提需求的人也接受了这一点，建筑的需求变化慢，自然建筑的建造方法、架构也能够保持相对稳定，管理起来也就容易得多。
与建筑相比，软件制造的限制要小得多，人们的需求实现得快，自然也就变化得快了（人真是一个不容易满足的动物）。jeffyan77提出的Time Friendly概念，我想对于软件来说，已经远远超出Friendly的要求了，也许应该说Timeless, 或Change Critically。
为什么会这样呢，我想也许是因为软件的制造比建筑的制造要容易得多，房子的设计很大程度上需要遵守自然规律，比如说承重结构等，人们对于房子的需求也是很大程度上受到这些限制的，提需求的人也接受了这一点，建筑的需求变化慢，自然建筑的建造方法、架构也能够保持相对稳定，管理起来也就容易得多。
与建筑相比，软件制造的限制要小得多，人们的需求实现得快，自然也就变化得快了（人真是一个不容易满足的动物）。jeffyan77提出的Time Friendly概念，我想对于软件来说，已经远远超出Friendly的要求了，也许应该说Timeless, 或Change Critically。
#35
各位楼上的思想都好深邃，我只能到‘明确需求，双方签字’，‘需求变动，掏钱’的层次，而不会去考虑time-friendly。看了你们的发言之后，就觉得你们追求的境界会更加有成就感，甚至‘使命感’。谢谢大家，我要向大家学习，要在工作的时候时时考虑这个问题。
#36
很深刻，
好像有点跑题，
我觉得，大家都不否认建筑业同软件业很有相同点，
结论是，软件业和建筑业很相似。
那么大家在讨论什么？
我想，对于力于阐明软件项目和建筑项目相似的朋友，
主要还是想把一些用于建筑的好的东西引入软件，
或者说，大家可以借鉴建筑领域的东西来进行软件开发，
我想到了软件模式，
其实说白了，三人行必有我师，
对于不同的领域，到了高处，很多东西也都是可以相互借鉴的吧。
好像有点跑题，
我觉得，大家都不否认建筑业同软件业很有相同点，
结论是，软件业和建筑业很相似。
那么大家在讨论什么？
我想，对于力于阐明软件项目和建筑项目相似的朋友，
主要还是想把一些用于建筑的好的东西引入软件，
或者说，大家可以借鉴建筑领域的东西来进行软件开发，
我想到了软件模式，
其实说白了，三人行必有我师，
对于不同的领域，到了高处，很多东西也都是可以相互借鉴的吧。
#37
软件的构架与设计模式的关系如何？
#38
To gg007(赵gg):
软件的架构设计有一些规律可循，有经验的人经过综合，发现了一些模式。这些模式称作架构模式，它们都是架构设计的范例。
软件模式可以分成架构模式、设计模式和代码模式，它们的尺度不同。
一般地讲，软件架构与设计模式没什么关系。有关系的是架构模式。
软件的架构设计有一些规律可循，有经验的人经过综合，发现了一些模式。这些模式称作架构模式，它们都是架构设计的范例。
软件模式可以分成架构模式、设计模式和代码模式，它们的尺度不同。
一般地讲，软件架构与设计模式没什么关系。有关系的是架构模式。
#39
swinging(山不在高)说：想把一些用于建筑的好的东西引入软件
这已经在发生了，只是大部分人没有察觉而已。软件架构设计有一个Layers模式（分层模式），这本就来自于建筑学，参见
参考文献
[BRAND94]Stewart Brand，How Buildings Learn: What Happens After They're Built, Viking, 1994（呵呵，那时候UML在哪里，设计模式在那里？）
那里对Layers模式的描述比我见过的所有软件著作都精辟得多。
这已经在发生了，只是大部分人没有察觉而已。软件架构设计有一个Layers模式（分层模式），这本就来自于建筑学，参见
参考文献
[BRAND94]Stewart Brand，How Buildings Learn: What Happens After They're Built, Viking, 1994（呵呵，那时候UML在哪里，设计模式在那里？）
那里对Layers模式的描述比我见过的所有软件著作都精辟得多。
#40
开了一个讨论架构的话题，没有人理我，放到这里，请大家看看
在总结前人的基础上给出了整体描述一个系统的7个架构
应用架构：从使用视角看架构。系统实现的功能，以及各功能模块间的关系。
业务架构：业务模型，流程模型，组织模型等企业本身
信息架构：企业的信息系统规划
体系架构：三层或N层体系
系统架构: 软硬件部署
安全架构：安全了
软件架构：此部分主要描述各个应用软件间的关系结构，如数据库，was，portal等
在用这个架构去描述一个大系统的时候感觉非常清楚，
其中信息架构，我给出的说明实际上是信息系统架构，有没有对信息架构专门有研究的同行详细说明一下，对信息架构还是不很把握
在总结前人的基础上给出了整体描述一个系统的7个架构
应用架构：从使用视角看架构。系统实现的功能，以及各功能模块间的关系。
业务架构：业务模型，流程模型，组织模型等企业本身
信息架构：企业的信息系统规划
体系架构：三层或N层体系
系统架构: 软硬件部署
安全架构：安全了
软件架构：此部分主要描述各个应用软件间的关系结构，如数据库，was，portal等
在用这个架构去描述一个大系统的时候感觉非常清楚，
其中信息架构，我给出的说明实际上是信息系统架构，有没有对信息架构专门有研究的同行详细说明一下，对信息架构还是不很把握
#41
好！好！好！
学习！
学习！
#42
建筑构架：门、窗、墙（柱）、顶（梁）、基、梯（如多层），任你千变万化，管他怎么用途。
车构架：*、驱动器、轮驱连接器，任你千变万化，管他怎么用途。
软件构架：？？？？？？？任你千变万化，管他怎么用途。
车构架：*、驱动器、轮驱连接器，任你千变万化，管他怎么用途。
软件构架：？？？？？？？任你千变万化，管他怎么用途。
#43
支持！
#44
个人觉得软件架构设计目的是为了能符合人思维模式。
软件架构能从比较高层次来抽象模型。使人有个总体的概念。就如同书目录一样，勾画出主题，把握方向。相对于底层复杂模型而言，人更易接受简单和全局的东西。而对于软件架构分类如应用架构，信息架构......那是思维和应用的多样化（把它们分类了，可能更加容易理解）对于复杂的东西，我们希望抽象，分解他们，变成我们容易理解的东东。
这几天在看设计模式（elements of reusable oo software）和doctor yan
（jeffyan77(jeffyan77)）的java 和模式。虽然不是很明白具体模式，其实说实在的，我也没有打算都明白每个模式，但是我觉得收益非浅。OO把问题域与解域的距离拉近，oo解决问题的思维与我们的思维模式相近。而设计模式可以说是许许多多软件应用领域设计思维的一种抽象。细细品，还真是那个味。
谈谈建筑和软件关系。我觉得没有必要牵扯太多。软件和建筑有许多相近的东西。只是思维的一种碰撞。但可以借助建筑学的东西来理解软件领域的内容，同样软件的发展是极其快的，（是时尚？活力？）也会影响建筑业的！
//（注释）在众多高手面前，瞎说！
软件架构能从比较高层次来抽象模型。使人有个总体的概念。就如同书目录一样，勾画出主题，把握方向。相对于底层复杂模型而言，人更易接受简单和全局的东西。而对于软件架构分类如应用架构，信息架构......那是思维和应用的多样化（把它们分类了，可能更加容易理解）对于复杂的东西，我们希望抽象，分解他们，变成我们容易理解的东东。
这几天在看设计模式（elements of reusable oo software）和doctor yan
（jeffyan77(jeffyan77)）的java 和模式。虽然不是很明白具体模式，其实说实在的，我也没有打算都明白每个模式，但是我觉得收益非浅。OO把问题域与解域的距离拉近，oo解决问题的思维与我们的思维模式相近。而设计模式可以说是许许多多软件应用领域设计思维的一种抽象。细细品，还真是那个味。
谈谈建筑和软件关系。我觉得没有必要牵扯太多。软件和建筑有许多相近的东西。只是思维的一种碰撞。但可以借助建筑学的东西来理解软件领域的内容，同样软件的发展是极其快的，（是时尚？活力？）也会影响建筑业的！
//（注释）在众多高手面前，瞎说！
#45
如何架构你的构架？我想这里有两个方面的讨论：
1、构架是个什么样子？它有什么基本特征？基本概念？作用是什么？构架应该是个目标、是个结果，最后以图纸的形式表现。
2、架构属于设计的方面，有什么方法？模式？用到什么工具？
我想构架的基本特征应该是一样的，只是通过你的架构，可以有不同的表现形式，就如同建筑：可以是钢结构、木结构、石结构等（这样说可能也不准确）。
而架构也应该有基本的方法、步骤等。
1、构架是个什么样子？它有什么基本特征？基本概念？作用是什么？构架应该是个目标、是个结果，最后以图纸的形式表现。
2、架构属于设计的方面，有什么方法？模式？用到什么工具？
我想构架的基本特征应该是一样的，只是通过你的架构，可以有不同的表现形式，就如同建筑：可以是钢结构、木结构、石结构等（这样说可能也不准确）。
而架构也应该有基本的方法、步骤等。
#46
具体的提出一个案例，看各位如何来运用上面所说的理论来分析，并提出方案：
本公司有5个办事处，总部有四十号人，其他四个分部各有五号人，都安装了宽带。因为从事物流行业，所以对于数据要求集中，格式要求严格，各办事处均需要报表打印的功能，有一定的安全措施，还有成本低（主要指硬件），希望系统的扩展性高，即不管谁负责系统，都能方便地增加或删除其中的功能。
向各位讨教，如何用理论来解决实际问题！
本公司有5个办事处，总部有四十号人，其他四个分部各有五号人，都安装了宽带。因为从事物流行业，所以对于数据要求集中，格式要求严格，各办事处均需要报表打印的功能，有一定的安全措施，还有成本低（主要指硬件），希望系统的扩展性高，即不管谁负责系统，都能方便地增加或删除其中的功能。
向各位讨教，如何用理论来解决实际问题！
#47
to jeffyan77(jeffyan77):
系统架构是不是系统分析师们的一部分工作？
系统架构是不是系统分析师们的一部分工作？