系统分析师学习笔记（十三）

软件架构设计

构件与软件复用

构件（component）也称为组件，是一个功能相对独立的具有可复用价值的软件单元。在OO方法中，一个构件由一组对象构成，包含了一些协作的类的集合，它们共同工作来提供一种系统功能。

可复用性（可重用性）是指系统和（或）其组成部分能在其他系统中重复使用的程度。软件复用的形式可分为垂直式复用和水平式复用。水平式复用是复用不同应用领域中的软件元素，例如，数据结构、排序算法、人机界面构件等。标准函数库是一种典型的原始的水平式复用机制；垂直式复用是在一类具有较多公共性的应用领域之间复用软件构件。

主流构件标准

目前，主流的构件标准有OMG（Object Management Group，对象管理集团）的CORBA、Microsoft的COM（Component Object Model，构件对象模型）和DCOM（Distributed Component Object Model，分布式构件对象模型）和Sun的EJB（Enterprise JavaBean，Java 企业Bean）。

1.CORBA
CORBA技术规范，主要内容包括接口定义语言（Interface Definition Language，IDL）、接口池（Interface Repository，IR）、动态调用接口（Dynamic Invocation Interface，DII）和对象适配器（Object Adapter，OA）等。

（1）接口定义语言。IDL是CORBA规范中定义的一种中性语言，它用来描述服务器对象（向调用者提供服务的对象）的接口，而不涉及对象的具体实现。IDL本身也是面向对象的，它虽然不是编程语言，但它为客户对象（发出服务请求的对象）提供了语言的独立性，因为客户对象只需了解服务器对象的IDL接口，而不必知道其编程语言。CORBA还定义了IDL到C、C++、SmallTalk和Java语言的映射。
（2）接口池。IR包括分布式计算环境中所有可用的服务器对象的接口表示，它使动态搜索可用服务器的接口、动态构造请求及参数成为可能。
（3）动态调用接口。DII提供了一些标准函数以供客户对象动态创建请求和构造请求参数。客户对象将DII与IR配合使用，可实现服务器对象接口的动态搜索、请求及参数的动态构造与动态发送。当然，只要客户对象在编译之前能够确定服务器对象的IDL接口，CORBA也允许客户对象使用静态调用机制。静态机制的灵活性虽不及动态机制，但执行效率却胜过动态机制。
（4）对象适配器。OA用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便它们使用ORB内部的某些功能，例如，服务器对象的登录与激活、客户请求的认证等。

CORBA定义了一种面向对象的构件开发方法，使不同的应用系统可以共享构件。每个对象都将其内部操作细节封装起来，同时又向外界提供精确定义的接口，从而降低了应用系统的复杂性，也降低了软件开发费用。

2.EJB
EJB是用于开发和部署多层结构的、分布式的、面向对象的Java应用系统的跨平台的构建架构。使用EJB编写的应用程序具有可扩展性和交互性，以及多用户安全的特性。这些应用只需要写一次，就可以发布到任何支持EJB规范的服务器平台上。

3.COM/DCOM
Microsoft的COM定义了构件和它们的客户之间互相作用的方式，使得构件和客户端无需任何中介构件就能相互联系。DCOM扩展了COM，使其能够支持在局域网、广域网甚至Internet上不同计算机的对象之间的通信。

构件获取与管理

1.构件的获取
在基于构件的软件开发中，可以通过多种不同的途径来获取构件：

（1）从现有构件中获得符合要求的构件，直接使用或作适应性修改，得到可复用的构件。
（2）通过遗留工程（legacy engineering），将具有潜在复用价值的构件提取出来，得到可复用的构件。
（3）从市场上购买现成的商业构件，即COTS（Commercial Off-The-Shell）构件。
（4）开发新的符合要求的构件。

企业或项目组在进行以上决策时，必须考虑到不同方式获取构件的一次性成本和以后的维护成本（直接成本和间接成本），然后做出最优的选择。

2.构件的组织
可复用技术对构件库组织方法的要求是：

（1）支持构件库的各种维护动作，例如，增加、删除或修改构件，尽量不要影响构件库的结构。
（2）不仅要支持精确匹配，还要支持相似构件的查找。
（3）不仅能进行简单的语法匹配，而且能够查找在功能或行为方面等价或相似的构件。
（4）对应用领域具有较强的描述能力和较好的描述精度。
（5）库管理员和用户容易使用。

目前，已有的构件分类方法大致可以归纳为三大类，分别是关键字分类法、刻面（facet）分类法和超文本组织方法。

（1）关键字分类法。关键字分类法将应用领域的概念按照从抽象到具体的顺序逐次分解为树形或有向无回路图结构，每个概念用一个描述性的关键字表示。当在构件库中加入新的构件时，库管理员必须对构件的功能或行为进行分析，在浏览已有关键字分类结构的同时，将新构件置于最合适的原子级关键字之下。如果无法找到构件的属主关键字，则可以扩充现有的关键字分类结构，引进新的关键字。
（2）刻面分类法。刻面分类法定义若干用于刻画构件特征的“刻面”，每个面包含若干概念，这些概念描述构件在刻面上的特征。刻面可以描述构件执行的功能、被操作的数据、构件应用的语境或其他特征。描述构件的刻面集合称为刻面描述符，一般而言，刻面描述符不超过7个刻面。
（3）超文本方法。与基于数据库系统的构件库组织方法不同，超文本方法基于全文检索技术，其主要思想是：所有构件必须辅以详尽的功能或行为说明文档；说明中出现的重要概念或构件以网状链接方式相互连接；检索者在阅读文档的过程中可按照人类的联想思维方式任意跳转到包含相关概念或构件的文档；全文检索系统将用户给出的关键字与说明文档中的文字进行匹配，实现构件的浏览式检索。超文本组织方法为开发和复用构件提供了直观的多媒体方式。由于网状结构比较自由、松散，因此，超文本方法比前两种方法更易于修改构件库的结构。

3.人员及权限管理
一般来说，构件库系统可包括五类用户，分别是注册用户、公共用户、构件提交者、普通管理员和超级管理员，他们对构件库分别有不同的职责和权限，这些人员相互协作，共同维护着构件库系统的正常运作。同时，系统为每种操作都定义一个权限，包括提交构件、管理构件、查询构件和下载构件等，每个用户可被赋予其中一项或多项操作权限。

构件复用的方法

1.检索与提取构件

