|
|
|
对于软件项目的开发来说，一个清晰的架构是首要的。即使在初始原型阶段，也不例外。然而，在系统开发的初始阶段就设计好系统的最终结构是不可能的，也是不现实的，因为，需求还在不断地发生变化。所以，一个好的软件架构应该可以创建或再创建功能、用户界面和问题域模型，演化原型以满足新的软件需求。也就是说，软件架构本身也是可演化的，这种演化可基于需求的变化、增进了的对问题域的理解、对实现系统的技术方式的进一步理解的基础上。从这种意义上来说，不但软件系统以原型方式演化，架构本身也以原型方式演化。
|
|
|
|
一个软件系统开发完毕正式投入使用之后，如果要将该系统移植到另一个环境运行，且新环境的需求也有相应的变化时，软件也要进行修改。通常，这种修改所需的工作量与软件需求变化的多少和变化的范围有直接关系。但是，一个好的软件架构能大大减少修改工作量。
|
|
|
|
|
|
基于架构的软件开发过程可以分为独立的两个阶段，这两个阶段分别是实验原型阶段和演化开发阶段。
|
|
|
|
（1）实验原型阶段。这一阶段考虑的首要问题是要获得对系统支持的问题域的理解。为了达到这个目的，软件开发组织需要构建一系列原型，与实际的最终用户一起进行讨论和评审，这些原型应该演示和支持全局改进的实现。但是，来自用户的最终需求是很模糊的，因此，整个第一个阶段的作用是使最终系统更加精确化，有助于决定实际开发的可行性。
|
|
|
|
（2）演化开发阶段。实验原型阶段的结果可以决定是否开始实现最终系统，如果可以，开发将进入第二个阶段。与实验原型阶段相比，演化开发阶段的重点放在最终产品的开发上。这时，原型即被当作系统的规格说明，又可当作系统的演示版本。这意味着演化开发阶段的重点将转移到构件的精确化。
|
|
|
|
虽然实验原型阶段的结果可以决定是否开始实现最终系统，但在实验原型阶段之后，还会有些功能需求不能足够准确地得到表达。然而，系统有哪些组成部分和这些部分该如何相互作用应该是明确的了。
|
|
|
|
在每个阶段中，都必须以一系列的开发周期为单位安排和组织工作，一个开发周期的时间长短可根据软件项目的性质、功能复杂性、开发阶段等因素决定。每一个开发周期都要有不同的着重点，要有一个分析、设计和实现的过程，这个过程取决于当前对系统的理解和前一个开发周期的结果。为了控制开发进度，在每一个开发周期结束时，都必须对当前产品安排一次技术评审，评审组成员由最终用户代表和开发组织的管理人员组成。技术评审的目的是指出当前产品中可能存在的问题，制订下一个开发周期的工作计划。
|
|
|
|
|
|
一般地，实验原型阶段的第一个开发周期没有具体的、明确的目标。此时，为了提高开发效率，缩短开发周期，所有开发人员可以分成了两个小组，一个小组创建图形用户界面，另一个小组创建一个问题域模型。两个小组要并行地工作，尽量不发生相互牵制的现象。
|
|
|
|
在第一个周期结束时，形成了两个版本，一个是图形用户界面的初始设计，主要包括一些屏幕元素，例如窗口、菜单等；另一个是问题域模型，该模型覆盖了问题域的子集。用户界面设计由水平原型表示，也就是说，运行的程序只是实现一些用户界面控制，没有实现真正的系统功能。问题域模型可由一个统一建模语言类图表示，该类图并不是运行的原型的一部分。然而，它并不只是一个简单的类图，可由一个CASE工具（如IBM Rational Rose）自动产生代码，而且，当一个新的元素增加到模型中时，这些代码会自动进行增量更新。
|
|
|
|
第二个开发周期的任务是设计和建立一个软件架构，该架构应该具有以下特征：
|
|
|
|
（1）必须足够灵活，不但能包含现有的元素，而且能包含新增的功能。
|
|
|
|
（2）必须提供一个相当稳定的结构，在这个结构中，原型能在实验原型阶段进行演化。
|
|
|
|
（3）必须支持一个高效的开发组织，允许所有开发人员并行地在原型的基础上进行开发。
|
|
|
|
|
|
（1）标识构件。为系统生成初始逻辑结构，包含大致的构件。这一阶段又可分为3个小步骤：生成类图、对类进行分组、把类打包成构件。
|
|
|
|
（2）提出软件架构模型。在建立架构的初期，选择一个合适的架构风格是首要的。在这个风格基础上，开发人员通过架构模型，可以获得关于架构属性（如程序逻辑结构、开发平台等）的理解。此时，虽然这个模型是理想化的（其中的某些部分可能错误地表示了应用的特征），但是，该模型为将来的调整和演化过程建立了目标。
|
|
|
|
（3）把已标识的构件映射到软件架构中。把在第（1）阶段已标识的构件映射到架构中，将产生一个中间结构，这个中间结构只包含那些能明确适合架构模型的构件。
|
|
|
|
（4）分析构件之间的相互作用。为了把所有已标识的构件集成到架构中，必须认真分析这些构件的相互作用和关系。
|
|
|
|
（5）产生软件架构。一旦决定了关键的构件之间的关系和相互作用，就可以在第（3）阶段得到的中间结构的基础上进行细化。可以利用顺序图标识中间结构中的构件和剩下的构件之间的依赖关系，分析第（2）阶段模型的不一致性（如丢失连接等）。
|
|
|
|
|
|
一旦软件的架构得以确定，就可以开始正式的构件开发工作。在构件开发过程中，最终用户的需求可能还有变动。在软件开发完毕，正常运行后，由一个单位移植到另一个单位，需求也会发生变化。在这两种情况下，就必须使用系统演化步骤去修改应用，以满足新的需求。主要包括以下8个步骤：
|
|
|
|
（1）需求变动归类。首先必须对用户需求的变化进行归类，使变化的需求与已有构件和线索对应。对找不到对应构件和线索的变动，也要作好标记，在后续工作中，将创建新的构件或线索，以对应这部分变化的需求。
|
|
|
|
（2）制订架构演化计划。在改变原有结构之前，开发组织必须制订一个周密的架构演化计划，作为后续演化开发工作的指南。
|
|
|
|
（3）修改、增加或删除构件。在演化计划的基础上，开发人员可根据在第（1）步得到的需求变动的归类情况，决定是否修改或删除存在的构件、增加新构件。
|
|
|
|
（4）更新构件的相互作用。随着构件的增加、删除和修改，构件之间的控制流必须得到更新。
|
|
|
|
（5）产生演化后的架构。在原来系统上所作的所有修改必须集成到原来的架构中。这个架构将作为改变的详细设计和实现的基础。
|
|
|
|
（6）迭代。如果在第（5）步得到的架构还不够详细，不能实现改变的需求，可以把第（3）~（5）步再迭代一次。
|
|
|
|
|
|
（8）对所做的标记进行处理。重新开发新线索中的所有构件，对已有构件按照标记的要求进行修改、删除或更换。完成一次演化过程。
|
|
|
