软考高级系系统分师和架构师常考知识点总结三

前面第一、第二部分总结参考如下：
软考高级系系统分师和架构师常考知识点总结二
软考高级系系统分师和架构师常考知识点总结一
这部分是系分和架构总结的第三部分，也是最后一部分，架构评估和基于架构的软件开发（很多也翻译成基于体系结构的软件开发）是重点中的重点。

第 11 章： 软件体系结构评估

软件质量属性
1、性能
性能（performance）是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量的表示。性能测试经常要使用基准测试程序（用以测量性能指标的特定事务集或工作量环境）。
2、可靠性
可靠性（reliability）是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。可靠性是最重要的软件特性，通常用它衡量在规定的条件和时间内，软件完成规定功能的能力。可靠性通常用平均失效等待时间（Mean Time To Failure，MTTF）和平均失效间隔时间（Mean Time Between Failure，MTBF）来衡量。在失效率为常数和修复时间很短的情况下，MTTF和MTBF几乎相等。可靠性可以分为两个方面：
（1）容错。其目的是在错误发生时确保系统正确的行为，并进行内部“修复”。例如，在一个分布式软件系统中失去了一个与远程构件的连接，接下来恢复了连接。在修复这样的错误之后，软件系统可以重新或重复执行进程间的操作直到错误再次发生。
（2）健壮性。这里说的是保护应用程序不受错误使用和错误输入的影响，在遇到意外错误事件时确保应用系统处于已经定义好的状态。值得注意的是，和容错相比，健壮性并不是说在错误发生时软件可以继续运行，它只能保证软件按照某种已经定义好的方式终止执行。软件体系结构对软件系统的可靠性有巨大的影响。例如，软件体系结构通过在应用程序内部包含冗余，或集成监控构件和异常处理，来支持可靠性。
3、可用性
可用性（availability）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。
4、安全性
安全性（security）是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性是根据系统可能受到的安全威胁的类型来分类的。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。其中，机密性保证信息不泄露给未授权的用户、实体或过程；完整性保证信息的完整和准确，防止信息被非法修改；可控性保证对信息的传播及内容具有控制的能力，防止为非法者所用。
5、可修改性
可修改性（modifiability）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。可修改性包含四个方面：
（1）可维护性（maintainability）。这主要体现在问题的修复上：在错误发生后“修复”软件系统。为可维护性做好准备的软件体系结构往往能做局部性的修改并能使对其他构件的负面影响最小化。
（2）可扩展性（extendibility）。这一点关注的是使用新特性来扩展软件系统，以及使用改进版本来替换构件并删除不需要或不必要的特性和构件。为了实现可扩展性，软件系统需要松散耦合的构件。其目标是实现一种体系结构，它能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的体系结构中也是必要的。
（3）结构重组（reassemble）。这一点处理的是重新组织软件系统的构件及构件间的关系，例如通过将构件移动到一个不同的子系统而改变它的位置。为了支持结构重组，软件系统需要精心设计构件之间的关系。理想情况下，它们允许开发人员在不影响实现的主体部分的情况下灵活地配置构件。
（4）可移植性（portability）。可移植性使软件系统适用于多种硬件平台、用户界面、操作系统、编程语言或编译器。为了实现可移植，需要按照硬件无关的方式组织软件系统，其他软件系统和环境被提取出。可移植性是系统能够在不同计算环境下运行的能力。这些环境可能是硬件、软件，也可能是两者的结合。在关于某个特定计算环境的所有假设都集中在一个构件中时，系统是可移植的。如果移植到新的系统需要做些更改，则可移植性就是一种特殊的可修改性。
6、功能性
功能性（functionality）是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。
7、可变性
可变性（changeability）是指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品（例如，软件产品线）的基础时，可变性是很重要的。
8、集成性
可集成性（integrability）是指系统能与其他系统协作的程度。
9、互操作性
作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性（interoperation），软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口。程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件体系结构。