（1）基于关键字的检索。系统在图形用户界面上将构件库的关键字树形结构直观地展示给用户，复用者通过对树形结构的逐级浏览，寻找需要的关键字并提取相应的构件。当然，复用者也可以直接给出关键字（其中可含通配符），由系统自动给出合适的候选构件清单。这种方法的优点是比较简单、易于实现，但在某些场合没有应用价值，因为复用者往往无法用构件库中已有的关键字来描述期望的构件功能或行为，对树形结构的浏览也容易使复用者迷失方向。
（2）刻面检索法。该方法基于刻面分类法，由三步构成，分别是构造查询、检索构件和对构件进行排序。这种方法的优点是它易于实现相似构件的查找，但复用者在构造查询时比较麻烦。
（3）超文本检索法。复用者首先给出一个或数个关键字，系统在构件的说明文档中进行精确或模糊的语法匹配，匹配成功后，向复用者列出相应的构件说明。这种方法的优点是用户界面友好，但在某些情况下复用者难以在超文本浏览过程中正确选取构件。

2.理解与评价构件
逆向工程是理解构件的另一种重要手段。它试图通过对构件的分析，结合领域知识，半自动地生成相应的设计信息，然后借助设计信息完成对构件的理解和修改。

对构件可复用性的评价，是通过收集并分析构件的复用者在实际复用该构件的历史过程中的各种反馈信息来完成的。这些信息包括复用成功的次数、对构件的修改量、构件的健壮性度量和其他性能度量等。

3.修改构件
为了减少构件修改的工作量，要求开发人员尽量使构件的功能、行为和接口设计更为抽象化、通用化和参数化。这样，复用者即可通过对实参的选取来调整构件的功能或行为。如果这种调整仍不足以使构件适用于新系统，复用者就必须借助设计信息和文档来修改构件。因此，与构件有关的文档和抽象层次更高的设计信息对于构件的修改至关重要。

4.构件组装
构件组装技术大致可以分为三种，分别是基于功能的组装技术、基于数据的组装技术和面向对象的组装技术。

（1）基于功能的组装技术。基于功能的组装技术采用子程序调用和参数传递的方式将构件组装起来。它要求库中的构件以子程序/过程/函数的形式出现，并且接口说明必须清晰。当使用这种组装技术进行软件开发时，开发人员首先要对新系统进行功能分解，将系统分解为强内聚、松耦合的功能模块；然后根据各模块的功能需求提取构件，进行适应性修改后，再挂接在上述功能分解框架中。
（2）基于数据的组装技术。基于数据的组装技术首先根据当前软件问题的核心数据结构设计出一个框架，然后根据框架中各结点的需求提取构件并进行适应性修改，再将构件逐个分配至框架中的适当位置。此后，构件的组装方式仍然是传统的子程序调用与参数传递。这种组装技术也要求库中构件以子程序形式出现，但它所依赖的软件设计方法不再是功能分解，而是面向数据的设计方法，例如，Jackson系统开发方法。
（3）面向对象的组装技术。由于封装和继承特征，面向对象方法比其他软件开发方法更适合支持软件复用。在面向对象的软件开发方法中，如果从类库中检索出来的基类能够完全满足新系统的需求，则可以直接应用。否则，必须以基类为父类，生成相应的子类，以满足新系统的需求。

软件架构概述

软件架构研究的主要内容涉及软件架构描述、软件架构风格、软件架构评估和软件架构的形式化方法等。解决好软件的复用、质量和维护问题，是研究软件架构的根本目的。

1.软件架构的意义

（1）架构是项目干系人进行交流的手段。软件架构代表了系统的高层抽象，项目干系人能将它作为建立一个互相理解的基础，形成统一认识，互相交流。不同的项目干系人关心着系统的不同方面，而这些方面都受架构的影响，因此，架构可能是所有项目干系人都关心的一个重要因素。
（2）架构是早期设计决策的体现。软件架构体现了系统的最早的一组设计决策，这些早期的约束比起以后的开发、设计、编码或运行及维护阶段的工作重要得多，对系统生命周期的影响也大得多。早期决策的正确性最难以保证，而且这些决策也最难以改变，影响范围也最大。
（3）架构明确了对系统实现的约束条件。所谓“实现”就是要用实体来显示出一个软件架构，即要符合架构所描述的结构性设计决策，分割成规定的构件，按规定方式互相交互。在具体实现时，必须按照架构的设计，将系统分成若干个组成部分，各部分必须按照预定的方式进行交互，而且每个部分也必须具有架构中所规定的外部特征。这些约束是在系统级或项目范围内作出的，每个构件上工作的实现者是看不见的。这样一来，可以分离关注点，架构设计师不必是算法设计者或精通编程语言，他们只需重点考虑系统的总体权衡（tradeoff）问题，而构件的开发人员在架构给定的约束下进行开发。
（4）架构决定了开发和维护组织的组织结构。架构包含了对系统的最高层次的分解，因此一般被作为任务划分结构的基础。任务划分结构又规定了计划、调度及预算的单位，决定了开发小组内部交流的渠道、配置控制和文件系统的组织、集成与测试计划和过程等。各开发小组按照架构中对各主要构件接口的规定进行交流。一旦进入维护阶段，维护活动也会反映出软件架构，常由不同的小组分别负责对各具体部分的维护。
（5）架构制约着系统的质量属性。小的软件系统可以通过编程或调试措施来达到质量属性的要求，而随着软件系统规模的扩大，这种技巧也将越来越无法满足要求。因为在大型软件系统中，质量属性更多地是由系统结构和功能划分来实现的，而不再主要依靠所选用的算法或数据结构。可以使用对架构的评价来预测系统未来的质量属性，架构评估技术可以对按某架构开发出来的软件产品的质量及缺陷做出比较准确的预测。
（6）架构使推理和控制更改更简单。在整个软件生命周期内，每个架构都将更改划分为三类，分别是局部的、非局部的和架构级的变更。局部变更是最经常发生的，也是最容易进行的，只需修改某一个构件就可以实现。非局部变更的实现则需对多个构件进行修改，但并不改动软件架构。架构级的变更是指会影响各部分的相互关系，甚至要改动整个系统。所以，一个优秀的架构应该能使更改简单易行。
（7）架构有助于循序渐进的原型设计。一旦确定了架构，就可以对其进行分析，并将其按可执行模型来构造原型，以减少项目开发的潜在风险。
（8）架构可以作为培训的基础。在对项目组新成员介绍所开发的系统时，可以首先介绍系统的架构，以及对构件之间如何交互从而实现系统需求的高层次的描述，让项目新成员很快进入角色。
（9）架构是可传递和可复用的模型。软件架构体现了一个相对来说比较小又可理解的模型。软件架构级的复用意味着架构的决策能在具有相似需求的多个系统中发生影响，这比代码级的复用要有更大的好处。通过对架构的抽象，架构设计师能够对一些经过实践证明是非常有效的架构进行复用，从而提高设计的效率和可靠性。

