***前言***
假期里粗略的看了一遍《架构之美》，对软件架构有了自己的理解。在周一的第一节《软件架构》课上，老师用了一个房屋改造的引例来开展软件构造的概论内容，这个引例让我对软件架构有了更深刻的理解，下面结合这个引例谈一些对于软件架构的理解。
一、什么是软件架构
人们常常喜欢使用结构来描述“架构”，在软件架构上更是如此，而且会参照建筑方面的概念来进行说明.其实在好多学科中都用到了“架构”这个词，大都表达了对所创造作品的描述，或者是对创造过程的计划。但是在软件专业中还有更具体的表达。软件架构不是一个简单的实体，软件架构师需要用多分文档来对软件的行为和结构进行描述，以此来形成软件架构。这里有一个较为严格的定义是这样的：一个程序或计算机系统的软件架构是系统的一种结构或一组结构，包含了软件元素、软件元素外部可见的属性以及元素之间的联系。这里的外部可见的属性指的是其他元素对该元素可以做出的假定，比如所提供的服务，执行的特征或者错误处理等等。实际上，软件架构对软件设计进行了适当的抽象化，使得架构师更关注软件设计中的某些方面。我的理解就是软件架构就是对软件系统中的各个元素之间在结构方面的关系进行一个抽象化的描述。
二、软件架构师要做什么？
这里就用到了我们在软件需求分析课堂上所学到的知识了。
第一步是全面认识需求。在需求分析与领域建模即分析阶段，软件架构工程师与软件需求人员一起将所有需求从不同的级别(组织级、用户级、开发级)分层梳理列表归纳总结建立跟踪矩阵，并划分为不同的类型(功能需求或用例、质量属性、约束与限制)进行梳理列表归纳总结建立影响分析表，找出不同需求类型之间的相互支持、相互制约关系的影响。软件架构设计过程的第二步是确定对架构关键的需求。软件架构工程师将所有需求进行筛选，在深思熟虑之后作出合适的需求权衡和取舍，最终确定对软件架构起关键作用的需求子集，控制架构设计时需要详细分析的用例个数，找到影响架构的重点非功能需求。在此基础上，软件架构设计过程的第三步是进行概念性架构设计。设计概念性架构的第一步是分析关键用例有用例规约，运用鲁棒图等方法构造系统理想化的职责模型(如分层)。接下来明确架构模式(如MVC)，确定交互机制，形成初步的概念性架构。最后通过质量属性分析，制定出满足非功能需求的高层设计决策，并根据这些决策对之前的工作成果进行增强、调整，以保证概念性架构体现这些设计决策。接下来，软件架构设计过程的第四步是细化软件架构，考虑具体技术的运用，设计出实际架构。概念性架构所关注的关键设计要素、交互机制、高层设计决策与具体技术无关，而最终的软件架构设计方案必须和具体技术结合，为开发人员提供足够的指导和限制。为些，必须从系统如何规划、如何开发、如何运行等角度揭示软件系统的结构和机制。一般分别从逻辑架构、开发架构、运行架构、物理架构、数据架构等不同架构视图进行设计。最后，软件架构设计过程的第五步，千万别忘了验证软件架构。
这里只突出强调两点，要关注利益相关人员的需求，以及同时做到关注软件的功能和品质。每一个或者说每一类的利益相关者对软件系统的品质关注点是不一样的，软件架构师需要同这些利益相关者展开协作，理解这些品质关注点和约束，并为这些品质关注点排列优先级。尽管许多架构都能满足功能需求，但是能满足品质需求的却很少。架构师需要对软件系统形成全面的理解，在软件设计中做出明智的决定。
三、什么是好的软件架构？
其实创建软件架构的过程就是一个取舍的过程，对于一组给定的功能需求和品质需求，是没有唯一正确的软件架构的，我们需要从经验中对架构进行评估。首先一个好的软件架构须让系统的每一个用户都能理解该系统的架构，如果不能让一个人理解软件的架构的话，那么这个软件的架构一定不是好的架构。其次，在使用架构之前必须先构建，使用一个好的架构一定是可构建的，可扩展的。最后也是最重要的一点，好的架构必须从软件设计到构建到使用的全过程使得所有人都满意，这里包含了三个层次。第一是能使软件开发人员的工作变得简单。第二是使软件测试人员的工作变得轻松，最后是让使用软件的用户拥有良好的使用体验。