软件体系结构

架构定义:某个软件或计算系统的软件构架是该系统的一个或多个结构，它由软件元素、这些元素的外部可见属性以及这些元素之间的关系组成。

2.含义：

•首先，构架定义了软件元素。构架必须省略元素中与其交互无关的某些信息

•第二，该定义明确指出系统可能而且确实由多个结构组成。–其中任何一个结构并不能与构架等同–结构的多重性是理解软件构架的关键

•第三，该定义意味着具有软件的每个计算系统都有一个软件构架。–每个软件系统都可以看成由若干个元素及其相互联系构成

•第四，只要某个元素的行为可以从其他元素的角度观察到或区别开，这个元素的行为就是构架的内容。–这种行为使各元素的交互成为可能，是构架的一部分

3.软件体系结构异构的方式,特点？  

异构的方式：一种方式是使用层次结构，一个系统构件被组织成某种体系结构风格，但它的内部结构可能是另一种完全不同的风格。第二种组合风格的方式是，允许单一构件使用复合的连接件。比如一个构件可能通过它的接口访问知识库，但通过管道与系统中其他构件进行交互，又通过其他接口接受控制信息。第三种组合方法是用完全不同的软件体系结构风格对一个系统水平的软件体系结构进行描述。

4、构件：构件是计算或数据储存的单元；构件定义：构件是指语义完整、语法正确和有可复用价值的单位软件，是软件复用过程中可以明确辨识的元素；结构上，它是语义描述、通讯接口和实现代码的复合体。5、连接件：连接件是构件之间的交互和指导这些交互的规则进行建模的体系结构元素

软件体系结构（构架）研究的问题

•结构性问题•系统的组织，由哪些组件构成•全局性的控制结构•通讯、同步或访问的协议

•将功能分配到不同的系统组成部分•设计元素的组成•系统的物理分布•可扩展性、性能

（要求：要弄清哪些方面的问题是属于构架的，哪些方面的问题是不属于构架的）

常见的架构风格

一、什么是软件架构风格

软件体系结构风格描述某一特定应用领域中系统组织方式的惯用模式，以结构组织模式定义了一个系统家族a)关于构件和连接件类型的术语词汇表b)一组约束它们组合方式的规定

c)一个或多个语义模型，规定了如何从各成分的特性决定系统整体特性。

概括地说，一种软件体系结构风格刻画一个具有共享结构和语义的系统家族

二、常见的架构风格

–管道和过滤器模式–数据抽象/面向对象模式–基于事件的模式–分层模式–仓库（Repository)模式–解释器模式–过程控制–C/S, B/S–特点, 不变式, 优点, 缺点

答：比较典型的体系结构风格有：

数据流风格 (Dataflow)：批处理序列、管道－过滤器风格 (Pipe-and-Filter)

调用/返回风格：主程序/子程序、面向对象风格 (ADT)、层次系统(Layered Systems)

独立构件风格：进程通信、事件系统

虚拟机风格：解释器、基于规则的系统

仓库风格：数据库系统、超文本系统、黑板系统

1、–管道和过滤器模式

•    每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了

•    优点：1：使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；2：允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；3：支持软件复用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；4：系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；5：允许对一些如吞吐量、死锁等属性的分析6：支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行

•    缺点：1通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换；2不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重； 3因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。

2、数据抽象和面向对象组织

•    这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。

•    优点：因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其它的对象；设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。缺点：1，为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象；2，必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的。

3、基于事件的隐式调用

•    构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。

•    这种风格的构件是一些模块，模块既可以是一些过程，又可以是一些事件的集合。过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。

•    这种风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。

•    优点1：为软件复用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。2：为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其它构件的接口。缺点1：构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被 调用的顺序。2：数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。3：既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。

4、分层系统

•    层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机（在另一些层次系统中层是部分不透明的）。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。

•    这种风格支持基于可增加抽象层的设计。允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持

•    实例:分层通信协议，每一层提供一个抽象的功能作为上层通信的基础，较低层次定义低层的交互，最底层通常只定义物理连接

•    优点1:支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解；2:支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层；3:支持复用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。缺点:1:并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；2:很难找到一个合适的、正确的层次抽象方法。

5、仓库系统及知识库

•    在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据上执行，仓库与外构件间的相互作用在系统中会有大的变化。

•    控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程执行的选择，则仓库是一传统型数据库；另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统。

•    实例:信号处理领域，如语音和模式识别;松耦合数据共享

•    黑板系统的组成

–  知识源：知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通信，它们之间的通信通过黑板来完成

–  黑板数据结构：黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题

–  控制：控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识

6、C2

•    通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：1:系统中的构件和连接件都有一个顶部和一个底部；2:构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；3:一个连接件可以和任意数目的其它构件和连接件连接4:当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

•    C2风格的特点

–  系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起；

–  所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的；

–  构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。

7、客户/服务器风格

•    基本概念

1:C/S软件体系结构是基于资源不对等，且为实现共享而提出来的，是20世纪90年代成熟起来的技术，C/S体系结构定义了工作站如何与服务器相连，以实现数据和应用分布到多个处理机上。2:C/S体系结构有三个主要组成部分：数据库服务器、客户应用程序和网络。

•    优点:1:C/S体系结构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。2:系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。3:系统中的功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，而数据库服务器的开发则集中于数据的管理，不必在每一个新的应用程序中都要对一个DBMS进行编码。将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。

