系统架构师的工作是复杂设计总体解决方案以及领域对象的逻辑和物理布局,这是一项在复杂环境中高风险、高影响力的活动。那么软件架构是什么呢?什么是系统架构呢?一起来了解一下!
软件架构可以被简单的描述为，一系列组件之间的组合，交互，继承的关系。当然这样的解释基本上人人都可以接收。不过在我们看来，这样的说法有点过于抽象。
软件架构有这标准的定义，就是参考ansi/ieee的标准，软件架构可以理解为软件密集型系统中对系统的实现和部署起决定性作用的的系统。
软件架构中的关键点是应该符合项目干系人的目标，功能上当然细分成功能性的和非功能性的需求。
软件架构有一定的特殊性，架构设计必须开发的初期就确定，架构设计作为关键决策必须前期确定。
软件架构其实主要是要符合项目干系人的目标，如果无法满足项目干系人的目标，那么这个架构方案就行不通，下图是ansi/ieee标准中定义的系统、架构与项目干系人直接的关系。
开篇中已经介绍了系统架构的表述工具有uml和relation rose，uml基本上已经成为国际的标准。
uml的类图：主要是描述类之间的关系。
用例图：描述使用场景。
组件图：用来描述系统中的可重用部分。并且容易看出组件与二进制文件之间的对应关系。
通过uml工具，我们能够更深层次对系统架构进行不同角度的描述。抓住其核心。
软件架构的验证，目前没有什么好的办法可以自动验证软件架构是否可以达到项目干系人的目标，只有通过多种方式多个级别的测试。
例如通过单元测试，来验证单一的功能，集成测试来评估系统的兼容性，验收测试来验证用户的`满意度,程序是否提供必要的功能。
可以这样说，软件系统的架构过程中没有什么系统是不可拆分的，系统的开发方法越敏捷，为开发人员实现架构是预留的空间越大。
系统架构师将系统分解的过程，其实最终形成的就是一份为开发人员提供的详细设计说明书。当然详细设计说明书的内容和格式也取决于开发方法。
架构大多体现在难以改变或者改变起来代价较大的决定上。但是最终还是需要有人做决定。
系统分析师分析系统做什么，架构师设计如何去做。
架构师是需求与详细说明的纽带。
架构师的职责：架构师应该参与到开发的全过程当中。包括分析需求与架构设计、实现、测试、继承与部署。
按照iso的定义架构师的定义如下：负责系统架构的人、团队或组织。
微软则对系统架构是做了如下的划分：
1、企业架构师。
2、基础架构师。
3、特定技术架构师。
4、解决方案架构师。
最后总结软件开发过程中的一些法则：
1、为了一个赶不上进度的项目增加人手，只会让项目更加落后于进度。
2、程序的复杂性会一直的增加，直到维护人员感觉到力不从心为止。
3、建筑师与开发人员写程序不同，如果建筑师按照开发人员的方式开建造，只会成为历史中的败笔。