1、敏感点和权衡点
敏感点（sensitivity point）和权衡点（tradeoff point）是关键的体系结构决策。
敏感点是一个或多个构件（和/或构件之间的关系）的特性。研究敏感点可使设计人员或分析员明确在搞清楚如何实现质量目标时应注意什么。
权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。例如，改变加密级别可能会对安全性和性能产生非常重要的影响。提高加密级别可以提高安全性，但可能要耗费更多的处理时间，影响系统性能。如果某个机密消息的处理有严格的时间延迟要求，则加密级别可能就会成为一个权衡点。
2、风险承担者
风险承担者（stakeholders）在项目管理领域中通常翻译为“项目干系人”或“涉众”。系统的体系结构涉及到很多人的利益，这些人都对体系结构施加各种影响，以保证自己的目标能够实现。

3、场景
在进行体系结构评估时，一般首先要精确地得出具体的质量目标，并以之作为判定该体系结构优劣的标准。把为得出这些目标而采用的机制叫做场景（scenarios）。场景是从风险承担者的角度对与系统的交互的简短描述。在体系结构评估中，一般采用刺激（stimulus）、环境（environment）和响应（response）三方面来对场景进行描述。
评估的主要方式
基于调查问卷或检查表的方式、基于场景的方式和基于度量的方式。

整个ATAM评估过程包括九个步骤，按其编号顺序分别是描述ATAM方法、描述业务动机、描述体系结构、确定体系结构方法、生成质量属性效用树、分析体系结构方法、讨论和分级场景、分析体系结构方法（是第六步的重复）、描述评估结果。有时，可以修改这九个步骤的顺序以满足体系结构信息的特殊需求。也就是说，虽然这九个步骤按编号排列，但并不总是一个瀑布过程，评估人员可在这九个步骤中跳转或进行迭代。
ATAM 被分为四个主要的活动领域(或阶段)，分别是场景和需求收集、体系结构视图和场景实现、属性模 型构造和分析、折中。SAAM 分析评估体系结构的过程包括五个步骤，即场景开发、体系结构描述、单个场景评估，场景交互和总体评估。SAAM 的主要输入是问题描述、需求声明和体系结构描述。
图11-1是一棵效用树的样例。在图11-1中，“效用”是树的根结点，代表了系统的整体质量。质量属性构成了效用树的二级结点，典型的质量属性（如性能、可修改性、可用性和安全性）构成了效用的子结点。依次类推，可对每个质量属性依次展开。

ATAM评估的阶段
大致分为两个阶段。第一个阶段以体系结构为中心，重点是获取体系结构信息并进行分析。第二个阶段以风险承担者为中心，重点是获取风险承担者的观点，验
证第一个阶段的结果。
SAAM评估方法
SAAM方法是最早形成文档并得到广泛使用的软件体系结构分析方法，最初是用来分析体系结构的可修改性的，但实践证明，SAAM方法也可用于对许多质量属性（例如，可移植性、可扩充性、可集成性等）及系统功能进行快速评估。

第 12 章：基于体系结构的软件开发