2.软件架构的发展史
纵观软件架构技术的发展过程，从最初的无结构设计到现行的基于架构的软件开发，可以认为经
历了4个阶段：

（1）无架构设计阶段。以汇编语言进行小规模应用程序开发为特征。
（2）萌芽阶段。出现了程序结构设计主题，以控制流图和数据流图构成软件结构为特征。
（3）初级阶段。出现了从不同侧面描述系统的结构模型，以UML为典型代表。
（4）高级阶段。以描述系统的高层抽象结构为中心，不关心具体的建模细节，划分了架构模型与传统软件结构的界限，该阶段以Kruchten提出的“4+1”模型为标志。

软件架构建模

以将软件架构的模型分为五种，分别是结构模型、框架模型、动态模型、过程模型和功能模型。

（1）结构模型：这是一种最直观和最普遍的建模方法，它以构件、连接件和其他概念来刻画架构，并力图通过架构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格和性质等。研究结构模型的核心是架构描述语言。
（2）框架模型：框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的架构。
（3）动态模型：动态模型是对结构模型或框架模型的补充，研究系统的粗粒度行为性质。例如，描述系统的重新配置或演化等，这类系统通常是激励型的。
（4）过程模型：过程模型研究构建系统的步骤和过程。
（5）功能模型：功能模型认为架构是由一组功能构件按层次组成的，下层向上层提供服务。功能模型可以看作是一种特殊的框架模型。

“4+1”视图模型从五个不同的视角来描述软件架构，每个视图只关心系统的一个侧面，五个视图结合在一起才能反映软件架构的全部内容。

（1）逻辑视图。逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在OO技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格，在设计中要注意保持一个单一的、内聚的对象模型贯穿整个系统。
（2）开发视图。开发视图也称为模块视图，在UML中被称为实现视图，它主要侧重于软件模块的组织和管理。开发视图要考虑软件内部的需求，例如，软件开发的容易性、软件复用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统I/O关系的模型图和子系统图来描述。
（3）进程视图。进程视图侧重于系统的运行特性，主要关注一些非功能性需求，例如，系统的性能和可用性等。进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的功能抽象如何适合进程结构等，它也定义了逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。
（4）物理视图。物理视图在UML中被称为部署视图，它主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装和通信等问题。当软件运行于不同的物理节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小化。
（5）场景。场景可以看作是那些重要系统活动的抽象，它使四个视图有机联系起来，从某种意义上说场景是最重要的需求抽象。场景视图对应UML中的用例视图。在开发软件架构时，它可以帮助架构设计师找到构件及其相互关系。同时，架构设计师也可以用场景来分析一个特定的视图，或描述不同视图的构件之间是如何相互作用的。场景可以用文本表示，也可以用图形表示。

软件架构风格

经典架构风格

1.数据流风格
数据流风格包括批处理序列和管道/过滤器两种风格。

（1）批处理序列。构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式传递。
（2）管道/过滤器。每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常是通过对输入数据流的变换或计算来完成的，包括通过计算和增加信息以丰富数据、通过浓缩和删除以精简数据、通过改变记录方式以转化数据和递增地转化数据等。这里的构件称为过滤器，连接件就是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。

2.调用/返回风格

（1）主程序/子程序。单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。过程调用作为交互机制，即充当连接件的角色。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性。
（2）数据抽象和面向对象。这种风格的构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来，对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式，对象是通过函数和过程的调用来交互的。对象具有封装性，一个对象的改变不会影响其他对象。
（3）层次结构。层次系统的构件组织成一个层次结构，连接件通过决定层间如何交互的协议来定义。该风格的特点是每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。在层次结构中，修改某一层，最多影响其相邻的两层（通常只能影响上层）。上层必须知道下层的身份，不能调整层次之间的顺序。

3.独立构件风格
独立构件风格包括进程通信和事件驱动的系统。

（1）进程通信。构件是独立的过程，连接件是消息传递。这种风格的特点是，构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程（方法）调用等。
（2）事件驱动的系统。构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用（implicit invocation）来实现的。基于事件的隐式调用风格的主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便，其缺点是构件放弃了对系统计算的控制。

4.虚拟机风格
虚拟机风格包括解释器和基于规则的系统。

（1）解释器。解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。
（2）基于规则的系统。基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。

5.仓库风格
仓库风格包括数据库系统、黑板系统和超文本系统。

（1）数据库系统。数据库系统是仓库风格最常见的形式。在数据库系统中，构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态；另一类是多个独立处理单元，处理单元对数据元素进行操作。
（2）黑板系统。黑板系统包括知识源、黑板和控制三个部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中，例如，信号处理、问题规划和编译器优化等。
（3）超文本系统。超文本系统中出现的构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。

层次架构风格

1.二层架构
客户机/服务器（Client/Server，C/S）架构是基于资源不对等，且为实现共享而提出来的。与集中式系统相比，C/S架构的优点主要在于，系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。

但随着企业规模的日益扩大，软件的复杂程度不断提高，C/S架构逐渐暴露出以下缺点：

（1）开发成本较高。C/S 架构对客户端软硬件配置要求较高，尤其是软件的不断升级，对硬件要求不断提高，增加了整个系统的成本。
（2）客户端程序设计复杂。采用C/S架构进行软件开发，大部分工作量放在客户端的程序设计上，客户端显得十分庞大。
（3）用户界面风格不一，使用繁杂，不利于推广使用。
（4）软件移植困难。采用不同开发工具或平台开发的软件，一般互不兼容，不能或很难移植到其它平台上运行。
（5）软件维护和升级困难。采用C/S架构的软件要升级，开发人员必须到现场为客户机升级，每个客户机上的软件都需维护。对软件的一个小小改动，每一个客户端都必须更新。
（6）新技术不能轻易应用。因为一个软件平台及开发工具一旦选定，不可能轻易更改。
（7）可扩展性差。C/S架构是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet，软硬件的组合和集成能力有限。客户机的负荷太重，难以管理大量的客户机，系统的性能容易变坏。
（8）系统安全性难以保证。因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。