•    缺点:1:开发成本较高2:客户端程序设计复杂3:信息内容和形式单一4:用户界面风格不一，使用繁杂，不利于推广使用5:软件移植困难6:软件维护和升级困难7:新技术不能轻易应用

8、三层客户/服务器风格

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

•    要注意的问题1:三层C/S结构各层间的通信效率若不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。2:设计时必须慎重考虑三层间的通信方法、通信频度及数据量。这和提高各层的独立性一样是三层C/S结构的关键问题

9、浏览器/服务器风格

•    基本概念

–  浏览器/服务器（B/S）风格就是上述三层应用结构的一种实现方式，其具体结构为：浏览器/Web服务器/数据库服务器。B/S体系结构主要是利用不断成熟的WWW浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本。从某种程度上来说，B/S结构是一种全新的软件体系结构。

•    优点1:基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。2:B/S体系结构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。缺点1:B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能2:B/S体系结构的系统扩展能力差，安全性难以控制。3:采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远地低于C/S体系结构。4:B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理(OLTP)应用。

构架风格vs 设计模式

	构架风格	设计模式
联系	构架风格可以被看作是种模式（模式语言） 对于特定的风格，可能存在一组习惯用法
区别	1:为建立在某一特定领域的一大类构架提供指导和分析 2:为良好的s/w构架家族提供语言和框架 3:被认为是一种建筑模式的语言	使用特定风格着重解决比较小而且比较具体的问题

 •影响构架的因素包括哪些？

软件构架是技术、商业和社会等诸多因素共同作用的结果。

1:受系统涉众影响,如开发组织的涉众,市场营销组织的涉众,最终用户的涉众, 维护组织的涉众.2:受开发组织的影响;3:受设计师的素质和经验的影响;4:受技术环境的影响;

什么样的构架才算好?

•什么样的架构是一个好的架构?

软件开发过程的建议设计架构的建议，如何设计架构？

1：架构的设计应该由一位设计师来完成，或者设计师领导的小组完成。

2：在设计架构之前应该全面掌握系统的功能需求，并且应有一份所设计架构应满足的划分了优先级的质量属性列表（如安全性或可修改性）3：架构的设计文档应该完备，至少应有一个静态视图和动态视图，应该采用使所有涉众都能理解的文档。4：设计方案要及时交由涉众传阅，让各涉众积极参与设计方案的评审。5：对架构认真分析得出量化的指标，对质量属性进行评估。6：架构的设计应有助于增量式实现。可先创建一个粗略的、具备雏形功能简单的系统，通过把这个骨架系统逐步细化、呱嗒来得到所期望的的系统。7：允许架构带来一定的资源竞争，但应清楚的给出这些资源争用的解决方案。8：架构应该采用定义良好的模块，各模块的功能职责划分应给予信息隐藏和相互独立的原则。9：应该使用特定于每个属性的众所周知的架构战术来实现质量属性10：架构应避免依赖于某个特定版本的商业产品或工具11：应将产生数据的模块和使用数据的模块分开。12：对于并行处理系统，架构应该采用定义良好的进程或任务，他们未必反映模块分解结构。13：每个任务或进程的编写都要考虑到与特定处理器的关系，并保证能够方便的改变这种关系。14：架构应该采用少量的、简单交互模式。在整个运行过程中，系统的功能应保持一致。使系统结构易于理解，有助于缩短开发时间、提高可靠性、增强可修改性。

软件构架结构(视图)

1、RUP的4+1视图

架构模型

软件架构用来处理软件高层次结构的设计和实施。它以精心选择的形式将若干结构元素进行装配，从而满足系统主要功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和可用性。逻辑视图:设计的对象模型（使用面向对象的设计方法时）。过程视图:捕捉设计的并发和同步特征。物理视图:描述了软件到硬件的映射，反映了分布式特性。开发视图:描述了在开发环境中软件的静态组织结构。

架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例 （use cases）或场景(scenarios)来说明，从而形成了第五个视图。正如将看到的，实际上软件架构部分从这些场景演进而来，将在下文中讨论。

 

2、三个主要的软件结构视图：模块视图、组件-连接器视图、分配视图

模块视图类型和风格

模块是一个功能集的实现，模块视图揭示了系统在设计阶段所存在的结构

模块视图类型主要包括四种风格：分解风格：代表系统一个自顶向下的视图;使用风格：指出当前模块要正确执行的话，哪些其他模块必须存在;泛化（类）风格：通常用来表达面向对象的设计分层风格：将系统划分为不相交的“层”所有类型的模块都可以作为模块视图类型的元素

       模块的属性：名称：一个模块的名称往往暗示着该模块在系统中所起的作用;责任：精确的确认模块的角色，模块的责任必须被非常详尽的描述;接口的可见性：内部VS.外部接口

实现信息：严格来讲，实现信息并非是构架的

模块风格类型的作用：系统构建：为系统的代码实现提供一副蓝图（系统的模块和各种物理结构之间往往有非常紧密的映射关系）系统分析：系统的可追查性（系统需求可以表达为各模块间的一系列交互）；系统的可修改性分析;提供更好的沟通：对系统功能提供一个自顶向下的展示

分解风格：通过“是一个子模块”的关系将单元彼此关联展示了系统的责任如何在模块间进行划分：一种“分而治之”的策略；利于新人学习构架；为系统提供可修改性;分解原则：为达到某种质量属性、“开发”或“购置”的决策、软件产品线