设计模式的分类
根据目的和用途不同，设计模式可分为创建型（creational）模式、结构型（structural）模式和行为型（behavioral）模式三种。创建型模式主要用于创建对象，结构型模式主要用于处理类或对象的组合，行为型模式主要用于描述类或对象的交互以及职责的分配。
1 创建型模式包括工厂方法模式、抽象工厂模式、原型模式、单例模式和建造者模式等。
（1）工厂方法（factory method）模式。工厂方法模式又称为虚拟构造器（virtual constructor）模式或多态模式，属于类的创建型模式。在工厂方法模式中，父类负责定义创建对象的公共接口，而子类则负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成，即由子类来决定究竟应该实例化（创建）哪一个类。
（2）抽象工厂（abstract factory）模式。抽象工厂模式又称为Kit模式，属于对象创建型模式。抽象工厂模式是所有形式的工厂模式中最为抽象和最具一般性的一种形态，它提供了一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。在抽象工厂模式中，引入了产品等级结构和产品族的概念，产品等级结构是指抽象产品与具体产品所构成的继承层次关系，产品族是同一个工厂所生产的一系列产品，即位于不同产品等级结构且功能相关联的产品组成的家族。当抽象工厂模式退化到只有一个产品等级结构时，即变成了工厂方法模式。
（3）原型（prototype）模式。在系统开发过程中，有时候有些对象需要被频繁创建，原型模式通过给出一个原型对象来指明所要创建的对象的类型，然后通过复制这个原型对象的办法，创建出更多同类型的对象。原型模式是一种对象创建型模式，用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。原型模式又可分为两种，分别是浅克隆和深克隆。浅克隆仅仅复制所考虑的对象，而不复制它所引用的对象，也就是其中的成员对象并不复制；深克隆除了对象本身被复制外，对象包含的引用也被复制，即成员对象也被复制。
（4）单例（singleton）模式。单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。
（5）建造者（builder）模式。建造者模式强调将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式是一步一步地创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。建造者模式属于对象创建型模式。

