什么是系统架构
系统架构 (System Architecture )是系统的一种整体的高层次的结构表示， 是系统的骨架和根基，也决定 了系统的健壮性和生命周期的长短。
什么系统架构设计师
系统架构设计师在整个项目研制中的主导地位愈加重要。可以说，系统架构师就是项目的总设计师，他是一个既需要掌控整体又需要洞悉局部瓶颈，并依据具体的业务场景给出解决方案的总体设计人员；他要确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员；他要掌握技术团队的能力需要，给出项目管理方法，采用合适生命周期模型，具备以自身为核心形成团队的能力，并在项目进度计划和经费分配等方面开展评估，以预防项目风险。
系统架构的定义
这里的架构(Architecture)定义来源于IEEE1471-2000: “TEEE’s Recommand Practicefor Architectural Deseription of Software-Intensive Systems. 〞标准， 本标准主要针对软件密集系统进行了架构描述，其对架构定义如下:
- 架构 是体现在组件中的一个系统基本组织、它们彼此的关系与环境的关系及指导它的设计和发展的原则。
- 系统 是组织起来完成某一特定功能或一组功能的组件集。系统这个术语包括了单独的应用程序、传统意义上的系统、 子系统、 系统之系统、产品线、整个企业及感兴趣的其他集合。系统用于完成其环境中的一个或多个任务。
- 环境 或者上下文决定了对这个系统的开发、 运作、政策以及会对系统造成其他影响的环境和设置。
- 任务 是由一个或者多个利益相关者通过系统达到一些目标的系统的一个用途或操作。
通俗地说，系统架构(System Architecture)是系统的一种整体的高层次的结构表示，是系统的骨架和根基，支撑和链接各个部分，包括组件、连接件、约束规范以及指导这些内容设计与演化的原理，它是刻画系统整体抽象结构的一种手段。系统架构设计的目的是对需要开发的系统进行一系列相关的抽象，用于指导系统各个方面的设计与实现，架构设计在系统开发过程中起着关键性作用，架构设计的优劣决定了系统的健壮性和生命周期的长短。我们通常把架构设计作为系统开发过程中需求分析阶段后的一个关键步骤，也是系统设计前的不可或缺工作要点之一，架构设计的作用主要包括以下几点:
- 解决相对复杂的需求分析问题;
- 解决非功能属性在系统占据重要位置的设计问题:
- 解决生命周期长、扩展性需求高的系统整体结构问题;
- 解决系统基于组件需要的集成问题;
- 解决业务流程再造难的问题。
系统架构设计是成熟系统开发过程中的一个重要环节，它不仅是连接用户需求和系统进一步设计与实现的桥梁，也是系统早期阶段质量保证的关键步骤。
软件架构(也可称为体系结构)是用来刻画软件系统整体抽象结构的一种手段，软件架构设计也是软件系统开发过程中的一个重要环节。
软件架构的诞生
为了避免软件开发中重复劳动的方式提升软件开发效率并保障软件质量，软件重用与组件化成为解决此次危机行之有效的方案。随着软件组件化开发方式的发展，如何在设计阶段对软件系统进行抽象，获取系统蓝图以支持系统开发中的决策成为迫切而现实的问题，分析问题的根源和产生的原因，以下现象应该获得关注:
- 软件复杂、易变，其行为特征难以预见，软件开发过程中需求和设计之间缺乏有效的转换，导致软件开发过程困难和不可控。
- 随着软件系统的规模越来越大、越来越复杂，整个系统的结构和规格说明就显得越来越重要。
- 对于大规模的复杂软件系统，相较于对计算算法和数据结构的选择，系统的整体结构设计和规格说明己经变得明显重要得多。
- 对软件系统结构的深入研究将会成为提高软件生产率和解决软件维护问题的最有希望的新途径。
在这种情况下，软件架构应运而生。
模块化开发方法
模块化开发方法是指把一个待开发的软件分解成若干个小的而且简单的部分，采用对复杂事物分而治之的经典原则。模块化开发方法涉及的主要问题是模块设计的规则，即系统如何分解成模块。而每一模块都可独立开发与测试，最后再组装成一个完整软件。对一个规约进行分解，以得到模块系统结构的方法有数据结构设计法、功能分解法、数据流设计和面向对象的设计等。将系统分解成模块时，应该遵循以下规则:
- 最高模块内聚。也就是在一个模块内部的元素最大限度地关联，只实现一种功能的模块是高内聚的，具有三种以上功能的模块则是低内聚的。
- 最低耦合。也就是不同模块之间的关系尽可能弱，以利于软件的升级和扩展。
- 模块大小适度。颗粒过大会造成模块内部维护困难，而颗粒过小又会导致模块间的耦合增加。
- 模块调用链的深度(嵌套层次)不可过多。
- 接口简单、精炼(扇入扇出数不宜太大)，具有信息隐蔽能力。
- 尽可能地复用己有模块。
模块化方法它一方面通过抽象、封装、分解、层次化等基本科学方法，对各种软件组件和软件应用进行打包，提高对企业现有资产的重用水平和能力:另一方面，基于模块化思想，业界提出了面向对象服务架构(Service-Oriented Architecture,SOA)思想，它提供一组基于标准的方法和技术，通过有效整合和重用现有的应用系统和各种资源实现服务组件化，并基于服务组件实现各种新业务应用的快速组装，帮助企业更好地应对业务的灵活性要求。
软件架构理论
主要包括:软件架构描述与表示；软件架构分析、设计与测试；软件架构发现、演化与重用；基于软件架构开发方法；软件架构风格；动态软件架构等。
软件架构描述与表示
目前存在多种软件架构描述语言，比较典型的是基于组件和消息的软件架构描述语言C2SADL，分布、并发类型的架构描述语言Wright，架构互换语言ACME，基于组件和连接的架构描述语言UniCon，基于事件的架构描述语言Rapide，以及其他比较有影响力的描述语言Darwin、MetaFl、Aesop、Weaves、SADL、xADL等。软件架构分析、设计和测试
架构分析的内容可分为结构分析、功能分析和非功能分析。分析的目的是系统被实际构造之前预测其质量属性。
架构分析常用的方法有:软件架构分析方法SAAM、架构权衡分析法ATAM、成本效益分析法CBAM、基于场景的架构再工程SBAR、架构层次的软件可维护性预测ALPSM、软件架构评估模型SAEM等。
架构设计是指生成一个满足用户需求的软件架构过程。架构设计常用的方法有:从工件描述中提取架构描述的工件驱动(artifact-driven)方法；从用例导出架构抽象的用例驱动(use-case-driven)；从模式导出架构抽象的模式驱动(pattern-driven)方法；从领域模型导出架构抽象的域驱动(domain-driven)方法；以及从设计过程中获得架构质量属性需求的属性驱动设计(attribute-drivendesign)方法等。
架构测试着重于仿真系统模型、解决架构层的主要问题。由于测试的抽象层次不同，架构测试策略分为单元、子系统、集成和验收测试等阶段的测试策略。测试方法主要包括架构测试覆盖方法、组件设计正确性验证方法和基于CHAM的架构动态语义验证方法等。软件架构发现、演化与重用
软件架构发现解决如何从己经存在的系统中提取软件架构的问题，属于逆向工程。Watcrs等人提出了一种迭代式架构发现过程。
软件架构演化即由于系统需求、技术、环境和分布等因素的变化而最终导致软件架构的变动。软件系统在运行时刻的架构变化称为架构动态性，而将架构的静态修改称为架构扩展。架构扩展和动态性都是架构适应性和演化的研究范畴。软件架构复用属于设计重用，比代码重用更抽象。架构模式就是架构复用的一种成果。基于软件架构的开发方法
软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，给出了软件开发活动各个阶段之间的关系。通常软件开发模型可分为三种:以软件需求完全确认为前提的瀑布模型:在软件开发初期只能提供基本需求为前提的渐进式开发模型(如螺旋模型等)；以形式化开发方法为基础的变换模型。软件架构风格
架构风格(架构模式)是针对给定场景中经常出现的问题提供的一般性可重用方案，它反映了领域中众多系统所共有的结构和语义特征，并指导如何将各个模块和子系统有效地组成一个完整的系统。通常，将软件架构风格分成主要五类(David Garland和Mary Shaw划分方式):数据流风格、调用/返回风格、独立组件风格、虚拟机风格和仓库风格。
软件架构是软件生命周期中的重要产物，它影响软件开发的各个阶段。
- 需求阶段:把软件架构有的概念引入需求分析阶段，有助于保证需求规约和系统设计之间的可追踪性和一致性。
- 设计阶段:设计阶段是软件架构研究关注最早、最多的阶段，这一阶段的软件架构主要包括软件架构的描述、软件架构模型的设计与分析以及对软件架构设计经验的总结与复用等。
- 实现阶段:将设计阶段设计的算法及数据类型用程序设计语言进行表示，满足设计、架构和需求分析的要求，从而得到满足设计需求的目标系统。
-维护阶段:为了保证软件具有良好的维护性，在软件架构中针对维护性目标进行分析时，需要对一些有关维护性的属性(如可扩展性、可替换性)进行规定，当架构经过一定的开发过程实现和形成软件系统时，这些属性也相应地反映了软件的维护性。