开篇说明

      由于是自己对这些技术的学习总结和心得体会，错误之处在所难免，怀着技术交流的心态，现在发表出来，所以希望大家能够多多指点，这样能使一部分人受益同时也能纠正我的错误观点，以便和各位共同提高！

软件架构到底是什么

      软件架构可以被简单的描述为，一系列组件之间的组合，交互，继承的关系。当然这样的解释基本上人人都可以接收。不过在我们看来，这样的说法有点过于抽象。

      软件架构有这标准的定义，就是参考ANSI/IEEE的标准，软件架构可以理解为软件密集型系统中对系统的实现和部署起决定性作用的的系统。

      软件架构中的关键点是应该符合项目干系人的目标，功能上当然细分成功能性的和非功能性的需求。

      软件架构有一定的特殊性，架构设计必须开发的初期就确定，架构设计作为关键决策必须前期确定。

      软件架构其实主要是要符合项目干系人的目标，如果无法满足项目干系人的目标，那么这个架构方案就行不通，下图是ANSI/IEEE标准中定义的系统、架构与项目干系人直接的关系。

     开篇中已经介绍了系统架构的表述工具有UML和Relation Rose，UML基本上已经成为国际的标准。

     UML的类图：主要是描述类之间的关系。

     用例图：描述使用场景。

     组件图：用来描述系统中的可重用部分。并且容易看出组件与二进制文件之间的对应关系。

     通过UML工具，我们能够更深层次对系统架构进行不同角度的描述。抓住其核心。

     软件架构的验证，目前没有什么好的办法可以自动验证软件架构是否可以达到项目干系人的目标，只有通过多种方式多个级别的测试。

     例如通过单元测试，来验证单一的功能，集成测试来评估系统的兼容性，验收测试来验证用户的满意度,程序是否提供必要的功能。

     除了UML建模工具之外，还有IBM比较著名的Relation Rose，这里大概介绍下该工具具有的视图模式：

系统的架构

      可以这样说，软件系统的架构过程中没有什么系统是不可拆分的，系统的开发方法越敏捷，为开发人员实现架构是预留的空间越大。

      系统架构师将系统分解的过程，其实最终形成的就是一份为开发人员提供的详细设计说明书。当然详细设计说明书的内容和格式也取决于开发方法。

架构是什么

       架构大多体现在难以改变或者改变起来代价较大的决定上。但是最终还是需要有人做决定。

       系统分析师分析系统做什么，架构师设计如何去做。

       架构师是需求与详细说明的纽带。

       架构师的职责：架构师应该参与到开发的全过程当中。包括分析需求与架构设计、实现、测试、继承与部署。

      按照ISO的定义架构师的定义如下：负责系统架构的人、团队或组织。

      微软则对系统架构是做了如下的划分：

      1、企业架构师。

      2、基础架构师。

      3、特定技术架构师。

      4、解决方案架构师。

最后总结软件开发过程中的一些法则：

      1、为了一个赶不上进度的项目增加人手，只会让项目更加落后于进度。

      2、程序的复杂性会一直的增加，直到维护人员感觉到力不从心为止。

      3、建筑师与开发人员写程序不同，如果建筑师按照开发人员的方式开建造，只会成为历史中的败笔。

本文转自何戈洲博客园博客，原文链接：http://www.cnblogs.com/hegezhou_hot/archive/2010/09/07/1821012.html，如需转载请自行联系原作者