2 结构型模式包括适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式等。适桥组装外享代（石桥组装外箱带）
（1）适配器（adapter）模式。适配器模式将一个接口转换成客户希望的另一个接口，从而使接口不兼容的那些类可以一起工作。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。在类适配器模式中，通过使用一个具体类将适配者适配到目标接口中；在对象适配器模式中，一个适配器可以将多个不同的适配者适配到同一个目标。
（2）桥接（bridge）模式。桥接模式将抽象部分与它的实现部分分离，使它们都可以独立地变化。它是一种对象结构型模式，又称为柄体（handle and body）模式或接口（interface）模式。桥接模式类似于多重继承方案，但是多重继承方案往往违背了类的单一职责原则，其复用性比较差，桥接模式是比多重继承方案更好的解决方法。
（3）组合（composite）模式。组合模式又称为整体-部分（part-whole）模式，属于对象的结构模式。在组合模式中，通过组合多个对象形成树形结构以表示整体-部分的结构层次。组合模式对单个对象（即叶子对象）和组合对象（即容器对象）的使用具有一致性。
（4）装饰（decorator）模式。装饰模式是一种对象结构型模式，可动态地给一个对象增加一些额外的职责，就增加对象功能来说，装饰模式比生成子类实现更为灵活。通过装饰模式，可以在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责；当需要动态地给一个对象增加功能，这些功能可以再动态地被撤销时可使用装饰模式；当不能采用生成子类的方法进行扩充时也可使用装饰模式。
（5）外观（facade）模式。外观模式是对象的结构模式，要求外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
（6）享元（flyweight）模式。享元模式是一种对象结构型模式，通过运用共享技术，有效地支持大量细粒度的对象。系统只使用少量的对象，而这些对象都很相似，状态变化很小，对象使用次数增多。享元对象能做到共享的关键是区分内部状态和外部状态。内部状态是存储在享元对象内部并且不会随环境改变而改变，因此内部状态可以共享；外部状态是随环境改变而改变的、不可以共享的状态，享元对象的外部状态必须由客户端保存，并在享元对象被创建之后，在需要使用的时候再传入到享元对象内部，外部状态之间是相互独立的。
（7）代理（proxy）模式。代理模式是一种对象结构型模式，可为某个对象提供一个代理，并由代理对象控制对原对象的引用。代理模式能够协调调用者和被调用者，能够在一定程度上降低系统的耦合度，其缺点是请求的处理速度会变慢，并且实现代理模式需要额外的工作。
3、行为型模式
行为型模式是对在不同的对象之间划分责任和算法的抽象化，它不仅仅是关于类和对象的，而且是关于它们之间的相互作用的。行为型模式分为类行为模式和对象行为模式两种，其中类行为模式使用继承关系在几个类之间分配行为，而对象行为模式则使用对象的聚合来分配行为。行为型模式包括职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式等。
（1）职责链（chain of responsibility）模式。职责链模式是一种对象的行为型模式，避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。职责链模式不保证每个请求都被接受，由于一个请求没有明确的接收者，那么就不能保证它一定会被处理。
（2）命令（command）模式。命令模式是一种对象的行为型模式，类似于传统程序设计方法中的回调机制，它将一个请求封装为一个对象，从而使得可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是对命令的封装，将发出命令的责任和执行命令的责任分割开，委派给不同的对象，以实现发送者和接收者完全解耦，提供更大的灵活性和可扩展性。
（3）解释器（interpreter）模式。解释器模式属于类的行为型模式，描述了如何为语言定义一个文法，如何在该语言中表示一个句子，以及如何解释这些句子，这里的“语言”是使用规定格式和语法的代码。解释器模式主要用在编译器中，在应用系统开发中很少用到。
（4）迭代器（iterator）模式。迭代器模式是一种对象的行为型模式，提供了一种方法来访问聚合对象，而不用暴露这个对象的内部表示。迭代器模式支持以不同的方式遍历一个聚合对象，复杂的聚合可用多种方法来进行遍历；允许在同一个聚合上可以有多个遍历，每个迭代器保持它自己的遍历状态，因此，可以同时进行多个遍历操作。
（5）中介者（mediator）模式。中介者模式是一种对象的行为型模式，通过一个中介对象来封装一系列的对象交互。中介者使得各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。中介者对象的存在保证了对象结构上的稳定，也就是说，系统的结构不会因为新对象的引入带来大量的修改工作。
（6）备忘录（memento）模式。备忘录模式确保在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。备忘录模式提供了一种状态恢复的实现机制，使得用户可以方便地回到一个特定的历史步骤。
（7）观察者（observer）模式。观察者模式又称为发布-订阅模式、模型-视图模式、源-监听器模式或从属者（dependents）模式，是一种对象的行为型模式。它定义了对象之间的一种一对多的依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象都得到通知并被自动更新。观察者模式的优点在于实现了表示层和数据层的分离，并定义了稳定的更新消息传递机制，类别清晰，抽象了更新接口，使得相同的数据层可以有各种不同的表示层。
（8）状态（state）模式。状态模式是一种对象的行为型模式，允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。状态模式封装了状态的转换过程，但是它需要枚举可能的状态，因此，需要事先确定状态种类，这也导致在状态模式中增加新的状态类时将违反开闭原则，新的状态类的引入将需要修改与之能够进行转换的其他状态类的代码。状态模式的使用必然会增加系统类和对象的个数。
（9）策略（strategy）模式。策略模式是一种对象的行为型模式，定义一系列算法，并将每一个算法封装起来，并让它们可以相互替换。策略模式让算法独立于使用它的客户而变化，其目的是将行为和环境分隔，当出现新的行为时，只需要实现新的策略类。
（10）模板方法（template method）模式。模板方法模式是一种类的行为型模式，用于定义一个操作中算法的骨架，而将一些步骤延迟到子类中。模板方法模式使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤，其缺点是对于不同的实现，都需要定义一个子类，这会导致类的个数增加，但是更加符合类职责的分配原则，使得类的内聚性得以提高。
（11）访问者（visitor）模式。访问者模式是一种对象的行为型模式，用于表示一个作用于某对象结构中的各元素的操作，它使得用户可以在不改变各元素的类的前提下定义作用于这些元素的新操作。访问者模式使得增加新的操作变得很容易，但在一定程度上破坏了封装性。
中间件概述
1、中间件的功能
中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于操作系统之上，管理计算资源和网络通信，实现应用之间的互操作。中间件的基本功能包括以下六个方面：
（1）负责客户机与服务器之间的连接和通信，以及客户机与应用层之间的高效率通信机制。
（2）提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制。
（3）提供一个多层体系结构的应用开发和运行的平台，以及一个应用开发框架，支持模块化的应用开发。
（4）屏蔽硬件、操作系统、网络和数据库的差异。
（5）提供应用的负载均衡和高可用性、安全机制与管理功能，以及交易管理机制，保证交易的一致性。
（6）提供一组通用的服务去执行不同的功能，避免重复的工作和使应用之间可以协作。
2、中间件的分类
采用自底向上的方式来划分，可分为底层中间件、通用型中间件和集成型中间件三个大的层次。
底层中间件的主流技术主要有JVM（Java Virtual Machine，Java虚拟机）、CLR（CommonLanguage Runtime，公共语言运行库）、ACE（Adaptive Communication Environment，自适配通信环境）等；
通用型中间件也称为平台，其主流技术主要有RPC、ORB、MOM（Message-Oriented Middleware，面向消息的中间件）等；
集成型中间件的主流技术主要有WorkFlow、EAI等。
基于体系结构的软件设计
（Architecture-Based Software Design，ABSD）方法。ABSD方法为产生软件系统的概念体系结构提供基础。
ABSD方法取决于决定系统的体系结构驱动。所谓体系结构驱动，是指构成体系结构的业务、质量和功能需求的组合。使用ABSD方法，设计活动可以在体系结构驱动一决定就开始，这意味着需求获取和分析还没有完成（甚至远远没有完成），就开始了软件设计。
ABSD方法有3个基础。第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术。第二个基础是通过选择体系结构风格来实现质量和业务需求。第三个基础是软件模板的使用。软件模板利用了一些软件系统的结构。
ABSD方法是递归的，且迭代的每一个步骤都是清晰地定义的。
基于体系结构的软件开发过程可以分为独立的两个阶段，这两个阶段分别是实验原型（experimental prototype）阶段和演化开发阶段。
根据基于软件架构的设计的定义，基于软件架构的设计(Architecture Based Software Development, ABSD)强调由商业、质量和功能需求的组合驱动软件架构设计。它强调采用视角 和视图来描述软件架构，采用用例和质量属性场景来描述需求。进一步来说，用例描述的是功能需 求，质量属性场景描述的是质量需求(或侧重于非功能需求)。
在软件架构中，从不同的视角描述特定系统的体系结构，从而得到多个视图，并将这些 视图组织起来以描述整体的软件架构模型。因此，在考虑体系结构时，可以从不同的视角来 检查，这促使软件设计师考虑体系结构的不同属性。例如，展示功能组织的静态视角能判断质量特性，展示并发行为的动态视角能判断系统行为特性。选择的特定视角或视图也就是逻 辑视图、进程视实现视图和配置视图。使用逻辑视图来记录设计元客、素的功能和概念接口，设计元素的功能定义了它本身在系统中的角色，这些角色包括功能、性能等。
基于体系结构的软件开发模型
ABSDM模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现、演化等六个子过程,如图12-22所示。

