1.1　软件架构流程

软件架构（Software Architecture）是指一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构可以看作是一个系统的“草图”，软件体系结构是构建计算机软件的实践基础。软件架构所描述的对象由直接的系统抽象组件构成。连接系统的各个组件需要做到将组件之间所存在的通信以比较明确且相对细致的方式进行描述。当处于相应的系统实现环节时，那么就会细化这些抽象组件成为现实的组件。

软件架构为软件系统提供了一个将结构、行为和属性融合为一体的高级抽象，它由构件的描述、构件的相互作用、指导构件集成的模式和这些模式的约束组成。软件架构不仅明确了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，并提供了一些设计决策的基本原理。

1.1.1　业务分析

业务分析是面向业务的一门分析学科，它通常可以采取逻辑分析和概念分析两种方法论。逻辑分析是指进行部件解析；概念分析则是综合性地从概念所处的上下文背景环境入手进行分析。简单来说，业务分析主要针对目标行业的业务战略、蓝图、业务功能及流程进行分析。在此期间，提出部分功能以信息化的手段进行处理，通过分析最终得出信息化要解决的问题。

业务分析作为一种实践，通过战略分析与利益相关者合作，定义业务需求，从而有助于促进组织变革。业务分析是一个识别业务需求并确定业务问题解决方案的研究学科。解决方案通常包括软件系统开发组件，但也可能包括流程改进、组织变更、战略规划和政策制定。执行此任务的人称为业务分析师或BA。

以下是四种类型的业务分析。

（1）识别组织的业务需求和业务机会。

（2）业务模型分析。定义组织的政策和市场方法。

（3）流程设计。标准化组织的工作流。

（4）系统分析。技术系统的业务规则和要求的解释。

1.1.2　解决方案架构

解决方案架构属于“技术性”架构，它包括软件、数据和IT基础架构等各种技术元素。解决方案架构是解决系统问题的主要蓝图，其中涉及主要的工作步骤和采用的技术方法等。

解决方案，即提出解决问题的方案，主要用于解决已经出现或可预期的问题、缺陷、需求等，同时确保解决方案能够有效执行。解决方案包括明确的对象、施行的范围和领域。

解决方案是多个项目的集合，一个项目的输出一般对应一个程序集。解决方案的输出构成了一个应用程序，根据项目数量的不同，其可以是单个文件或多个文件。

1.1.3　系统功能设计

系统功能设计是根据系统分析的结果，运用系统科学的思想和方法，设计出可以最大限度满足所有要求目标的过程。系统设计流程为：确定系统功能、设计方针和方法，提出理想系统并做出草案→通过收集信息对草案做出修正，形成可选设计方案→将系统分解为若干子系统，进行子系统和总系统的详细设计并评价→对系统方案进行论证并做出性能效果预测。

在进行系统设计时，必须把所要设计的对象系统和围绕该对象系统的环境共同考虑。前者称为内部系统，后者称为外部系统。内部系统和外部系统结合起来，称为总体系统。内部系统与外部系统之间存在着相互支持和相互制约的关系，因此，在设计系统时必须采用内部设计与外部设计相结合的方式，从总体系统的功能、输入、输出、环境、程序、人为因素、物质媒介各方面综合考虑，设计出整体最优的系统。进行系统设计应当采用分解、综合与反馈的工作方法。无论多复杂的系统，首先要分解为若干子系统，分解可从结构要素、功能要求、时间序列、空间配置等方面进行，并将其特征和性能标准化，综合成最优子系统，然后将最优子系统进行总体设计，从而得到最优系统。在这一过程中，从设计计划开始到设计出满意系统为止，都要进行分阶段及总体综合评价，并以此对各项工作进行修改和完善。整个设计阶段是一个综合性反馈过程。

系统设计通常应用两种方法：一种是归纳法；另一种是演绎法。应用归纳法进行系统设计的过程是：首先尽可能地收集现有的和过去同类系统的设计资料，接着在对这些系统的设计、制造和运行状况进行分析、研究的基础上，根据所设计系统的功能要求进行多次选择，然后对少数几个同类系统做出相应修正，最终得到一个理想的系统。演绎法是一种公理化方法，即先从普遍的规则和原理出发，根据设计人员的知识和经验，从具有一定功能的元素集合中选择符合系统功能要求的多种元素，然后将这些元素按照一定形式进行组合，从而创造出具有所需功能的新系统。在系统设计的实践中，这两种方法往往是并用的。