2.三层C/S架构
与二层C/S架构相比，在三层C/S架构中，增加了一个应用服务器。可以将整个应用逻辑驻留在应用服务器上，而只有表示层存在于客户机上。三层C/S架构将应用系统分成表示层、功能层和数据层三个部分。

与传统的二层架构相比，三层C/S架构具有以下优点：

（1）允许合理地划分三层的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统的可维护性和可扩展性。
（2）允许更灵活、有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层，并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
（3）系统的各层可以并行开发，各层也可以选择各自最适合的开发语言，使之能并行且高效地进行开发，达到较高的性能价格比。对每一层的处理逻辑的开发和维护也会更容易些。
（4）利用功能层可以有效地隔离表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础。

3.B/S架构
浏览器/服务器（Browser/Server，B/S）架构是三层C/S架构的一种实现方式，其具体结构为“浏览器/Web服务器/数据库服务器”。

与C/S架构相比，B/S架构也有许多不足之处，例如，缺乏对动态页面的支持能力，没有集成有效的数据库处理功能；安全性难以控制；采用B/S架构的系统，在数据查询等响应速度上，要远远地低于C/S架构；B/S架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用。

富互联网应用

RIA（Rich Internet Application，富互联网应用）是一个用户接口，它比用HTML实现的接口更加健壮、反应更加灵敏和更具有令人感兴趣的可视化特性。RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性，简化并改进了B/S架构的用户交互

1.RIA的概念
RIA是B/S架构的一种演变，“富”的含义有两种，分别是丰富的数据模型和丰富的用户界面。

RIA 具有C/S架构的特点，包括在消息确认和格式编排方面提供互动用户界面，在无刷新页面之下提供快捷的界面响应时间，提供通用的用户界面特性（例如，拖放操作、在线和离线操作能力等）；RIA也具有B/S架构的特点，包括立即布署、跨平台、采用逐步下载来检索内容和数据，以及可以充分利用广泛采纳的互联网标准。在RIA中，数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。

2.客户端开发技术
支持RIA的平台或工具主要有以下几个：

（1）Flex。Flex是一个表示服务器和应用程序框架，它可以运行于J2EE和.NET平台。Flex应用程序框架由MXML（Macromedia XML）、ActionScript和Flex类库构成。开发人员利用MXML定义应用程序用户界面元素，利用ActionScript定义客户逻辑与程序控制。Flex类库中包括Flex组件、管理器和行为等。应用程序由 Flex服务器翻译成SWF格式的客户端应用程序，在Flash Player中运行。
（2）Bindows。Bindows是用Javascript和DHTML（Dynamic HTML，动态HTML）开发的Web窗口框架。Javascript用于客户端界面的显示和处理，XML和HTTP用于客户端与服务器的信息传输。Bindows的一个主要缺点是，它采用一次性全部载入的方式来实现脚本库，在窗口的加载期，需要一个漫长的等待过程，甚至浏览器的进程会产生无响应的情况。另外，Bindows内部大量利用了IE（Internet Explorer）技术，没有考虑到非IE的浏览器，限制了Bindows的流行。
（3）Java。一些相当复杂的系统都是用Java编写的，这说明可以用Java来建立几乎任何一个能够想象得到的RIA。使用Java建立RIA的主要缺陷是它的复杂性，例如，即使对简单的窗口和图形，也要求编写非常烦琐的代码。
（4）Laszlo。Laszlo 是一个开源的RIA开发环境。使用Laszlo平台时，开发人员只需编写名为LZX的描述语言（其中整合了XML和Javascript），运行在J2EE应用服务器上的Laszlo表示服务器会将其编译成SWF格式的文件并传输给客户端展示。从这点上来说，Laszlo的本质和Flex是一样的。
（5）XUL（XML User Interface Language，基于XML的用户界面语言）。XUL可用于建立窗口应用系统，这些系统既可以在 Mozilla浏览器上运行，也可以在其他描述引擎上运行。XUL描述引擎都非常小，它既可以使用XML数据，也可以生成XML数据。
（6）Avalon。Avalon是Vista的一部分，是一个图形和展示引擎，主要由.NET框架中的一组类集合而成。Avalon定义了一个在Longhorn中使用的新标记语言，其代号为XAML（eXtensibleApplication Markup Language，可扩展应用标记语言）。可以使用XAML来定义文本、图像和控件的布局，程序代码可以直接嵌入到XAML中，也可以将它保留在一个单独的文件内。这与Flex中的MXML或者Laszlo中的LZX非常相似。不同的是，基于Avalon的系统必须运行在Longhorn环境中，而Flex和Laszlo是不依赖于平台的，仅仅需要装有Flash播放器的浏览器即可。

3.异步JavaScript和XML

（1）XML。XML是一套从SGML（Standard Generalized Markup Language，标准通用标记语言）中派生出来的定义语义标记的规则，这些标记将文档分成许多部件并对这些部件加以标识。它也是元标记语言，用于定义其他与特定领域有关的、语义的、结构化的标记语言的句法语言。XML的高扩展性、高灵活性特性，使得其可以描述各种不同种类的应用软件中的各种不同类型的数据，可以实现不同数据的集成。由于XML格式的标准化，许多浏览器软件都能够提供很好的支持，因此，只需简单地将XML格式的数据发送给客户端，客户端就可以自行对其进行编辑和处理，而不仅是显示。
（2）XHTML。XHTML是一个基于XML的标记语言，是一个扮演着类似HTML角色的XML，结合了部分XML的强大功能和大多数HTML的简单特性。建立XHTML的目的就是实现HTML向XML的过渡。
（3）JavaScript。JavaScript是一种粘合剂，使AJAX应用的各部分集成在一起。在AJAX中，JavaScript主要用来传递用户界面上的数据到服务端并返回结果。
（4）XMLHttpRequest。XMLHttpRequest对象用来响应通过HTTP传递的数据，一旦数据返回到客户端，就可以立刻使用DOM将数据显示在网页上。XMLHttpRequest对象在大部分浏览器中已经实现，而且拥有一个简单的接口，允许数据从客户端传递到服务端，但并不会打断用户当前的操作。使用XMLHttpRequest传送的数据可以是任何格式的。
（5）DOM。DOM为XML文档的已解析版本定义了一组接口。解析器读入整个文档，构建一个驻留内存的树结构，然后代码就可以使用DOM接口来操作这个树结构。
（6）XSLT。XSLT 是一种将XML文档转换为XHTML文档或其他XML文档的语言，可以用在客户端和服务端，它能够减少大量的用JavaScript编写的应用逻辑。
（7）CSS。一个CSS样式单就是一组规则，样式再根据特定的一套规则级联起来。每个规则给出其所适用的元素名称，以及要应用于哪些元素的样式。CSS提供了从内容中分离应用样式和设计的机制。虽然CSS在AJAX应用中扮演至关重要的角色，但它也是构建跨浏览器应用的一大阻碍，因为不同的浏览器厂商支持各种不同的CSS级别。