基于体系结构的软件过程
基于体系结构的软件过程Petri网模型（ABSPN）
（1）形式化的语义 （2）直观的图形表示 （3）丰富的分析技术 （4）基于状态的表示方式

该模型把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现、演化和退役等七个子过程

软件架构设计包括提出架构模型，产生架构设计和进行设计评审等活动，是一个迭代的过程。架构 设计主要关注软件组件的结构、属性和(交互作用)，并通过多种(视图)全面描述特定系统的架构。
是一个迭代的过程，在建立软件架构的初期，一般需要选择一个合适的架构风格，将架构分析阶段已标识的构件映射到架构中，并分析这些构件之间的关系，一旦得到了详细的软件架构设计，需要邀请独立于系统开发的外部人员对系统进行评审。
一般来说，软件架构设计活动将已标识构件集成到软件架构中，设计这些构件,但不予以实现。

第 13 章：软件产品线体系结构

主要的软件产品线的过程模型有双生命周期模型、SEI模型和三生命周期模型。
1、双生命周期模型
最初的和最简单的软件产品线开发过程的双生命周期模型来自STARS，分成两个重叠的生命周期：领域工程和应用工程。两个周期内部都分成分析、设计和实现三个阶段。

2、SEI模型
SEI将产品线的基本活动分为三部分，分别是核心资源开发（即领域工程）、产品开发（即应用工程）和管理
3、三生命周期模型
Fred针对大型软件