元素：模块（有时也为“子系统”）关系：分解，“是一个子模块”，另外，分解的原则必须在构架编档的时候注明;元素和关系的属性：如模块视图类型中所定义；模块的可见性（模块间的包含关系）与其他结构风格的关系：与组件—连接器风格之间的多对多映射关系；工作分配风格将分解风格中产生的模块分配到相应的开发队伍，形成任务分配关系。

使用风格：是模块依赖关系的一个特殊案例，需要告诉开发者如果当前的系统部分要正确工作，哪些其他模块必须存在；此风格使得系统的递增性开发和部署成为可能。

元素：模块关系：使用（use）元素的属性：如模块视图类型所定义

关系的属性：对一个模块对另外一个模块的使用关系更详尽的描述

拓扑结构：使用风格没有拓扑结构上的限制。但是使用拓扑结构上的环将会损伤递增性开发的能力。

泛化风格：泛化风格来自于面向对象设计的继承关系，模块的定义用于捕捉模块间的共同性和差异性，父模块是子模块的一个更加泛化的版本，可以通过在子模块中添加、删除、修改某些设计来进行功能的扩展而任何对父模块的改变将直接作用于继承自该父模块的子模块。元素：模块关系：泛化（即“是一个”或继承关系）元素的属性：抽象接口（只有接口，没有实现，类似于C++中的虚函数定义）拓扑结构：一个模块可以有多个父模块（多重继承）；不允许环的出现

分层风格：每一层都代表一个虚拟机，虚拟机是一组模块的集合，他们一起向其他模块提供一些服务，其他模块可以使用这些服务而不必知道这些服务是如何实现的。在软件构架中，这是最常用的一种视图，往往有较高的可修改性，不过也常常定义得很差，也经常被误解。

       任何分层风格都不会允许某一层不加限制的调用比它更高层的服务（向上使用）。分层风格中，虚拟机之间的相互交互必须遵循一个严格的次序关系。处于实际设计的需要，有时会在分层设计中允许少量向上使用和跨层使用的情况出现。元素：层关系：允许使用（allowed-to-use）元素的属性：层名、层中所包含的软件单元、该层所允许使用的软件、提供上层的调用接口。关系的属性：该关系是否为传递的分层风格的作用：可移植性，只要保持上层调用接口不变，那么该层中的任何改变对上层而言都是透明的，在这里“接口”不仅指的是API，也包括对上层对下层所做的假设（比如性能、安全性等方面的假设）。

 

组件－连接器视图（衍生问题：系统如何被划分为一组有动态行为的元素（组件）和相互交互的元素（连接器）？）

组件－连接器视图描述了系统在运行时所存在的实体和可能的交互

组件－连接器视图中的组件是指有运行时的表现的元素在组件—连接器视图中，元素间相互交互的途径也作为元素之一（说的就是连接件）

元素：组件－连接器视图中的每个元素都有运行时表现，消耗运行资源，形成系统的运行时行为，这些运行时的实体是组件－连接器类型的实例

类型VS.实例：元素类型由架构风格或系统设计所决定，尽管组件有类型，一个组件－连接器视图只能包含组件的实例：在组件－连接器视图中不能出现组件类型。

组件：一般的组件类型包括：客户端、服务器、过滤器、对象和数据库等

连接器：连接器的示例可以包括：过程调用、异步消息传递、事件广播、管道以及数据库服务器和客户端的事务处理机制

组件－连接器视图类型的作用：组件－连接器视图类型用于考察运行时的系统质量属

组件－连接器视图类型的风格：

共享数据

服务器/客户端（C/S）

P2P

通信进程

管道和过滤器

发布－订阅

共享数据风格：

共享数据风格中有着至少一个能够实现数据持续化的共享数据存储以及多个数据

的访问者。交互的模式主要是持续化数据的交换

一般计算模型：数据的访问者从数据存储中读取数据，执行计算，然后回写数据（纯

共享数据模式），除了上述功能外，还非数据存储元素之间的相互交互

元素：

       组件类型：共享数据存储，数据访问者

       连接器类型：数据读/写

关系：决定哪个访问者和哪个数据存储相连接的关系

属性：数据存储的类型，性能属性，数据分布等

拓扑结构：通常是星型拓扑，数据存储在中间

共享数据风格的作用：实现数据生产者和消费者之间的分离

C/S风格：

组件通过请求其他组件的服务进行交互

纯C/S系统的计算流是非对称的

使用C/S风格的一些限制：限制可以连接到一个服务器的客户端数量，限制服务器不能跟其他服务器进行交互

元素：客户端：向其他组件请求服务；服务器：向其他组件提供服务

关系：连接关系决定哪个服务可以被哪些客户端所请求

属性：服务器：可以连接的客户端的数量和类型，性能属性；连接器：交互的协议

拓扑结构：一般情况下，C/S结构在拓扑上没有限制，也有些特例可能会做以下限制：某个服务的最大连接数、服务器之间的交互关系和层

C/S风格的作用： 提供了一个将客户端应用和它们所使用的服务相分离的系统视图，通过将需要关注的事情进行分离，使得系统易于理解，为将系统部署到硬件平台提供了一个有用的基础。这种分离同时还将系统功能独立的分配到各个层，支持性能上的可扩展性和可靠性

P2P风格：

组件以对等实体的身份交换服务进行交互：以请求/响应的方式进行交互、可能设计复杂的双向交互协议、在两个或多个P2P实体间存在双向通信

P2P和C/S的区别：负载分布问题

特性：支持以下协议：查找另外一个P2P实体，信息查询，信息交换；在运行时由于有新的P2P实体进入或改变链接会引起拓扑结构的变化