使用AJAX的最大优点，就是能在不更新整个页面的前提下维护数据，这使得Web系统更为迅捷地回应用户动作，并避免了在网络上发送那些没有改变过的信息。进行AJAX开发时，需要慎重考虑网络延迟。不给予用户明确的回应，没有恰当的预读数据，或者对XMLHttpRequest的不恰当处理，都会使用户感到延迟。

面向服务的架构（Service-Oriented Architecture，SOA）

许多组织从不同的角度和不同的侧面对SOA进行了描述，较为典型的有以下三个：

（1）W3C的定义：SOA是一种应用程序架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。
（2）Service-architecture.com的定义：服务是精确定义、封装完善、独立于其它服务所处环境和状态的函数。SOA本质上是服务的集合，服务之间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务之间需要某些方法进行连接。
（3）Gartner的定义：SOA是一种C/S架构的软件设计方法，应用由服务和服务使用者组成，SOA与大多数通用的C/S架构模型不同之处，在于它着重强调构件的松散耦合，并使用独立的标准接口。

SOA概述

在SOA模型中，所有的功能都定义成了独立的服务。服务之间通过交互和协调完成业务的整体逻辑。所有的服务通过服务总线或流程管理器来连接。

1.服务的基本结构
服务模型的表示层从逻辑层分离出来，中间增加了服务对外的接口层。通过服务接口的标准化描述，使得服务可以提供给在任何异构平台和任何用户接口使用。

2.SOA设计原则
关于服务，一些常见的设计原则如下：

（1）明确定义的接口。服务请求者依赖于服务规约来调用服务，因此，服务定义必须长时间稳定，一旦公布，不能随意更改；服务的定义应尽可能明确，减少请求者的不适当使用；不要让请求者看到服务内部的私有数据。
（2）自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和构件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
（3）粗粒度。服务数量不应该太多，依靠消息交互而不是远程过程调用，通常消息量比较大，但是服务之间的交互频度较低。
（4）松耦合。服务请求者可见的是服务的接口，其位置、实现技术、当前状态和私有数据等，对服务请求者而言是不可见的。
（5）互操作性、兼容和策略声明。为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，例如，一个服务对安全性方面的要求；也可以是与业务有关的语义方面的内容，例如，需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。

3.服务构件与传统构件
服务构件架构（Service Component Architecture，SCA）是基于SOA的思想描述服务之间组合和协作的规范，它描述用于使用SOA构建应用程序和系统的模型。

SCA服务构件与传统构件的主要区别在于，服务构件往往是粗粒度的，而传统构件以细粒度居多；服务构件的接口是标准的，主要是服务描述语言接口，而传统构件常以具体API形式出现；服务构件的实现与语言是无关的，而传统构件常绑定某种特定的语言；服务构件可以通过构件容器提供QoS的服务，而传统构件完全由程序代码直接控制。

SOA的关键技术

1.UDDI
UDDI（Universal Description Discovery and Integration，统一描述、发现和集成）提供了一种服务发布、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它。

在UDDI技术规范中，主要包含以下三个部分的内容：

（1）数据模型。UDDI数据模型是一个用于描述业务组织和服务的XML Schema。
（2）API。UDDI API是一组用于查找或发布UDDI数据的方法，UDDI API基于SOAP。
（3）注册服务。UDDI注册服务是SOA中的一种基础设施，对应着服务注册中心的角色。

2.WSDL
WSDL（Web Service Description Language，Web服务描述语言）是对服务进行描述的语言，它有一套基于XML的语法定义。

3.SOAP
SOAP（Simple Object Access Protocol，简单对象访问协议）定义了服务请求者和服务提供者之间的消息传输规范。SOAP用XML来格式化消息，用HTTP来承载消息。SOAP主要包括以下四个部分：

（1）封装。SOAP封装定义了一个整体框架，用来表示消息中包含什么内容，谁来处理这些内容，以及这些内容是可选的还是必须的。
（2）编码规则。SOAP编码规则定义了一种序列化的机制，用于交换系统所定义的数据类型的实例。
（3）RPC表示。SOAP RPC表示定义了一个用来表示远程过程调用和应答的协议。
（4）绑定。SOAP绑定定义了一个使用底层传输协议来完成在节点之间交换SOAP封装的约定。

SOAP消息包括以下三个部分：

（1）封装（信封）。封装的元素名是Envelope，在表示消息的XML文档中，封装是顶层元素，在SOAP消息中必须出现。
（2）SOAP头。SOAP头的元素名是Header，提供了向SOAP消息中添加关于这条SOAP消息的某些要素的机制。SOAP定义了少量的属性用来表明这项要素是否可选以及由谁来处理。SOAP头在SOAP消息中可能出现，也可能不出现。如果出现的话，必须是SOAP封装元素的第一个直接子元素。
（3）SOAP体。SOAP体的元素名是Body，是包含消息的最终接收者想要的信息的容器。SOAP体在SOAP消息中必须出现且必须是SOAP封装元素的直接子元素。如果有头元素，则SOAP体必须直接跟在SOAP头元素之后；如果没有头元素，则SOAP体必须是SOAP封装元素的第一个直接子元素。

4.REST
REST（Representational State Transfer，表述性状态转移）是一种只使用HTTP和XML进行基于Web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。REST提出了如下一些设计概念和准则：

（1）网络上的所有事物都被抽象为资源。
（2）每个资源对应一个唯一的资源标识。
（3）通过通用的连接件接口对资源进行操作。
（4）对资源的各种操作不会改变资源标识。
（5）所有的操作都是无状态的。

SOA的实现方法

目前，实现SOA的方法也比较多，其中主流方式有Web Service、企业服务总线和服务注册表。

1.Web Service
在Web Service（Web服务）的解决方案中，一共有三种工作角色，其中服务提供者和服务请求者是必须的，服务注册中心是一个可选的角色。