1.1.4　系统架构设计

系统架构设计主要针对某一系统的支撑表达、层次化关系表达及功能、技术核心元素进行设计。

系统架构设计是指根据一个系统的“草图”，描述构成系统的抽象组件及各个组件之间是如何进行通信的，这些组件在实现过程中会被细化为实际的组件，例如类或对象。在面向对象领域中，组件之间的关联通常是面向接口实现的。

“架构”一词最早来自建筑学，原意为建筑物设计和建造的艺术。但是在软件工程领域，软件架构并不是一个新名词，只是在早期的著作中人们常将软件架构称为软件体系架构。

1.1.5　技术体系设计

技术体系设计主要针对系统的接口、数据存储、技术路线、部署及实现抽象进行设计。

体系架构通常会建立一个共有的远景。然而，仅有简单的设定远景是远远不够的，必须与构建人员、客户、其他相关人员进行沟通以达成共识。在构建过程中要维护该体系架构。体系架构可以定义为一种可行的、有条理的部件集合的结构化形式，该架构通过这些部件以一种精确的方式为用户提供远景支持。IT行业使用“体系架构”这一个概念的历史不是很长，但它与其他行业在体系结构使用的方法上有相同的应用愿景，即体系架构的实现连接了具体的需求和远景战略规划。

从IT规划角度看，企业IT体系架构往往与软件系统架构、应用程序架构混为一谈。确切来讲，企业IT体系架构的概念比软件系统架构的概念更为宽泛，它指明了通过IT系统支持业务目标的方向。在企业IT体系架构中，其中较为关键的部分就是技术体系架构。之所以技术体系结构重要，是因为它对IT规划的实现起着支撑作用。从本质上讲，技术体系架构定义了组织为了获得商业利润而构建与使用的信息技术平台。

技术体系架构包含以下几点内容。

（1）描述和定义所交付业务系统采用的技术环境结构。

（2）建立和维护一套评价技术项目的核心技术标准。

（3）建立技术实现决策的框架。

（4）建立一个技术与业务系统有机结合的有效方法。

（5）为组织内技术环境保持良好的发展态势提供管理架构。

1.1.6　体系结构设计原则

体系结构设计原则有以下几点。

1．合适性

合适性是指体系结构是否契合软件的“功能性需求”和“非功能性需求”。高水平的设计师能设计出恰好满足客户需求的软件，并且使开发方和客户方均获取到最大的利益，而不是不惜代价设计出最先进的软件。

2．结构稳定性

详细设计阶段的工作（如用户界面设计、数据库设计、模块设计、数据结构与算法设计等）都是在体系结构确定后开展的，而编程和测试则是更靠后面的工作，因此体系结构应在一定的时间内保持稳定。

软件开发过程中最怕的就是需求变化，但“需求会发生变化”是个无法逃避的现实。开发人员等希望在需求发生变化时最好只对软件做些简单的修改，而不需要改动软件的体系结构。如果需求发生变化时，程序员必须去修改软件的体系结构，那么这表示该软件的系统设计是失败的。

高水平的设计师应当能够分析需求文档，判断出哪些需求是稳定不变的、哪些需求是可能变动的。于是，便可以根据那些稳定不变的需求设计体系结构，而根据那些可变的需求设计软件的“可扩展性”。

3．可扩展性

可扩展性是指软件扩展新功能的容易程度。可扩展性越好，表示软件适应“变化”的能力越强。

4．可复用性

由经验可知，通常在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。一般可以相信成熟的事物总是比较可靠的（即具有高质量），而大量成熟的工作可以通过复用来快速实现（即具有高生产率）。

可复用性是设计出来的，而不是偶然碰到的。要使体系结构具有良好的可复用性，设计师应当分析应用域的共性问题，然后设计出一种通用的体系结构模式。这样的体系结构才可以被复用。