元素：组件类型：P2P实体；连接器类型：过程调用。交互可以由任何一方发起

关系：连接关系可能的组件交互图

属性：相互交互的协议以及性能属性，连接关系可能动态的改变

P2P风格的作用：P2P风格展示了一副以合作的领域划分应用的系统视图，P2P实

体既是服务器，又是客户端，为系统部署在一个分布式的平台上提供了灵活性。

P2P计算：分布式的计算应用，在一个计算机网络中，高效的利用CPU和磁盘资源。

通信进程风格：

该风格将系统表示为一系列的并发执行单元以及它们之间的交互：可用的交互方法

包括：同步，消息传递，数据交互，进程控制原语

元素：组件类型：并发单元（任务、进程、线程等）；连接器类型：数据交换、消息传递、同步、控制等

关系：一般的组件和连接器之间的连接关系

计算模型：并发执行的组件通过特殊的连接器机制进行交互

元素属性：并发单元：可抢占性、优先级、定时参数等；数据交换：是否被缓冲

通信进程风格的作用：该风格揭示：系统的哪些部分可以并发执行，如何将组件打包成进程和系统中的控制流；可以用于性能和可靠性分析，设计决策；

注意：系统由多个进程并不意味着使用通信进程风格来表示系统是一个正确的选择

分配视图

分配结构展示了软件元素和创建并执行软件的一个或多个外部环境中的元素之间的关系。他们回答了诸如此类的问题：每个软件元素在什么处理器上执行？在开发、测试和系统构建期间，每个元素都存储在什么文件中？分配给开发小组的软件元素是什么？

部署风格：

在部署风格中，某种组件－连接器风格（通常是通信进程风格）的元素被分配到执行平台。分配上的一些限制包括：软件元素所表达的需求，这些需求如何被硬件元素的特性所满足。

元素：软件元素：通常是某个组件-连接器视图中的进程；环境元素：计算机硬件——处理器、内存、硬盘、网络等

关系：分配关系：显示软件元素驻留在哪个物理单元上；分配关系有可能是动态的

属性：会影响到将软件分配到硬件的一些属性：软件元素的需求属性（资源消耗、必须满足的资源需求和限制、安全性）；环境元素的提供属性（CPU属性、内存属性、硬盘和其他存储单元、带宽）

实现风格：

实现（implementation）风格将模块视图类型中的模块映射到开发基础设施。

题外话：模块的实现通常会导致多个分离的文件：源代码、包含的文件、编译模块产生的文件等，而组织这些文件需要配置管理的技巧

元素：软件元素：一个模块；环境元素：一个配置项

关系：包含：指明一个配置项被包含在另外一个中；分配：描述将一个配置项分配到一个配置项

拓扑结构：配置项的包含关系呈现层次结构

实现风格的作用：在开发和编译中管理和维护与软件元素相对应的文件；开发者使用实现风格来找到相应的文件进行更新，测试，编译或找到文件过去的版本；对一个特定的系统，制定版本的差别；对需要特殊关注的元素进行高亮显示

工作分配风格：

工作分配风格揭示如何将软件分配到开发系统的人员：将模块划分为更小的模块，跟将开发队伍划分成更小的队伍是相对应的；在划分中的每一步，开发队伍的结构都反映了模块结构

元素：软件元素：一个模块；环境元素：一个组织单元

关系：分配关系

元素的属性：技能集：需求的和提供的

一个良好的工作分配关系需要：完全性：所有的工作都被分配；没有重叠：没有工作被分配到两个地方

工作分配关系的作用：管理团队资源的分配；向新员工解释一个项目的结构；对项目成本和开发周期的详细估计

质量属性

1、功能性与质量属性之间的关系

功能性和质量属性是正交的，对选择的任何功能设计师都将确定每个质量属性的相对级别，功能性在很大程度上是独立于结构的，当其他质量属性很重要时，软件构架会限制各结构的功能分配，功能性关注的是他如何与其他质量属性交互，以及如何限制其他质量属性的。

2、构架和质量属性的实现关系

构架是软件功能到软件结构的映射，正是这个映射（或分配）决定了构架对质量属性的支持

n  质量属性的达成，必须在以下阶段都进行考虑：设计，实现，部署

n  满意的质量属性，来自于系统的总体蓝图（构架）和细节的正确处理

n  构架对质量属性的达成是关键的

n  仅靠构架是无法达成质量属性的

n  质量属性的达成不是独立的

q  一种质量属性的达成，可能会负面的（或正面的）影响另外一种质量属性

n  易用性涉及架构和非架构俩个方面。例如，非架构方面包括使用户界面清晰、易用。系统是否能够为用户提供取消操作、撤消操作或者重用以前输入的数据的能力属于架构方面的问题。

n  可修改性由划分功能的方式和模块中的编码技巧决定

n  系统性能是一个既依赖于架构又不完全依赖于架构的质量属性。系统性能受个组件之间必须进行通信的数据量的制约，受为每个组件所分配的功能的影响，受共享资源的方式的影响，受所选择实现某个功能的算法的影响

与构架本身相关的一些质量属性

n  概念完整性——在各个层次上统一系统设计的根本指导思想

q  我认为概念完整性在系统设计中是最重要的考虑事项。一个省却了不常见的特性或改进，但反映了一组设计思想的系统要比一个包括了很多好的但相互独立且不协调的思想的系统要好得多。[人月神话]

n  正确性和完整性

n  可构建性

3、 质量属性场景