Web Service模型中的操作包括发布、查找和绑定，这些操作可以单次或反复出现。

（1）发布。为了使用户能够访问服务，服务提供者需要发布服务描述，以便服务请求者可以查找它。
（2）查找。在查找操作中，服务请求者直接检索服务描述或在服务注册中心查询所要求的服务类型。对服务请求者而言，可能会在生命周期的两个不同阶段中涉及到查找操作，首先是在设计阶段，为了程序开发而查找服务的接口描述；其次是在运行阶段，为了调用而查找服务的位置描述。
（3）绑定。在绑定操作中，服务请求者使用服务描述中的绑定细节来定位、联系并调用服务，从而在运行时与服务进行交互。绑定可以分为动态绑定和静态绑定。在动态绑定中，服务请求者通过服务注册中心查找服务描述，并动态地与服务交互；在静态绑定中，服务请求者已经与服务提供者达成默契，通过本地文件或其他方式直接与服务进行绑定。

在采用Web Service作为SOA的实现技术时，应用系统大致可以分为六个层次，分别是底层传输层、服务通信协议层、服务描述层、服务层、业务流程层和服务注册层。

（1）底层传输层。底层传输层主要负责消息的传输机制，HTTP、JMS（Java MessagingService，Java消息服务）和SMTP都可以作为服务的消息传输协议，其中HTTP使用最广。
（2）服务通信协议层。服务通信协议层的主要功能是描述并定义服务之间进行消息传递所需的技术标准，常用的标准是SOAP和REST协议。
（3）服务描述层。服务描述层主要以一种统一的方式描述服务的接口与消息交换方式，相关的标准是WSDL。
（4）服务层。服务层的主要功能是将遗留系统进行包装，并通过发布的WSDL接口描述被定位和调用。
（5）业务流程层。业务流程层的主要功能是支持服务发现，服务调用和点到点的服务调用，并将业务流程从服务的底层调用抽象出来。
（6）服务注册层的主要功能是使服务提供者能够通过WSDL发布服务定义，并支持服务请求者查找所需的服务信息。相关的标准是UDDI。

2.服务注册表
大多数商用服务注册产品支持服务注册、服务位置和服务绑定功能。

（1）服务注册。服务注册是指服务提供者向服务注册表发布服务的功能（服务合约），包括服务身份、位置、方法、绑定、配置、方案和策略等描述性属性。使用服务注册表实现SOA时，要限制哪些新服务可以向注册表发布、由谁发布以及谁批准和根据什么条件批准等，以便使服务能够有序的注册。
（2）服务位置。服务位置是指服务使用者，帮助它们查询已注册的服务，寻找符合自身要求的服务。这种查找主要是通过检索服务合约来实现的，在使用服务注册表实现SOA时，需要规定哪些用户可以访问服务注册表，以及哪些服务属性可以通过服务注册表进行暴露等，以便服务能得到有效的、经过授权的使用。
（3）服务绑定。服务使用者利用查找到的服务合约来开发代码，开发的代码将与注册的服务进行绑定，调用注册的服务，以及与它们实现互动。可以利用集成的开发环境自动将新开发的服务与不同的新协议、方案和程序间通信所需的其他接口绑定在一起。

3.企业服务总线
具体来说，ESB具有以下功能：

（1）支持异构环境中的服务、消息和基于事件的交互，并且具有适当的服务级别和可管理性。
（2）通过使用ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使现有系统具有全新的服务接口，并能够在部署环境中支持任何标准。
（3）充当缓冲器的ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑相分离，从而使不同的系统可以同时使用同一个服务，用不着在系统或数据发生变化时，改动服务代码。
（4）在更高的层次，ESB还提供诸如服务代理和协议转换等功能。允许在多种形式下通过像HTTP、SOAP和JMS总线的多种传输方式，主要是以网络服务的形式，为发表、注册、发现和使用企业服务或界面提供基础设施。
（5）提供可配置的消息转换翻译机制和基于消息内容的消息路由服务，传输消息到不同的目的地。
（6）提供安全和拥有者机制，以保证消息和服务使用的认证、授权和完整性。

ESB具有以下优势：

（1）扩展的、基于标准的连接。ESB形成一个基于标准的信息骨架，使得在系统内部和整个价值链中可以容易地进行异步或同步数据交换。ESB通过使用XML、SOAP和其他标准，提供了更强大的系统连接性。
（2）灵活的、服务导向的应用组合。基于SOA，ESB使复杂的分布式系统（包括跨多个应用、系统和防火墙的集成方案）能够由以前开发测试过的服务组合而成，使系统具有高度可扩展性。
（3）提高复用率，降低成本。按照SOA方法构建应用，提高了复用率，简化了维护工作，进而减少了系统总体成本。
（4）减少市场反应时间，提高生产率。ESB通过构件和服务复用，按照SOA的思想简化应用组合，基于标准的通信、转换和连接来实现这些优点。

软件架构评估

架构评估概述

敏感点是一个或多个构件（和/或构件之间的关系）的特性，权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。

从目前已有的软件架构评估技术来看，可以归纳为三类主要的评估方式，分别是基于调查问卷（或检查表）的方式、基于场景的方式和基于度量的方式。

1.基于调查问卷（或检查表）的评估方式
这一评估方式比较自由灵活，可评估多种质量属性，也可以在软件架构设计的多个阶段进行。但是，由于评估的结果很大程度上来自评估人员的主观推断，因此，不同的评估人员可能会产生不同甚至截然相反的结果，而且评估人员对领域的熟悉程度、是否具有丰富的相关经验也成为评估结果是否正确的重要因素。

2.基于场景的评估方式
基于场景的方式主要应用在架构权衡分析法（Architecture Tradeoff Analysis Method，ATAM）、软件架构分析法（Software Architecture Analysis Method，SAAM）和成本效益分析法（Cost Benefit Analysis Method，CBAM）中。在架构评估中，一般采用刺激（stimulus）、环境（environment）和响应（response）三方面来对场景进行描述。

基于场景的评估方式是特定于领域的。这一评估方式的实施者一方面需要有丰富的领域知识，以对某一质量需求设计出合理的场景；另一方面，必须对待评估的软件架构有一定的了解，以准确判断它是否支持场景描述的一系列活动。

