软件体系结构是指系统的一个或者多个结构，这些结构包括软件的构件，如程序模型、类、中间件等，还包括构件的外部可见属性及其之间的相互关系。这里所说的软件体系结构实际上就是我们常说的软件架构。体系结构的设计主要包括数据设计和体系结构设计。
软件体系结构不是可以执行的软件，它只是用来帮助软件工程师分析设计在满足需求方面的有效性，在设计变更比较容易的阶段选择体系结构可能的方案，并且降低由软件架构带来的风险。软件的体系结构设计的目标就是构建软件的初始蓝图。
软件架构设计的生命周期
需求分析阶段
在需求分析阶段，软件架构的研究还处于起步阶段。需求和软件架构设计所面临的是不同的对象：一个是问题，一个是问题的解。从软件需求模型向软件架构模型的转换需要重点关注以下两个问题：
- 如何根据需求模型建立架构模型。
- 如何保证模型转换的可追踪性。
这两个问题的解决方案随着需求研究所建立的需求模型不同而不同。但是大部分情况下，需求模型向架构模型的转换通常都依靠词性分析和经验规则来完成。架构模型同样也会去影响需求分析过程，这往往是需求分析过程受已有软件系统的影响，通过借鉴和复用将已有的软件架构模型带入到新系统的需求分析中。
软件架构研究与软件需求分析同时启动，是有助于软件开发过程的完整的，也有利于软件开发的各个阶段的可追踪性。
设计阶段
软件设计阶段是软件架构模型快速发展的阶段，在这一阶段主要关注的内容有软件架构模型的描述、软件架构模型的设计和分析方法以及历史软件架构设计经验的总结和复用。
在这个阶段，软件架构模型的研究一般会分为三个步骤：
- 软件架构模型基本元素的提出。在这个步骤中，主要的目标是列出软件架构模型都由哪些元素组成，这些元素之间是按照什么样的也则进行组织的。随着对软件架构模型研究的深入，各个基本构件之间的互联机制也渐渐的清晰和独立，并成为与构件同级别的实体，即连接子。所以在这个阶段主要需要完成的工作是针对构件和连接子进行建模。
- 使用体系结构描述语言对构件、连接子以及它们的配置进行描述。
- 从不同的视角描述系统的体系结构，这样可以得到软件架构模型的多个视图表示，从而可以将其组织起来形成可以描述软件整体的软件架构模型。系统的每一个视角都反应了一组系统相关人员所关注系统的特殊方面。
对于软件架构模型的多视图表示，业界及学术界已经提出了多种方案可供选择，其中包括常用的4+1视图模型，Hofmesiter的4视图模型以及CMU-SEI的Views and Beyond模型。
实现阶段
软件架构研究的前两个阶段所站的层次都比较高，这两个阶段的工作特点也都是按照自顶向下、逐步细化的原则进行。但是无论再怎样设计，最终的目标都是让软件架构设计落地真正的与软件开发过程结合，指导软件系统的开发。所以实现阶段就是要来研究软件架构设计如何向软件实现的转换。这个转换过程的研究通常都集中在以下几个方面：
- 研究开发过程支持，如项目组织结构、配置管理等。
- 研究软件架构的过渡途径，如语言特性引入、模型映射、复用中间件等。
- 研究基于软件架构的测试技术。
在这个阶段所作的事情全部都围绕着填补高层软件架构模型与底层实现之间的差距来进行的，而这些事情的最终目的也一定是提速软件架构设计的落地，使之更加贴近实际的软件系统开发。
构件组装阶段
在这个阶段主要处理的是可复用构件的组装，通过比照软件架构模型设计出的系统蓝图，被选用的可复用组件将被快速构建为系统的支撑结构。例如安全服务、命名服务等公共服务。还可以将一些特定的操作转化为具体的实现机制。
在构件组装阶段最长出现的问题就是体系结构失配。体系结构失配是在软件复用过程中，用于被选中的可复用构件与最终的系统体系结构和环境不匹配而导致的冲突。所以在构件组装阶段的另一个重要的工作就是识别并消除这种体系结构失配的问题。
部署阶段
在分布式软件开发中，软件部署已经从软件开发过程中独立了出来，所以为了使这类分布式软件能够满足设计质量要求，软件架构设计过程中就需要对待部署的软件构件的互联、硬件的拓扑结构、资源占用等进行多方面的考虑和设计。
软件架构模型可以提供针对部署方案的质量分析，从而使团队能够选择一个合理的部署方案。
需要注意的是，软件架构设计过程中所涉及到的软件部署研究工作，更多的是关注于展示部署阶段，而不是生产部署阶段。生产部署方案往往是需要部署人员参与提出，软件架构设计人员参与评审的。
后开发阶段
后开发阶段是软件完成部署之后的阶段。在这个阶段中，软件架构研究的方向就主要迁移到了维护、演化和复用这些方面。
传统的软件架构设计会假设软件的体系结构是静态的，也就是说软件的体系结构一旦建立，就不会在运行时发生变动。但是在实践中的软件并不是这样，软件会根据其内部和外部的影响，在运行时动态的修改其体系结构。所以如何在设计阶段捕获体系结构的这种动态性，进一步指导软件系统在运行时刻实施体系结构的变化，从而最终达到系统的在线演化或者自适应计算，是在后开发阶段索要研究的内容。
此外，现实中还有相当数量的软件是基于已有系统进行升级、增强而来的，例如二次开发等。这样的系统大多数在开始开发的时候没有考虑软件架构，或者在进行升级和增强的时候没有获得原始系统的软件架构设计，在进行开发活动的时候就不会得到体系结构的支持。所以从这些系统中恢复或者重构体系结构也是一个非常必要的环节，对于当前系统的开发也是非常有意义的。这样从已经实现的系统中获取体系结构的过程，一般会被称为软件架构重建，软件架构重建会输出一组体系结构视图，可以用于指导已有系统的升级和增强等开发活动。
基于体系结构的开发模型
基于体系结构的软件设计（Architecture-Based Software Design，ABSD）是体系结构驱动的，也就是由构成体系结构的商业、质量、功能需求组合驱动的。在ABSD方法中，设计活动可以在需求抽取和分析还没有完成的时候就开始软件设计，并且软件设计与需求抽取和分析是同步进行的。
ABSD方法有三个基础：第一个是功能的分解，ABSD方法使用基于模块的内聚和耦合技术；第二个是通过选择体系结构风格来实现质量和商业需求；第三个是使用软件模板。使用ABSD方法设计出的体系结构的随意性很低，因为ABSD方法是一个自顶向下、逐步递归细化并且每个步骤都是清晰定义的方法。
传统的软件开发模型中，软件体系结构的建立位于需求分析之后，概要设计之前。但是传统软件开发效率不高，不能很好的支持软件重用等目标需求。所以基于体系结构的开发模型（Architecture-Based Software Design Model，ABSDM）将整个软件体系结构的构建划分为需求、设计、文档化、复审、实现和演化六个子过程，以此来加强软件体系结构建立的效率和一些被期望的附加特性。
体系结构需求
需求是用户对软件系统在功能、行为、性能、设计约束等方面的期望。体系结构需求主要是获取用户需求，标识系统中所要使用到的构件的过程。
体系结构需求一般来自三个方面：质量目标、系统的商业目标和人员的商业目标。所以软件体系结构的获取过程主要是定义开发人员必须要实现的软件功能目标，满足业务上的功能需求，同时还需要满足一些质量需求和非功能需求。
而标识系统中索要使用到的构件是为系统生成初始逻辑结构的过程，这一过程通常分为三个步骤来实现。
- 生成类图。
- 对类进行分组。分组可以大大简化类图结构，一般的分组原则是与其他类隔离的类形成一个组，由聚合或者合成等关联关系的类形成以一个附加组。
- 将上一步分组得到的类簇打包成构件。
体系结构需求获取过程的最后一个步骤是对所获取的需求进行评审。评审需要由不同的干系人代表参与，审查已经获取的需求是否真实的反应了客户的需求，类的分类是否合理，构建的合并和使用是否合理等。如果体系结构需求没有通过评审，那么就需要重新重复整个需求获取的过程，直到获取的需求能够通过评审为止。
实际上，软件体系结构设计的每一个过程都需要进行评审，评审是每一个设计步骤形成的工作输出的确认过程，也是一个质量保证过程和参与软件系统开发过程的多方达成共识的过程。
体系结构设计
体系结构需求定义了系统的功能边界，是用来激发和调整设计决策使用的。在体系结构需求的指导下，体系结构设计通过多次迭代，逐步形成和细化形成最终的软件结构体系结构模型。
进行软件体系结构设计的第一个步骤是提出软件体系结构模型。软件体系结构不是凭空出现的，如果没有一个基础的体系结构，那么就无法对未来所需要使用的体系结构提供指导方向，在这个步骤中，并不需要提出一个完全可用的软件体系结构，而是只需要选择一个合适的体系结构风格即可。开发人员可以通过这个体系结构风格给出的原始体系结构模型获得关于体系结构属性的一些信息；而这个体系结构风格也同时为未来体系结构模型的实现和演化提供了方向和目标。
体系结构风格一旦确立即不可更改，如果更改体系结构风格就会导致整个软件体系结构设计工作归零。所以在确立体系结构风格以后，体系结构设计的迭代就将基于已经选择的体系结构风格循环进行。
一个体系结构设计的迭代开始于映射构件，在这个步骤中，需要将在体系结构需求步骤中标识的构件一一映射到体系结构中。当完成已经标识的构件的映射工作以后，就需要分析这些构件的相互作用和关系。映射到体系结构中的构件会形成一个只包含适合体系结构模型的构件的中间结构，在明确这种中间结构中的各个构件间的关系和相互作用以后，这个中间结构就会变得精化起来，渐渐的变成一个真正可以用于指导开发工作的软件体系结构。
体系结构设计的每一个迭代的最后一个步骤都毫无例外的是评审环节，这个评审环节同样是用于保持已经建立的软件体系结构与客户的需求是契合的。
体系结构的文档化
软件体系结构模型在建立之后都是非常抽象的，只有一些概念构件。所以如果把已经建立的软件体系模型交给软件开发人员去实现，必须要先把软件体系结构模型进行文档，文档化在系统演化的每一个阶段都执行着设计人员与开发人员的通信媒介功能，也是提供各个阶段性评审的基础。
体系结构文档化的主要输出内容是体系结构规格说明和测试体系结构需求的质量设计说明两个文档。文档的编写必须要从使用者的角度出发，并在编写结束后分发给所有与系统有关的人员，而且还要保证开发人员手上的文档始终是最新的。
体系结构复审
体系结构设计、文档化和复审是一个完整的迭代过程，体系结构在完成文档化以后，需要由用户代表和领域专家进行一次复审。体系结构复审的目的是标识潜在的风险，及早的发现体系结构设计中的缺陷和错误，确定体系结构能否满足商业需求、质量需求，体系结构的层次是否清晰，构建的划分是否合理，文档是否准确等。
体系结构实现
体系结构的实现是所有软件开发人员最熟悉的一个过程，就是把体系结构模型代码化和实体化并最终形成可用软件系统的过程。
在体系结构说明书中，已经定义了系统中构件和构件之间的关系。构件可以从构件库中寻找符合构件接口约束的构件来使用，如果无法找到符合构件接口约束的构件，那么就必须开发满足要求的新构件。在所有构件都已经准备完毕以后，可以通过体系结构设计中提供的组装支持工具将构件连接起来，并以此完成整个系统的连接和合成。
对于已经组装完成的软件系统的测试也同样发生在这一个步骤中，着包括对单个构件的功能、性能测试和系统整体的功能、性能测试。
体系结构的演化
当一个软件系统被开发完毕并交付以后，软件体系结构设计就将进入到演化阶段。因为在软件系统交付以后，用户的需求期望还会发生变化，并且即便是在软件系统开发过程中，用户的需求期望也有极大的可能发生变化。
在这种用户需求期望发生变化的时候，就必须相应的修改软件体系结构来使软件系统适应新的软件需求。体系结构演化的过程也同样是一个反复迭代的过程，其中每一个迭代都包含以下六个步骤：
- 对用户的需求变化进行归类，使变化的需求与已有的构件相对应。如果没有相对应的构件，那么就需要在后续的工作中创建新的构件。
- 制订体系结构演化的计划，这个计划必须是一个周密的计划，能够指导后续的演化的开发工作。
- 在演化计划的基础上，确定构件的修改、删除或者新增。
- 更新构件之间的控制流。
- 通过组装支持工具连接和组装构件，完成软件系统的连接和合成，形成新的体系结构。并对整个软件系统进行整体功能、性能测试。
- 对以上完成的全部步骤进行技术评审，确定新的体系结构是否能够反映需求的变化以及是否符合用户的需求。
至此，将新的修改整合进原有的体系结构之中，就完成了一次完整的体系结构演化过程。