质量属性场景是一种面向特定的质量属性的需求它有6部分组成：

刺激源：这是某个生成该刺激的实体（人、计算机系统或任何其他激励器）

刺激：该刺激是当刺激到达系统时需要考虑的条件

环境：该刺激在某些条件下发生。当刺激发生时，系统可能处于过载，或者正在运行，也可以是其他情况。

制品：某个制品被刺激，这可能是整个系统，也可能是系统的一部分。

响应：该响应是在刺激到达后所采取的行动。

响应度量：当响应发生时，应该能够以某种方式对其进行度量，以对需求进行测试

刺激源->刺激->制品（环境）->响应->响应度量

战术

战术：就是影响质量属性响应控制的设计决策。我们把战术的集合叫做“构架策略”

六种质量属性相关战术：

可用性战术：错误检测战术、错误恢复战术、错误预防战术；目标：组织错误发展成故障，至少能把错误的影响限制在一定范围内，从而使修复成为可能

可修改性战术：局部化修改、防止连锁反应、延迟绑定时间.目标：控制实现、测试和部署变更的时间和成本

性能战术：资源需求、资源管理战术、资源仲裁；目标：在一定的时间限制内到达系统的事件生成一个响应。

安全性战术：抵抗攻击、检测攻击、从攻击中恢复；目标：系统检测攻击，对攻击的抵抗，并从攻击中恢复过来

可测试性战术：输入/输出、内部监视；目标：允许在完成软件开发的一个增量后，较轻松的对软件进行测试

易用性战术：运行时战术、设计时战术；目标：根据用户请求为用户提供适当的反馈和协助

构架设计

1、生命周期中的构架：把构架作为软件开发过程基础的任何组织都需要理解构架在其生命期中的位置，把构架放在一个适当位置的模型是演变交付生命期模型，该模型的意图是获得用户和客户反馈，并在发布最终版本前通过几个版本进行迭代。该模型还允许在每次迭代中添加功能，并且在开发了足够的特性集后，就交付该功能受到限制的版本。

2、ADD方法的思路原理：ADD是一种定义软件构架的方法，该方法将分解过程建立在软件必须满足的质量属性之上。它是一个递归的分解过程，其中在每个阶段都选择战术和构架模式来满足一组质量属性场景，然后对功能进行分配，以实例化由该模式所提供的模块类型。

3、ADD方法的步骤：1、选择要分解的模块a从整个系统开始b进行分解时，要求所有输入都是可获得的（限制条件、功能需求、质量需求）2、根据这些步骤对模块进行求精

A：从具体的质量场景和功能需求集合中选择构架驱动因素

B：选择创建满足构架驱动因素的构架模型，确定所选战术需要的子模块

C：实例化模块并根据用例分配功能，使用多个视图进行表示

D：定义子模块的接口

E：验证用例和质量场景并对其进行求精，使他们成为子模块的限制

3、对需要进一步分解的每个模块重复上述步骤

4、质量功能部署QFD：是一个非常结构化的、矩阵驱动的过程，运行包括4个阶段：a/将顾客需求转化成设计需求b/将设计需求转化成产品、零部件特性c/将产品、零部件特性转换成制造操作步骤d/将制造操作步骤转换成具体的操作或控制。

5、并行工程：是对产品及其相关过程（包括制造过程和支持过程）进行并行、集成化处理的系统方法和综合技术。它要求产品开发人员从一开始就考虑到产品全生命周期内各阶段的因素，并强调各部门的协同工作，通过建立各决策者之间的有效的信息交流与通讯机制，综合考虑各相关因素的影响，使后续环节中可能出现的问题在设计的早期阶段就被发现，并得到解决，从而使产品在设计阶段便具有良好的可制造性、可装配性、可维护性及回收再生等方面的特性，最大限度地减少设计反复，缩短设计、生产准备和制造时间。

软件体系结构描述

1: ADL：定义、作用、构成元素

定义: ADL是形式化语言，有底层语义的支持，提供语法和概念框架；

作用: 基于底层语义的工具，为SA的表示、分析、演化、细化、设计过程提供支持；

构成元素包括:构件：计算或数据存储单元；连接件：交互及其交互规则

 SA配置：拓扑图

详细内容在9-2-SA-ch-9-13-07-软件体系结构描述.ppt 57页

2、软件体系结构视图，有哪些视图，各视图的作用

①模块(module)视图类型：软件作为一个实现单元集，它是如何构造的。模块视图能为系统的实现单元编档

②构件-连接件(C&C)视图类型：软件作为一个运行时行为和交互作用的元素集，它是如何构造的。C&C视图能为系统的执行单元编档

③分配(allocation)视图类型：软件是如何在它所处的环境中与非软件结构产生联系的。能为系统软件与其开发和执行环境之间的关系编档

3、用UML描述软件体系结构的优缺点，解决策略, 如何描述一个模块视图和组件-连接器视图和分配视图等。UML建模优点主要优点可以归结为以下三点：1统一标准:UML不仅统一了Booch，OMT和OOSE等方法中的基本概念，还吸取了面向对象技术领域中其它流派的长处，其中也包括非OO方法的影响。UML使用的符号表示考虑了各种方法的图形表示，删掉了大量易引起混乱的，多余的和极少使用的符号，也添加了一些新符号，提供了标准的面向对象的模型元素的定义和表示法。2面向对象:UML建模优点中第二个就是面向对象。UML支持面向对象技术的主要概念，它提供了一批基本的表示模型元素的图形和方法，能简洁明了地表达面向对象的各种概念和模型元素。3表达能力强大，可视化:UML是一种图形化语言，用UML的模型图形能清晰地表示系统的逻辑模型或实现模型。它不只是一堆图形符号，在每一个图形表示符号后面，都有良好定义的语义；UML还提供了语言的扩展机制，用户可以根据需要增加定义自己的构造型，标记值和约束等，它的强大表达能力使它可以用于各种复杂类型的软件系统的建模。