企业的软件产品线开发对双生命周期模型进行了改进，提出了三生命周期（tri-lifecycle）软件工程模型
软件产品线的建立方式
软件产品线的建立通常有四种方式，其划分依据有两个：
（1）该组织是用演化方式(evolutionary)还是革命方式(revolutionary)引入产品线开发过程。
（2）是基于现有产品还是开发全新的产品线。

1、将现有产品演化为产品线 2、用软件产品线替代现有产品集 3、全新软件产品线的演化 4、全新软件产品线的开发

框架和应用框架技术
随着软件技术的发展，软件重用已经从模块、对象的重用发展到了基于构件的重用和基于框架的重用，这也是当前最主要的两个软件重用的方式。从重用粒度上看，框架要比构件大。框架重用是一种面向领域的软件重用方式，更适合于软件产品线。框架一般建立在同一个或相似领域中，即所要开发的软件系统要具有较强的相似性，通过框架把领域中不变或易变的部分在一定时间间隔内固定下来，把易变的部分以用户接口的形式保留下来，从而达到设计和代码的重用。框架技术与构件技术的结合产生了基于构件的应用框架技术，这是框架技术的一个发展趋势。
3 框架的分类
根据框架的使用和扩展方式，可以将框架分为两大类：黑盒框架和白盒框架。
黑盒框架通过构件/类的组合来支持重用和扩展。应用中的类由框架的不同构件组合而成。
白盒框架一般使用类的继承机制实现，由未完成的类（抽象类）组成，类有一个或多个抽象接口或虚方法。应用需要在抽象类的继承子类中提供特定意义的方法实例来重用框架。开发者通过虚方法的实例化将特定应用的代码联入框架来生成应用，所以虚方法又称为“钩子”或“热点”。

2、风险承担者观点
产品线风险承担者是人或受产品线开发所影响的系统，一个特定的产品线的风险承担者可以包括（但不限于）决策者（executive）、市场分析员、技术经理、产品线分析员、产品分析员、设计师、程序员和产品的最终用户，以及与产品线中的产品交互的内部和外部系统、政府机构和保险公司等。
产品线体系结构简介
软件体系结构设计的主要目的是满足对软件的质量需求。软件体系结构的应用方式有三种：用于独立软件系统、软件产品线体系结构、用于公共构件市场的标准软件体系结构。
系统升级策略

第 14 章：其他补充知识：

