软件构架实践_阅读笔记01（1-3）

　　之前的学期，我们学习了软件工程概论和软件需求分析，而下个学期即将学习软件体系架构。如课程安排的一样，如大众的观点一致：需求在架构之前。即传统的思想：在知道了系统的需求，就可以为此系统构建构架。而紧接着，书中使用了经典的“瑞典的瓦萨战舰”以证明这种观点的缺乏远见——不能真正揭示出架构的重要价值。

　　“瑞典的瓦萨战舰”讲的是一个违背当时技术水平建造的战舰，这个战舰却在第一次航行时淹水沉没了。虽然故事发生在400年前，却很好的说明了架构商业周期的概念：系统需求来自于企业目标，架构来自于系统需求，系统来自于架构。同时，此案例同样的提示了三方面的内容：一，能够满足苛刻需求的成功架构案例分析，以确定当前的技术水平；二，在构建系统之前使用对所用架构进行评估的方法，以减少开发一个无先例的全新系统所承担的风险；三，基于架构的增量开发技巧，以及时发现设计缺陷并加以改进。

　　既然开始了对“架构”的分析，那么就要清楚架构受什么的影响。首先，受涉众的影响，因为太多相关的人会对架构有建议和影响，所以这一点显而易见。因此，一个得到各方认可的系统需求在以下达到相应要求：性能、可靠性、可用性、平台兼容性、内存的利用、网络使用程度、安全性、可修改性、易用性、与其他系统的互操作性及行为。其次，架构还受开发组织、设计师的素质和经验的影响、也受技术环境的影响。这一点，也同样很好理解，所谓经济基础决定上层建筑，对等而言，技术基础决定最后的系统成果。同样，如同“作用存在一定有反作用力”，这些因素也会反作用于架构。

　　然后，我们再来分析“什么样的架构算最好？”。怎么简介地对那一页的内容进行概括呢，简单的说，就是因地制宜！再多的条条框框也是理论，实际来说，还是看实际情况来操作。

　　接下来，开始认识几个概念的定义。架构模式是对元素和关系模型以及一组对其使用方式的限制的描述。参考模型是一种考虑数据流的功能划分。参考架构是映射到软件元素及元素之间的数据流的参考模型。然而，讲了这么久，我们为什么要了解架构？为什么有一个新的名词叫做架构呢？架构简而言之是涉众进行交流的手段，同样是早期设计决策的体现，也是可传递、可重用的模型。用通俗的话来讲，就是，架构源于提出的人，同时受影响于各个方面的因素。

　　对第三章，说实话，无法具体的来说概念等，只能笼统而言，是案例分析的几个实例。