UML 缺点 UML缺乏对体系结构下述的元素进和相应的描述与应用能力

 体系结构风格;显式的体系结构连接器;体系结构约束

 总体来讲：UML是一种非形式化的描述语言，缺乏严格的语意描述，不能表达体系结构中的语义，不能描述体系结构的相关模型。

哪些是典型的软件体系结构描述语言？UniCon 、Wright、C2、Rapide、SADL、Aesop、ACME

构架编档

1、•优秀编档的七个原则

n  下面这些编档的原则可以用于所有的编档工作，而非仅仅是软件构架的编档

1：从读者的角度出发撰写你的文档2：避免不必要的重复3：避免歧义4：使用一种标准的组织格式5：不仅记载怎么做，也记载为什么这么做6：保持文档更新，但不必太新7：根据文档的使用目的来进行编档

2、视图的读者: 系统的涉众。

3、视图和超越视图”编档方法包含哪些相关信息？

n  视图的概念为我们提供了进行软件构架编档的基本原则

n  选择相关视图，对试图进行编档；将适合多个视图的信息放到文档中。

4、对一个视图的编档应包括哪些信息

n  视图编档没有工业标准模板，但是团队中采用的编档应该有一个标准组织（回顾编档7原则）接口的编档包括：命名和确定接口（“签名”）；编档语义信息；编档语法信息

n  一般实践中可以采取包括以下7部分的标准组织

1.展示视图中的元素和元素间关系的主要表示

n  2.元素目录：详述在主要表示中的元素和他们之间的关系；元素的行为和接口

n  3上下文图：展示在视图中描述的系统如何与其环境相关

n  4.可变性指南：展示如何应用该视图中所展示的构架的一部分的任何变化点

n  5.构架背景：解释视图中所反映的设计合理性

n  6.视图中所使用的术语表，对每个术语进行简要说明

n  7.其他信息：管理信息，比如：作者、配置控制数据、变更历史

5、对接口的编档应该包括哪些部分

1.接口身份2.所提供的资源3.数据类型定义4.异常定义5.该接口提供的可变性6.接口的质量属性特征7.元素需求8.基本原理和设计问题9.使用指南

构架评估方法ATAM（体系结构权衡分析方法）

1、体系结构权衡分析方法

•    特点

–  评估SA对特定质量目标的满足情况，揭示诸多质量目标之间的相互作用和权衡

–  结构化的评估方法，可重复

–  同样适合遗产系统的分析

•    方法来源

–  体系结构风格

–  质量属性分析方法

–  SAAM (Software ArchitectureAnalysis Method)

   目的:用于获取系统以及架构的业务目标,还用于使用这些目标和涉众参与来使评估人员把注意力放到对实现这些目标重要的架构部分上.

2、ATAM结果

•    ATAM / SAAM / ARID的共同输出

–  划分了优先级的质量属性需求

–  从体系结构方法到质量属性的映射

–  有风险决策和无风险决策

•    ATAM的特有输出

–  所使用的体系结构方法的分类

•   为相关人员提供熟悉体系结构的材料

–  针对所采用的方法和特定质量属性的分析方法

•   能够用于后续体系结构演化的评估，避免走错方向

–  敏感点(Sensitivity Points)和权衡点(Tradeoff Points)

•   敏感点是对于达到特定的质量属性响应至关重要的一个或多个构件（和/或构件关系）特性。敏感点告诉设计人员或分析人员当试图理解一个质量目标是否达到时，需将注意力集中到什么地方

•   权衡点是影响多于一个属性 (attribute) 的特性 (property)，并且是多个属性的敏感点。例如，改变加密算法级别会对安全性和效率有显著影响。权衡点是体系结构设计中最关键的决策，因此需要非常仔细地加以关注

4、ATAM主要部分包括4组，共9个步骤：

1. 陈述，包括通过它进行的信息交流

①     ATAM方法的陈述：评估负责人

②     商业动机的陈述：项目经理或系统客户

③     SA的陈述：系统设计人员

2. 调查与分析，包括对照体系结构方法评估关键质量属性需求

①     确定体系结构方法：系统设计人员

②     生成质量属性效用树（utility tree）：说明构成系统“效用” 的质量属性（性能、有效性、安全性、可修改性、可用性） ，具体到场景层次，标注刺激/反应，并区分不同的优先级

③     分析体系结构方法：基于步骤5识别出的高优先级的场景，说明和分析针对这些场景的体系结构方法。在这一步骤中，体系结构风险、非风险、敏感点和权衡点被识别出来

3. 测试，包括对照所有相关人员的需求检验最新结果

①     集体讨论并确定场景优先级

②     分析体系结构方法：针对步骤7的高等级场景

4. 形成报告，包括陈述ATAM的结果

①     结果的表述：包括方法、场景、特定属性的问题、效用树、有风险决策、无风险决策、敏感点和权衡点

5、评估团队

•    评估小组 (Evaluation team):主持评估，进行分析