3.基于度量的评估方式
度量是指为软件产品的某一属性所赋予的数值。基于度量的评估技术都涉及三个基本活动。首先，需要建立质量属性和度量之间的映射原则，即确定怎样从度量结果推导出系统具有什么样的质量属性；然后，从软件架构文档中获取度量信息；最后，根据映射原则分析、推导出系统的某些质量属性。基于度量的评估方式提供更为客观和量化的质量评估，需要在软件架构的设计基本完成以后才能进行，而且需要评估人员对待评估的架构十分了解，否则不能获取准确的度量。

ATAM评估方法

1.评估参与者
在ATAM方法中，参加评估的人员主要有评估小组、项目决策者和其他项目干系人。

（1）评估小组。该小组是所评估架构项目外部的小组，通常由3～5人组成，他们可能是开发组织内部的，也可能是外部的。评估小组的每个成员都要扮演大量的特定角色。
（2）项目决策者。项目决策者对开发项目具有发言权，并有权要求进行某些改变，他们包括项目管理人员、重要的客户代表和架构设计师等。
（3）项目干系人。包括关键模块开发人员、测试人员和用户等。

2.评估活动
整个ATAM评估过程包括九个步骤：

（1）描述ATAM方法。评估小组负责人向参加会议的项目干系人介绍ATAM评估方法。在这一步中，要解释每个人将要参与的过程，并预留出解答疑问的时间，设置好其他活动的环境和预期结果。关键是要使每个人都知道要收集哪些信息，如何描述这些信息，将要向谁报告等。
（2）描述业务动机。项目决策者从业务的角度介绍系统的概况。该描述应该包括系统最重要的功能、技术/管理/经济和政治方面的任何相关限制、与该项目相关的业务目标和上下文、主要的项目干系人，以及架构的驱动因素等。参加评估的所有人员必须理解待评估的系统。
（3）描述架构。首席设计师或设计小组要对架构进行详略适当的介绍，至少应该包括技术约束（例如，操作系统、硬件和中间件等）、将与本系统进行交互的其他系统、用以满足质量属性要求的架构方法等。这一步很重要，将直接影响到可能要做的分析及分析的质量。
（4）确定架构方法。ATAM评估方法主要通过理解架构方法来分析架构，在这一步，由架构设计师确定架构方法，由分析小组捕获，但不进行分析。
（5）生成质量属性效用树。评估小组、设计小组、管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些质量目标设置优先级和细化。这一步很关键，它对以后的分析工作起指导作用。即使是架构级的分析，也不一定是全局的，所以，需要集中所有相关人员的精力，注意架构的各个方面，这通常是通过构建效用树的方式来实现的。效用树的输出结果是对具体质量属性需求的优先级的确定，这种优先级列表为ATAM评估方法的后面几步提供了指导，它告诉评估小组应该把有限的时间花在哪里，特别是应该到哪里去考察架构的方法与相应的风险、敏感点和权衡点。
（6）分析架构方法。一旦有了效用树的结果，评估小组可以对实现重要质量属性的架构方法进行考察。这是通过文档化这些架构决策和确定它们的风险、敏感点和权衡点等来实现的。在这一步中，评估小组要对每一种架构方法都考察足够的信息，完成与该方法有关的质量属性的初步分析。这一步的主要结果是一个架构方法或风格的列表，与之相关的一些问题，以及设计师对这些问题的回答。通常产生一个风险列表、敏感点和权衡点列表。在这一步结束时，评估小组应该对整个架构的绝大多数重要方面所做出的关键设计决策、风险列表、敏感点、权衡点有一个清楚的认识。
（7）讨论场景和对场景分级。场景在驱动ATAM测试阶段起主导作用。项目干系人进行两项相关的活动，分别是集体讨论用例场景和改变场景。用例场景是场景的一种，在用例场景中，项目干系人是一个终端用户，使用系统执行的一些功能。一旦收集了若干个场景后，必须设置优先级。评估人员通过投票表决的方式来完成，每个项目干系人分配相当于总场景数的30%的选择，且此数值只入不舍。
（8）分析架构方法。在收集并分析了场景之后，设计师就可把最高级别的场景映射到所描述的架构中，并对相关的架构如何有助于该场景的实现做出解释。在这一步中，评估小组要重复第6步中的工作，把新得到的最高优先级场景与尚未得到的架构工作产品对应起来。在第7步中，如果未产生任何在以前的分析步骤中都没有发现的高优先级场景，则在第8步就是测试步骤。
（9）描述评估结果。最后，要把ATAM分析中所得到的各种信息进行归纳，并反馈给项目干系人。这种描述一般要采用辅以幻灯片的形式，但也可以在ATAM评估结束之后，提交更完整的书面报告。在描述过程中，评估负责人要介绍ATAM评估的各个步骤，以及各步骤中得到的各种信息，包括业务环境、驱动需求、约束条件和架构等。最重要的是要介绍ATAM评估的结果。ATAM的评估结果包括一个简洁的架构描述、表达清楚的业务目标、用场景集合捕获的质量属性、所确定的敏感点和权衡点的集合、有风险决策和无风险决策、风险主题的集合。

3.CBAM评估方法
CBAM的评估步骤大致如下：

（1）整理场景。整理ATAM中获取的场景，根据业务目标确定这些场景的优先级，并选取优先级最高的1/3的场景进行分析。
（2）对场景进行细化。为每个场景获取最坏情况、当前情况、期望情况和最好情况的质量属性响应级别。
（3）确定场景的优先级。项目干系人对场景进行投票，其投票是基于每个场景所期望的响应值，根据投票结果和票的权值，生成一个分值（场景的权值）。
（4）分配效用。对场景的响应级别确定效用表，根据架构策略涉及哪些质量属性及响应级别，形成相关的“策略-场景-响应级别”的对应关系。
（5）确定期望的质量属性响应级别的效用。即根据第（4）步的效用表及其对应关系，确定架构策略及其对应场景的效用表。
（6）计算各架构策略的总收益。根据第（3）步的场景的权值和第（5）步的架构策略效用表，计算出架构策略的总收益得分。
（7）根据受成本限制影响的投资收益率选择架构策略。根据开发经验估算架构策略的成本，结合第（6）步的收益，计算出架构策略的投资收益率，按投资收益率排序，从而确定选取策略的优先级。

SAAM评估方法

1.评估活动
SAAM比较简单，这种方法易学易用，进行培训和准备的工作量都比较少。SAAM评估可以分六个步骤进行：

