目录
前言：
软件重用技术是一种重要的软件开发方法，虽然至今软件重用技术还不够成熟，距离理想中的软件工厂还有一些距离，但是现有的一些重用技术（例如，中间件、应用服务器等）已经改变了开发过程。
软件重用
软件产品与其他的产品不同，是抽象的，一旦产生就可以不限制地复制，因此重复利用软件产品的意义重大，可以节约大量的人力物力。软件重用指的是利用已经存在的软件元素建立新的软件系统，这其中的软件元素既可以是软件产品、源代码、也可以是文档、设计思想甚至是领域知识。软件重用可以直接提高软件的开发效率、降低软件的开发成本、缩短软件的开发周期、提高软件质量。
常见的软件重用形式包括：
- 源代码复用。这是最简单的也是最常见的重用形式，但由于软件系统的复杂性，很难大规模地重用已有源代码。
- 架构重用。架构重用也很常见，随着软件架构风格和设计模式的推广和应用，架构重用已经对软件开发产生了重大的影响。
- 应用框架的重用。随着软件技术的发展，应用框架的重用变得越来越普遍，很多成熟的软件公司都建立了自己的开发框架。在开源社区中，世界各地的技术爱好者也在不断地推出应用了各种新技术的开发框架，例如，应用AOP技术的Spring等
- 业务建模的重用。虽然不同的软件的业务领域各自不同，但人们还是总结出了一些常见领域的建模方法，重用这些领域模型可以降低因领域知识不足而造成的需求风险。
- 文档以及过程重用。软件文档和软件过程也是软件开发中不可缺少的元素，有效地重用这些文档和过程也有助于提高开发效率和软件质量、降低开发成本。
- 软件构件的重用。
- 软件服务的重用。随着Web服务的提出，人们越来越关注服务的重用。SOA面向服务框架提出了面向服务的软件架构，并且定义了相应的标准。但是SOA还不够成熟，相信这一领域在未来的几年中还将取得更大的进展。
构件技术
构件又称为组件，是一个包容、可复用的程序集。首先，构件是一个程序集，或者说是一组程序的集合。这个集合可能会以各种方式体现出来，如源程序或二进制的代码。这个集合整体向外提供统一的访问接口，构件外部只能通过接口来访问构件，而不能直接操作构件的内部。
构件的两个最重要的特征是自包容与可重用。自包容指的是构件的本身是一个功能完整的独立体，构件内部与外部的功能界限清晰明确，可以独立配置与使用。而可重用既是构件的特点，也是构件 出现的目的。使用构件技术实现软件复用，采用搭积木的方式生产软件，就成为软件人员的梦想。
构件的开发者和使用者往往不是相同的人或组织，所以必须定义构件的标准才能够消除其中的障碍。随着构件技术的发展，目前应用比较广泛的构件标准有Java Bean。
基于架构的软件设计
基于架构的软件设计是一种架构驱动方法。
- 功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。
- 通过选择架构风格来实现质量和业务需求。
- 软件模板的使用。软件模板利用了一些软件系统的结构。
软件模板是一个特殊类型的软件元素，包括描述所有这种类型的元素在共享服务和底层构造的基础上如何进行交互。软件模板还包括属于这种类型的所有元素的功能，这些功能的例子有，每个元素必须记录某些重大事件，每个元素必须为运行期间的外部诊断提供测试点等。在软件产品线系统 中，软件模板 显得格外重要，因为新元素的引入是一个通用的技术。这个技术用来使产品线架构适应一个特定的产品。
ABSD方式是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，这有助于降低架构设计的随意性。
ABSD方法与生命周期
ABSD方法在生命周期中的位置。尽管我们没有描述一个需求获取、组织或跟踪的特定方法，但还是假设一个需求阶段至少部分完成，从需求获取（包括功能需求、质量和业务需求、约束）。ABSD方法的输出是三个视图的概念构件的集合，包括能够产生每个概念构件的假设、软件模板的集合和那些已经做出具体实现的决策，我们把具体实现决策当作附加约束来维护。
在ABSD方法中，必须记录所有做出的决策及这些决策的原理，这有利于决策的可跟踪性和决策评审。
ABSD方法的输入由下列部分组成
- 抽象功能需求，包括变化的需求和通用的需求
- 用例（实际功能需求）
- 抽象的质量和业务需求
- 质量因素（实际质量和业务需求）
- 架构选项
- 约束
抽象功能需求
ABSD方法假定需求阶段的输出之一是功能需求的抽象描述，包括这些需求的粗略变化描述。当获取需求时，考虑所有最终用户是重要的。
对一个特定系统来说，通常有不同类型的最终用户。不同的系统管理员（数据库管理员、系统管理员、网络管理员等）都是可以是最终用户。维护工程师也可以是系统的最终用户。总之，一个最终用户就是当系统运行时使用系统的任何人员。
与抽象功能需求相联系的是对公共需求和与这些需求相关的粗略变化的描述，在设计阶段，理解这些需求之间的依赖关系是至关重要的。
我们必须在某些抽象级别上获取功能需求，产品的详细需求往往要等具体产品开发完成后才能知道。当详细需求明确时，抽象功能的获取为详细需求提供了分类。
用例
用例是一个或多个最终用户系统之间的交互的具体表述，在这里，最终用户既可以是操作人员，也可以是与系统进行交互操作的其他软件系统。虽然用例很容易找到和创新，甚至可能有成百上千个，但是，因为我们需求分析用例，所以必须限制用例的数量。在架构设计阶段，只有重要的用例才有用。我们必须对所创建的用例进行分组，设置优先级，以便筛选出最重要的用例，剩下的用例可以在设计阶段的任何时候创建。
抽象的质量和业务需求
必须对待构建系统的质量和业务需求进行编号，每个质量属性都包含一个特定的行为，以及希望得到的结果，质量需求要尽量具体化。
架构选项
对每个质量和业务需求，我们都要列举能够满足该需求的所有可能的架构。例如，如果需求是支持一系列 不同的用户界面，则可能的架构选择就是把不同的用户界面分解成不同的构件。如果需求是保持操作系统的独立性，则可能的架构选择就是构建虚拟的操作系统层，接受所有的操作系统调用，并解释之为当前操作系统所能的支持。
只需要列举所有可能的选项，而不需要对这些架构选项进行决策，这种列举取决于设计师的经验，即可来自某些书籍介绍，也可直接来自设计师本身的实践。
质量场景
用例功能需求具体化一样，质量场景使质量需求具体化。质量场景使质量需求的特定扩充。
和用例一样，质量场景也很容易找到和创建，可以创建很多个。我们必须对质量场景进行分组，设置优先级，只需要验证最重要的质量场景。
约束
约束是一个前置的设计决策，设计过程本身包含决策。某些决策可以直接由业务目标导出而无须考虑对设计的影响。例如，如果一个公司在某个中间件产品上投入大量资金，那么在产品的选择上就可以不必考虑其他决策。在需求获取阶段，约束主要来自系统的业务目标。
在某些特殊情况下，约束由遗留系统决定。今天，几乎没有软件系统不参考已有系统的，常见的情况下，新老系统同时并存，或者新系统替代老系统，但是必须尽可能重用老系统的功能。在设计阶段，虽然这些遗留系统处于被设计系统的外部，但是设计师必须考虑遗留系统的特征。也就是说，在某种程度上，遗留系统影响着当前的设计，因此，理解遗留系统的结构和解决 问题的技术都很重要。出于商业的目的，可能要求重用遗留系统的构件，这种需求就变成了约束。
基于架构的软件开发模型
基于架构的软件开发模型（ABSDM）把整个基于架构的软件过程划分为架构需求、设计、文档化、复审、实现、演化等6个子过程。
架构需求
需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。架构需求受技术环境和架构设计师的经验影响。需求过程主要是获取用户需求，标识系统种所要用到的构件。如果以前有类似的系统架构的需求，我们可以从需求库中取出，加以利用和修改，以节省需求获取的时间，减少重复劳动，提高开发效率。
需求获取
架构需求一般来自三个方面，分别是系统的质量目标，系统的业务目标和系统开发人员的业务目标。软件架构需求获取过程主要是定义开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务上的功能需求。
与此同时，还要获得软件质量属性，满足一些非功能需求。
标识构件
上图所示虚框部分属于标识构件过程，该过程为系统生产初始逻辑结构，包含大致的构件。这一过程又可以分为三步来实现。
第一步：生产类图。生产类图的CASE工具有很多，例如Rational Rose就能生成类图。
第二步：对类进行分组。在生成的类图基础上，使用一些标准对类进行分组可以大大简化类图结构，使之更清晰。一般地，与其他类隔离的类形成一个组，由泛化关联的类组成一个附加组，由聚合或组合关联的类也形成一个附件组。
第三步：把类打包成构件。把在第二步得到的类打包成构件，这些构件可以分组合并成更大的构件。
需求评审
组织一个由不同代表（如分析人员、客户、设计人员、测试人员）组成的小组，对架构需求及相关构件进行仔细的审查。审查的主要内容包括所获取的需求是否真实反映了用户的需求，类的分组是否合理，构件合并是否合理等。
必要时，可以在"需求-标识构件-需求评审"之间进行迭代。
架构设计
架构需求用来激发和调整设计决策，不同的视图被用来表达与质量目标有关的信息。架构设计是一个迭代的过程，如果要开发的系统能够 从已拥有的系统中导出大部分，则可以使用已有系统的设计过程。软件架构设计过程如图：
- 提出软件架构模型
-
- 在建立架构的初期，选择一个合适的架构风格是首要的。在 这个风格基础上，开发人员通过架构模型，可以获得关于架构属性的理解。此时，虽然这个模型是理想化的（其中的某些部分可能错误地表示了应用的特征），但是，该模型为将来的实现和演化过程建立了目标。
- 把已标识的构件映射到软件架构中，把在架构需求阶段已标识的构件映射到架构中，将产生一个中间结构，这个中间结构只包含哪些能明确适合架构模型的构件。
- 分析构件之间的相互作用，为了把所有已标识的构件集成到架构中，必须认真分析这些构件的相互作用和关系。
- 产生软件架构，一旦决定了关键构件之间的关系和相互作用，就可以在第二阶段得到的中间架构的基础上进行细化。
- 设计评审，一旦设计了软件架构，我们必须邀请独立于系统开发的外部人员对架构进行评审。
架构文档
绝大多数的架构都是抽象的，由一些概念上的构件组成。例如，层的概念在任何程序设计语言中都不存在。因此，要让系统分析师和程序员去实现架构，还必须把架构进行文档化。文档是在系统演化的每一个阶段，系统设计与开发人员的通信媒介，是为验证架构设计和提炼或修改这些设计所执行预先分析的基础。
架构文档化过程的主要输出结果是架构需求规格说明和测试架构需求的质量设计说明书这两个文档。生成需求模型构件的精确 的 形式化的描述，作为用户和开发者之间的一个约定。
软件架构的文档要求与软件开发项目中的其他文档是类似的。文档的完整性和质量是软件架构成功的关键因素。文档要从使用者的角度进行编写，必须分发给所有与系统有关的开发人员，并且保证开发者手上的文档是最新的。
架构复审
上图中可以看出，架构设计、文档化和复审是一个迭代的过程。从这方面来说，在一个主版本的软件架构分析之后，要安排一次由外部人员（用户代表和领域专家）参加的复审。
复审的目的是标识潜在的风险，以及早发现架构设计中的缺陷和错误，包括架构能否满足需求、质量需求是否在设计中得到体现、层次是否清晰、构件的划分是否合理、文档表达是否明确、构件的设计是否满足功能与性能的要求，等等
由外部人员进行复审的目的是保证架构的设计能够公正的进行检验，使组织的管理者能够决定正式实现架构。
架构实现
所谓的实现，就是用实体来显示出一个软件架构，即要符合架构所描述的架构性设计决策，分割成规定的构件，按规定方式互相交互。架构的实现过程如图
上图中的虚框部分是架构实现过程。整个实现过程是以复审后的文档化的架构说明书为基础的，每个构件必须满足软件架构中说明的对其他 构件的责任。这些决定即实现的约束是在系统级或项目范围内做出的，每个构件上工作的实现者是看不见的。
在架构说明书中，已经定义了系统中的构件与构件之间的关系。因为在架构层次上，构件接口约束对外唯一地 代表了构件，所以可以从构件库中查找符合接口约束的构件，必要时开发新的满足要求的构件。
然后，按照设计提供的结构，通过组装支持工具把这些 构件的实现体组装起来，完成整个软件系统的连接与合成。
最后一步是测试，包括单个构件的功能性测试和被组装应用的整个功能和性能测试。
架构演化
在构件开发过程中，最终用户 的需求可能还有变动。在软件开发完毕，正常运行后，由一个单位移植到另一个单位，需求也会发生变化。在这种情况下，就必须相应地修改软件架构，以适应新的软件需求。架构演化过程如下图所示。脚骨演化是使用系统演化步骤去修改应用，以满足新的需求。主要包括以下七个步骤。
- 需求变动归类首先必须对用户需求的变化进行分类，使变化的需求与已有构件对应。对找不到对应构件的变动，也要做好标记，在后续的工作中，将创建新的构件，以对应这部分变化的需求。
- 制定架构演化计划在改变原有结构之前，开发组织必须制定一个周密的架构演化计划，作为后续演化开发工作的指南。
- 修改、增加或删除构件在演化计划的基础上，开发人员可根据在第一步得到的需求变动的归类情况，决定是否修改或删除存在的构件、增加新的构件。最后，对修改和增加的构件进行功能性测试。
- 更新构件的相互作用随着构件的增加、删除和修改，构件之间的控制流必须得到更新。
- 构件组装与测试通过组装支持工具把这些构件的实现组装起来，完成整个软件系统的连接与合成，形成新的架构。然后对组装后的系统的整体功能和性能进行测试。
- 技术评审对以上步骤进行确认，进行技术评审。评审组装后的架构是否反映需求变动，符合用户需求。如果不符合，则需要进行2到6步之间进行迭代。
- 产生演化后的架构在原来的系统上所作修改必须集成到原来的架构中，完成一次演化过程。