•    风险承担者 (Stakeholders)：在该体系结构以及根据该体系结构开发的系统中有既得6、评估结果：1.  已编写了文档的体系结构方法2.若干场景及其优先级3基于质量属性的若干问题4效用树5. 所发现的有风险点6已编写文档的无风险点7所发现的敏感点和权衡点

7:架构复审的目的:

1.揭示时间安排或预算中未知的或已觉察的风险。2检查某些构架设计的缺陷。众所周知，构架缺陷是最难修复的，归根结底也是最具有破坏力的因素。

3.检测需求与构架之间可能存在的失配：设计超标、需求不符合现实或者需求遗漏。评估尤其需要检查操作、管理和维护范围内某些容易遗漏的方面。系统如何安装？是否已经更新？如何转换当前的数据库？4.评估构架质量的一个或多个具体方面：性能、可靠性、可修改性、保密性和安全性。5.  确定复用的时机。

软件体系结构发展

•产品线

       软件体系结构的开发是大型软件系统开发的关键环节。体系结构在软件生产线的开发中具有至关重要的作用，在这种开发生产中，基于同一个软件体系结构，可以创建具有不同功能的多个系统。在软件产品族之间共享体系结构和一组可重用的构件，可以增加软件工程和降低开发和维护成本。一个产品线代表着一组具有公共的系统需求集的软件系统，它们都是根据基本的用户需求对标准的产品线构架进行定制，将可重用构件与系统独有的部分集成而得到的。采用软件生产线式模式进行软件生产，将产生巨型编程企业。但目前生产的软件产品族大部分是处于同一领域的。

•基于组件的软件开发

       组件技术是90年代初出现的一种软件开发技术， 它是在结构化设计和面向对象技术的基础上发展起的，是面向对象技术之后的软件开发的标准方法系，是面向对象的开发技术的延伸。因此组件具有面向对象的特征。一个软件组件是由契约性说明接口和明确的上下文相关性组合的单元组成。可以被独立地调度，而且常常由第三方开发。组件具有功能独立性、高度的可重用性、与语言和平台无关性等特点。软件组件就是一个通过规定的接口提供一组服务代码的执行单元，这个执行单元的特点是，对内做到高内聚，对外保持低偶合，它是基于面向对象概念的一种部件操作互联和通信的二进制代码模型。

       基于组件的软件工程(CBSE)可以理解为:在一定组件模型的支持下，重用组件库中的一个或多个软件组件， 通过一般化、特殊化或组合等手段高效率、高质量地构造应用软件系统的过程。已有的技术包括COM+、企业级JavaBeans，CORBA 等等。 基于组件的软件工程是软件工程进化和发展的产物，因此，它将会使软件开发过程中设计者的主要任务和所需技巧发生很大的改变

•软件体系结构的失配

       软件体系结构失配是指组装到一起的体系结构元素间的逻辑上的不一致，是一个构件的执行属性与系统中的其它构件的属性冲突时产生的。体系结构失配包括静态（又称结构上）和动态（又称行为上）两种

•软件集成

       软件集成就是用一种较好的方式，使多种软件的功能集成到一个软件里，或是把软件的各部分组合在一起。系统集成是在系统工程科学方法的指导下，根据用户需求，优选各种技术和产品，将各个分离的子系统连接成为一个完整可靠经济和有效的整体，并使之能彼此协调工作，发挥整体效益，达到整体性能最优。

•软件体系结构重用

       软件重用是指把软件生命周期中各阶段的成果作为可重用的部件。部件是目前发展最快的软件重用方式。软件部件技术主要解决两个重要问题：一是通用，即部件具有通用的特性，所提供的功能能为多种系统使用；二是互操作，即不同来源的部件能相互协调、通讯，共同完成更复杂的功能。

•软件体系结构重构

       软件重构是一种在保证系统外部行为属性不发生变化的前提下，通过改善系统的结构达到改善软件质量的方法。传统的软件重构技术关注与软件源代码上的重构。目前的主流趋势已将重构的概念运用于生命周期的早期阶段，重构的对象包括了各类软件制品，例如分析/设计模型等，由此产生了模型重构的研究领域。模型重构可以从需求模型、分析设计模型、体系结构等多个层次进行研究。

•MDA：模型驱动架构

       MDA源自于众所周知的把系统操作的规范从系统利用底层平台能力的方式细节中分离出来的思想，MDA提供了一种途径（通过相关的工具）来规范化一个平台独立的系统、规范化平台、为系统选择一个特定的实现平台，并且把系统规范转换到特定的实现平台。MDA的三个主要目标是：通过架构性的分离来实现轻便性、互操作性和可重用性。

       在MDA中软件开发过程是由软件系统的建模行为驱动的。

       MDA生命周期和传统生命周期没有大的不同，主要的区别在于开发过程创建的工件，包括PIM（PlatformIndependent Model，平台无关模型）、PSM（Platform specific Model，平台相关模型）和代码。

       MDA的出现，为提高软件开发效率，增强软件的可移植性、协同工作能力和可维护性，以及文档编制的便利性指明了解决之道。MDA被面向对象技术界预言为未来两年里最重要的方法学。当今建模的主要问题在于，对于很多企业来说它只是纸面上的练习。这就造成了模型和代码不同步的问题，代码会被不断修改，而模型不会被更新，这样模型就失去了意义。弥补建模和开发之间的鸿沟的关键就在于将建模变为开发的一个必不可少的部分。MDA 是模型驱动开发的框架，MDA的愿景是定义一种描述和创建系统的新的途径。MDA 使得UML 的用途走得更远，而不仅仅是美丽的图画。很多专家预言MDA 有可能会带领我们进入软件开发的另一个黄金时代。