J2EE 核心组成:
容器:Applet Container、Application Container、WebContainer、EJB Container
组件:Applet、Application、JSP/Servlet、EJB 服务
HTTP(Hypertext Transfer Protocol)超文本传输协议
RMl-llOP(Remote Method Invocation ober the InternetInter-ORB Protocol):远程方法调用，融合了 JavaRMI 和CORBA(Common Object Rrquest Broker Architecture公共对象请求代理体系结构)在使用 Application或 Web端访问 EJB 端组件是使用Java lDL(Java Interface Definition Language):Java 接定义语言，主要用于访问外部的 CORBA 服务
JTA(Java Transaction APl):用于进行事务处理操作的APIJDBC(Java Database Connectivity):为数据库操作提供的一组 APl
JMS(Java Massage Service):用于发送点对点消息的服务
JavaMai: 用于发送邮件JAF(Java Activation Framework):用于封装传递的邮件数据
JNDl(Java Naming and Directory Interface )
JAXP(Java API forXML Parsing ):专门用于 XML解析操作的 API
JCA(J2EE ConnectorArchitecture ):Java 连接器构架
JAAS (Java Authenticati on and Authorization ServiceJSF(Java Server Faces)
JSTL (JSP Standard Tag Library)SAAJ (SOAP with Attachments API for JAVA)
JAXR (Java Apl for XML Registries)

IDL是一种接口定义语言，具体的定义会涉及到接口以及相关部分。文件包含的主要元素有:接口描述、模块定义、类型定义、常量定义、异常、值类型。接口描述是DL文件中最核心的内容。由于IDL只是一种接口定义语言，最终还是要落地与语言对接的，所以IDL的数据类型要与实现语言进行映射。以Java为例，IDL接口映射为java类，而该接口的操作映射为相应的成员函数。模块定义映射为Java 语言中的包(Package)或C++的namespaces.
面向构件的编程(COP)关注于如何支持建立面向构件的解决方案。一个基于一般 OOP 风格的 COP 定义如下(Szyperski，1995):“面向构件的编程需要下列基本的支持:
-多态性(可替代性);
-模块封装性(高层次信息的隐藏)
-后期的绑定和装载(部署独立性)
-安全性(类型和模块安全性)。

POA是对象实现与ORB其它组件之间的中介，它将客户请求传送到伺服对象，按需创建子POA，提 供管理伺服对象的策略。 CORBA对象可看作是一个具有对象标识、对象接口及对象实现的抽象实体。之所以称为抽象的，是因为并没有硬性规定CORBA对象的实现机制。由于独立于程序设计语言和特 定ORB产品，一个CORBA对象的引用又称可互操作的对象引用(Interoperable ObjectReference)。从客户程序的角度看，IOR中包含了对象的标识、接口类型及其他信息以查找对象实 现。伺服对象(servant)是指具体程序设计语言的对象或实体，通常存在于一个服务程序进程之中。 客户程序通过对象引用发出的请求经过ORB担当中介角色，转换为对特定的伺服对象的调用。在一个CORBA对象的生命期中，它可能与多个伺服对象相关联，因而对该对象的请求可能被发送到不同的伺服对象。对象标识(ObjectlD)是一个用于在POA中标识一个CORBA对象的字符串。它既可由程序员指派，也可由对象适配器自动分配，这两种方式都要求对象标识在创建它的对象适 配器中必须具有唯一性。
SDN架构包括业务层、控制层、转发层。
软件重用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素的过程。软件元素 包括需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识等。对于新的软件开发 项目而言，它们或者是构成整个目标软件系统的部件，或者在软件开发过程中发挥某种作用。通常 将这些软件元素称为软部件。
软件开发环境(SoftwareDevelopment Environment,SDE)是指支持软件的工程化开发和维护而使用的一组软件，由软件工具集和环境集成机制构成。软件开发环境应支持多种集成机制，根据功能的不同，集成机制可以划分为环境信息库、过程控制与消息服务器、环境用户界面三个部分。①环境信息库。环境信息库是软件开发环境的核心,用于存储与系统开发有关的信息，并支持信息的交流与共享。环境信息库中主要存储两类信息，一类是开发过程中产生的有关被开发系统的信息，例如分析文档、设计文档和测试报告等;另–类是环境提供的支持信息，如文档模板、系统配置、过程模型和可复用构件等
企业信息集成是指企业在不同应用系统之间实现数据共享，即实现数据在不同数据格式和存储方式之间的转换。对来源不同、形态不一、内容不等的信息资源进行系统分析、辨清正误、消除冗余、合并同类，进而产生具有统一数据形式的有价值信息的过程。企业信息集成是一个十分复杂的问题，按照组织范围来分，分为企业内部的信息集成和外部的信息集成两个方面;
按集成内容企业内部的信息集成一般可分为4个方面，即技术平台集成、数据集成、应用系统集成和业务过程集成。其中应用系统集成是实现不同系统之间的互操作，使得不同应用系统之间能够实现数据和方法的共享；业务过程集成使得在不同应用系统中的流程能够无缝连接，实现流程的协调运作和流程信息的充分共享。