（1）形成场景。在形成场景的的过程中，要注意全面捕捉系统的主要用途、系统用户类型、系统将来可能的变更、系统在当前及可预见的未来必须满足的质量属性等信息。只有这样，形成的场景才能代表与各种项目干系人相关的任务。形成场景是通过集中讨论来实现的，使项目干系人在一个友好的氛围中提出一些场景，这些场景反映了他们的需求，也体现了他们对架构将如何实现需求的认识。
（2）描述架构。在这一步，架构设计师应该采用参加评估的所有人员都能够充分理解的形式，对待评估的架构进行适当的描述。这种描述必须要说明系统中的运算和数据构件，以及它们之间的联系。除了要描述这些静态特性外，还要对系统在某段时间内的动态特征做出说明。描述既可采用自然语言，也可采用形式化的手段。
（3）场景的分类和优先级确定。场景可分为直接场景和间接场景（潜在场景）。直接场景是按照现有架构开发出来的系统能够直接实现的场景。与在设计时已经考虑过的需求相对应的直接场景能增进对架构的理解，促进对诸如性能和可靠性等其他质量属性的研究；间接场景就是需要对现有架构做某些修改才能支持的场景。间接场景对衡量架构对系统在演化过程中将出现的变更的适用情况十分关键。通过各种间接场景对架构的影响，可以确定架构在相关系统的生命周期内对不断演化的使用的适应情况。直接场景类似于用例，而间接场景有时也叫变更案例。评估人员通过对场景设置优先级，可以保证在评估的有限时间内考虑最重要的场景。这里的“重要”完全是由项目干系人及其所关心的问题确定的。项目干系人可以通过投票表达所关心的问题。
（4）对场景进行单个评估。一旦确定了要考虑的一组场景，就要把这些场景与架构的描述对应起来。对于直接场景而言，架构设计师需要讲清所评估的架构将如何执行这些场景；对于间接场景而言，设计师应说明需要对架构做哪些修改才能适应间接场景的要求。
（5）评估场景的相互作用。场景的相互作用暴露了设计方案中的功能分配。场景相互作用的多少与结构复杂性、耦合度、内聚性有关。同时，场景的相互作用能够暴露出架构设计文档未能充分说明的结构分解。
（6）形成总体评估。最后，评估人员要对场景和场景之间的交互作一个总体的权衡和评价，这一权衡反映组织对表现在不同场景中的目标的考虑优先级。根据对系统成功的相对重要性来为每个场景设置一个权值，权值的确定通常要与每个场景所支持的业务目标联系起来。

2.评估结果
SAAM评估的主要有形输出包括以下两个方面：

（1）把代表了未来可能做的更改的场景与架构对应起来，显现出架构中未来可能会表现出较高复杂性的地方，并对每个这样的更改的预期工作量做出评估。
（2）理解系统的功能，对多个架构所支持的功能和数量进行比较。

软件产品线

软件产品线主要由两部分组成，分别是核心资源和产品集合。核心资源是领域工程的所有结果的集合，是产品线中产品构造的基础。核心资源必定包含产品线中所有产品共享的产品线架构，新设计开发的或者通过对现有系统的再工程得到的、需要在整个产品线中系统化复用的构件。与构件相关的测试计划、测试实例以及所有设计文档，需求说明书、领域模型、领域范围的定义，以及采用COTS的构件也属于核心资源。

产品线的过程模型

软件产品线的过程模型主要有双生命周期模型、SEI模型和三生命周期模型。

1.双生命周期模型
领域工程阶段的主要任务有：

（1）领域分析。利用现有系统的设计、架构和需求建立领域模型。
（2）领域设计。用领域模型确定领域/产品线的共性和可变性，为产品线设计架构。
（3）领域实现。基于领域架构开发领域可复用资源，例如，构件、文档和代码生成器等。

应用工程在领域工程结果的基础上构造新产品。应用工程需要根据每个应用独特的需求，经过以下阶段，生成新产品：

（1）需求分析。将系统需求与领域需求比较，划分成领域公共需求和独特需求两部分，得出系统需求规格说明书。
（2）系统设计。在领域架构基础上，结合系统独特需求，设计应用的软件架构。
（3）系统实现。遵照应用架构，用领域可复用资源实现领域公共需求，用定制开发的构件满足系统独特需求，构建新的系统。

2.SEI模型
SEI将产品线的基本活动分为三个部分，分别是核心资源开发（即领域工程）、产品开发（即应用工程）和管理。

SEI模型的主要特点如下：

（1）循环重复是产品线开发过程的特征，也是核心资源开发、产品线开发，以及核心资源和产品之间协作的特征。
（2）核心资源开发和产品开发没有先后之分。
（3）管理活动协调整个产品线开发过程的各个活动，对产品线的成败负责。
（4）核心资源开发和产品开发是两个互动的过程，三个活动和整个产品线开发之间也是双向互动的。

3.三生命周期模型
三生命周期模型为有多个产品线的大型企业增加了企业工程（enterprise engineering）流程，以便在企业范围内对所有资源的创建、设计和复用提供合理的规划。

产品线的建立方式

1.将现有产品演化为产品线
在基于现有产品架构设计的产品线架构的基础上，将特定产品的构件逐步地、越来越多地转化为产品线的共用构件，从基于产品的方法“慢慢地”转化为基于产品线的软件开发。

2.用软件产品线替代现有产品集
基本停止现有产品的开发，所有工作直接针对软件产品线的核心资源开发。遗留系统只有在符合架构和构件需求的情况下，才可以和新的构件协作。

3.全新软件产品线的演化
演化方式将每一个新产品的需求与产品线核心资源进行协调。

4.全新软件产品线的开发
设计师和开发工程师首先要得到产品线所有可能的需求，基于这个需求超集来设计和开发产品线核心资源。第一个产品将在产品线核心资源全部完成之后才开始构建。

软件产品线的发展过程有三个阶段，分别是开发阶段、配置分发阶段和演化阶段。引起产品线架构演化的原因与引起任何其他系统演化的原因一样：产品线与技术变化的协调、现有问题的改正、新功能的增加、对现有功能的重组以允许更多的变化等。产品线的演化包括产品线核心资源的演化、产品的演化和产品的版本升级。

不管采用哪种产品线的建立方式，企业要成功实施产品线，主要取决于以下因素：

（1）对要实施产品线的领域具备长期和深厚的经验。
（2）一个用于构建产品的好的核心资源库。
（3）好的产品线架构。
（4）好的管理（包括软件资源、人员组织和过程等）支持。