•SOA：面向服务的体系结构

       SOA(Service-OrientedArchitecture)，面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

       SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML/Web Service技术之后的自然延伸。

       SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。

       SOA的基本特征：可从企业外部访问、随时可用、粗粒度的服务接口分级、松散耦合、可重用的服务、服务接口设计管理、标准化的服务接口、支持各种消息模式、精确定义的服务契约

•AOP：Aspect Oriented Programming，面向方面/切面编程

       可以通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技术。AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，AOP可以说也是这种目标的一种实现。AOP针对业务处理过程中的切面进行提取，它所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果。

UML描述软件体系结构?

1模块视图:

    接口:UML用”棒棒糖”表示元素到该接口的依赖,它可以被附加到类和子系统上.允许将类符号构造为接口 模块:类构建-面向对象特征;软件包-在功能分组很重要的地方.子系统构件-接口和行为的规范.聚合:模块可以嵌套两个连续的图其中第二个图在第一个图中战士的模块的内容描述.泛化:模块被表示为类依赖:用软件表示层

2组件连接器视图:

   组件:将架构组建的特性表示为类属性,或用关联表示架构组件的特性.可以使用UML行为模型描述行为,可以使用泛化将组件类型集合联系到一起.接口:没有显示表示省略接口画出最简单的图;接口表示为注解,提供了接口信息场所;接口最为类对象属性是他们成为正式结构模型的一部分,接口作为UML接口提供了接口的紧凑表述;接口作为类克服了表达性的不足现在可以表示接口子结构,并指出某个组件类型具有相同类型的几个接口;连接器:连接器作为关联,连接器实例作为连接,连接器类型作为关联类,连接器类型作为类,连接器实例作为对象.系统:作为UML子系统,作为被包含的对象,作为协作的系统

3分配视图:

由通信关联所连接结点的图形,结点可以包含组建实例,这说明组件可以运行在结点上.组件可以包含对象,这说明对象是组件的一部分.组件通过虚线来表示依赖关系,与其他组件相连,这说明一个组件使用另一个组件的服务.

可用性与系统故障及相关后果有关，它关注的方面包括：如何检测系统故障、系统故障发生的频度、允许系统多长时间非正常运行等

可修改性：是有关修改的成本问题，包括时间成本和经济成本：可修改性有两个关注点可以修改什么（制品）何时进行变更以及由谁进行变更：在过去，通常是由开发者对源代码做出修改；随着软工的发展，我们认识到修改可以发生在不同的阶段

性能与时间相关，事件（中断、消息、用户请求或定时触发）发生时，系统必须对其做出反应。系统性能是跟事件源的数量和所到达的模式紧密相关的。

安全性是衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力。攻击——试图突破安全防线的行为。系统的安全性包括以下六方面特征不可否认性——交易不能被交易的任何一方所否认，保密性——未经授权不能访问数据或服务，完整性——按计划来提交数据或服务的属性，保证——交易的各方应该是他们所声称的人，可用性——系统可用于合法的用途(没DOS)，审核——系统在内部跟踪活动，跟踪级别足以对活动进行重构

软件的可测试性是指通过测试揭示软件缺陷的容易程度；一般会有超过40%的成本是用在测试上的如果构架师可以降低这个成本，收益是巨大的。要想对系统进行正确的测试，必须能够“控制”每个组件的内部状态及其输入，然后能够观察其输出

易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类；易用性可分为以下几个方面，学习系统的特性，有效的使用系统，将错误的影响降到最低，使系统适应用户的需要，提高自信和满意度。系统可以通过为用户提供所需特性、预计用户的需要等手段来提高易用性：支持学习系统特性、支持有效使用系统、支持降低错误的影响、支持系统适应用户需要、支持对系统满意：显示系统状态

可用性与系统故障及相关后果有关，它关注的方面包括：如何检测系统故障、系统故障发生的频度、允许系统多长时间非正常运行等 可修改性：是有关修改的成本问题，包括时间成本和经济成本：可修改性有两个关注点可以修改什么（制品）何时进行变更以及由谁进行变更：在过去，通常是由开发者对源代码做出修改；随着软工的发展，我们认识到修改可以发生在不同的阶段 性能与时间相关，事件（中断、消息、用户请求或定时触发）发生时，系统必须对其做出反应。系统性能是跟事件源的数量和所到达的模式紧密相关的。 安全性是衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力。攻击——试图突破安全防线的行为。系统的安全性包括以下六方面特征不可否认性——交易不能被交易的任何一方所否认，保密性——未经授权不能访问数据或服务，完整性——按计划来提交数据或服务的属性，保证——交易的各方应该是他们所声称的人，可用性——系统可用于合法的用途(没DOS)，审核——系统在内部跟踪活动，跟踪级别足以对活动进行重构 软件的可测试性是指通过测试揭示软件缺陷的容易程度；一般会有超过40%的成本是用在测试上的如果构架师可以降低这个成本，收益是巨大的。要想对系统进行正确的测试，必须能够“控制”每个组件的内部状态及其输入，然后能够观察其输出 易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类；易用性可分为以下几个方面，学习系统的特性，有效的使用系统，将错误的影响降到最低，使系统适应用户的需要，提高自信和满意度。系统可以通过为用户提供所需特性、预计用户的需要等手段来提高易用性：支持学习系统特性、支持有效使用系统、支持降低错误的影响、支持系统适应用户需要、支持对系统满意：显示系统状态