软件工程中的高级课题

《软件工程中的高级课题》由会员分享，可在线阅读，更多相关《软件工程中的高级课题（86页珍藏版）》请在装配图网上搜索。

1、软件工程中的高级课题 李 宣 东 南京大学计算机科学与技术系Advanced Topics in SE Computer-Aided Software Engineering Formal Methods Software Reuse Reengineering Component-Based Software Engineering Cleanroom Software Engineering Client/Server Software Engineering Web EngineeringComputer-Aided Software Engineering（CASE）支持软件开发生存期

2、的集成化工具、技术和方法CASE Concepts CASE技术（technology）：为软件开发、维护和项目管理提供自动化、工程化准则的软件技术；包括自动化结构化方法和自动化工具。CASE工具（tool）：支持特定的软件生存期活动自动化（至少部分自动化）的软件工具。CASE系统（system）：能共享一个公用的用户界面、并且在公用的计算机环境中运行的一组集成化的CASE工具。CASE工具箱（toolkit）：一组集成化的CASE工具，能够使得软件生存期的一个阶段或一个特殊的软件工作的活动自动化（或部分自动化）。CASE Concepts CASE工作台（workbench）：一组集成化的C

3、ASE工具，能够使得整个软件生存自动化（或提供自动化辅助），包括分析、设计、编码和测试。CASE方法学（methodology）：一种“可自动化”的方法学，它对软件开发和维护的所有方面或者某些方面定义了严格的、类似工程的研究途径。CASE方法学伙伴（methodology companior）：一组CASE工具，这些工具按某一种特殊的CASE方法学自动完成一些任务，并且自动产生由该方法学所要求的文档和其他交付的任务。CASE工作站（workstation）：为CASE工具提供操作平台的一个一层、二层或三层的硬件系统体系结构。CASE Methodology 由于CASE工具对整个信息系统或软件

4、工程开发过程的全面支持，引起了系统开发方法学领域从技术、方法到观念、认知体系的变化，方法学领域也受到了冲击和挑战，从而使CASE演变成了一种独特的、以自动化支持环境为基础的系统开发方法学。结构化方法 面向对象方法 快速原型方法CASE Integration集成化CASE环境的总体结构 界面集成层：用户界面开发工具包，界 面协议。工具集成层：触发执行机制，通信机制。信息集成层：信息与CASE工具的集成，信息与信息的集成。软件工程信息库：元模型，软件开发信息Interface IntegrationCASE界面集成层 界面集成层主要由一个标准化的用户界面开发工具包以及各CASE工具共同遵守的界面

5、协议组成。界面集成有两方面的目标：（1）开发人员可在统一而不是分离的界面框架下操作所有的CASE工具，完成软件开发过程。（2）所有CASE工具的用户界面和操作风格必须协调一致。Tool IntegrationCASE工具集成层 工具集成层负责管理所有的CASE工具并协调它们的行为。在多任务操作系统中，开发人员可以同时启动多个CASE工具，此时工具集成层必须在CASE工具之间进行信息传递和同步。协调CASE工具与软件工程信息库之间的信息流，实施安全检查和审计功能。此外，工具集成层往往还能够收集各CASE工具使用情况的统计信息以便改进软件开发方法，提高环境运行效率。Tool Integration

6、 为了完成上述任务，工具集成层至少要具备执行机制和通信机制：执行机制是指环境能够根据某些软件开发触发CASE工具的启动。此外，执行机制还包含对CASE工具执行过程的其他控制手段，例如挂起、恢复和终止。通信机制是指环境能够在CASE工具之间传递信息。大型软件开发项目的众多开发人员往往是在网络环境下协同完成开发任务的。这就对集成化环境提出了新的要求。为此，工具集成层还应提供分布机制，以便上述基本的执行和通信机制以用户透明的方式在网络分布环境下运行。Information IntegrationCASE信息集成层信息集成包含两方面的内容：信息与CASE工具的集成：主要表现为CASE工具实现了对软件工

7、程信息库中信息对象的某些操作功能。信息与信息之间的集成：指集成环境必须具有表示、维护信息项并利用信息项之间的关系完成相应动作的能力，如一致性和完整性检查，确定信息项修改的影响传播范围等。CASE Repository软件工程信息库 软件工程信息库是集成化环境的核心，它为整个CASE环境提供支持。软件工程信息库要完成对软件信息项的存储、查询、修改与删除等操作，所以它必须具备普通数据库管理系统的大部分基础功能。CASE Repository 除此之外，为了给集成化环境提供良好的信息服务，软件工程信息库还要支持：信息完整性：当信息项目修改或删除时，自动检查信息项之间的一致性，自动完成对相关信息项的必

8、要调整。信息与工具的集成：控制CASE工具和开发人员对信息项的访问，提供友好的信息服务。信息与信息的集成：建立并维护信息项之间的关系。开发方法学的引导与强制：利用元模型引导并强制开发人员按照既定的开发方法学实施软件开发。文档规范化：根据元模型对各类文档的定义，统一生成软件文档。版本控制与配置管理：存储软件信息项的各种版本，为开发人员生成阶段性成果或最终产品自动组合最新版本，并允许在测试过程中随时恢复旧版本。Implementation of CASE Repository 软件工程信息库的实现 考虑到软件开发过程中各类数据的纷繁复杂，仅按常规方法组织软件工程信息库是无法满足要求的。应该将软件信

9、息项不论粒度大小均视为对象，信息库的结构组织为元模型，系统通过元模型管理机制实现各种功能。Metamodel in CASE Repository软件工程信息库的元模型 元模型是对各CASE工具生成的软件开发信息项的元级描述，主要内容为：信息项的定义性描述，包括类型、属性、表示方法、生产者与消费者，等等。在各种粒度级别上的信息项之间的关系和依赖性描述。可能的粒度级别有：数据流程图级、数据项级、代码段级。软件设计规则。例如数据流程图的平衡规则，数据流程图中转换的输入、输出流与其相应过程的输入、输出参数的一致性规则。软件开发过程的工作流程和事件的描述，包括开发阶段界定、里程碑定义、错误发生、需求变

10、更，等等。Metamodel in CASE Repository除上述内容之外，元模型还定义了软件信息的组织形式、CASE工具和软件开发人员访问信息项的途径、数据安全性和完整性控制方法以及为适应新的软件开发项目而对现有元模型进行扩充的方法。CASE Repository除元模型外，软件工程信息库还应包含以下各方面的软件开发信息：有关应用问题及问题领域的描述。各类文档（需求说明，设计文档，源代码，测试方案与用例等）。由软件开发方法学限定的规则与指导性原则。项目规划、可用资源描述和开发历史信息。相对于元模型而言，以上各类信息为目标级信息对象。Implementation of CASE Repo

11、sitory 软件工程信息库的建造过程可以借用传统的数据库管理系统提供的下述技术手段：无冗余的信息储存 事物控制机制 安全机制 用户界面 开放性Implementation of CASE Repository 软件工程信息库的许多高级功能是大多数商用数据库管理系统不能直接支持的：复杂数据结构的存储 信息完整性检查 项目管理 版本控制与配置管理 需求追踪Industry Standard for CASE IntegrationCSAE工具集成的工业标准信息资源字典标准（Information Resource Dictionary Standard,IRDS,ANSI338-1988）。IR

12、DS最初是作为需求分析的数据字典标准而开发的。其主要特征是使用多级元模型并强调信息资源的协调管理，有助于在相关联的CASE工具之间建立信息通道。它支持CASE工具在不同的操作系统平台之间移植。Atherton IDEC工具集成标准（ATIS）。ATIS已被CASE Integration Standards Committee of Software Productivity Consortium采纳。ATIS主要强调软件工程信息库的总体结构定义，支持配置管理、工具集成、数据安全性与跨平台移植。公共ADA接口标准（CAIS）。CAIS侧重于ADA软件开发工具的集成，它为这些工具构成集成化环境定

13、义了接口标准。可移植的通用环境（PCTE）。PCTE是欧共体ESPRIT计划的一部分。它已被Europen Computer Manufacturer Association(ECMA)所接纳。Taxonomy of CASE Tools Business process engineering tools Process modeling and management tools Project planning tools Risk analysis tools Project management tools Requirements tracing tools Metrics and

14、management toolsTaxonomy of CASE Tools Documentation tools System software tools Quality assurance tools Database management tools Software configuration management tools Analysis and design tools PRO/SIM toolsTaxonomy of CASE Tools Interface design and development tools Prototyping tools Programmin

15、g tools Web development tools Integration and testing tools Static analysis tools Dynamic analysis toolsTaxonomy of CASE Tools Test management tools Client/server testing tools Reengineering toolsFormal Methods（形式化方法）研究背景 定义 形式验证 模型检验提高系统可靠性 随着计算机应用的日益普及，今天我们已经很难承受计算机系统发生故障所带来的损失；连续运行已成为现在许多计算机系统的关键

16、需求，一旦发生故障，终止系统运行进行维护是不现实的；提高系统可靠性 测试（testing）或 仿真（simulation）以运行系统（模型）为主要手段发现系统错误。验证（Verification）建立系统模型，确认系统模型是否存在错误。质量管理 在系统开发过程中加强管理，防止可能出现的错误。提高可信度的途径 测试（testing）或 仿真（simulation）无法回答系统一定没有错误这样一类问题 验证（Verification）可以从某一个角度回答系统一定没有错误这样一类问题，从而进一步提高我们对系统可靠性的可信度形式化方法 形式化方法是指为说明和验证复杂计算机系统所采用的基于数学的语言、技

17、术和工具。形式化方法不能确保系统的可靠性，但其可以通过揭示系统的不一致性、歧义性和不完备性来增加我们对系统的理解程度，从而提高我们对系统可靠性的可信度。形式验证 形式化方法包括：说明（specification）验证（verification）形式验证包括：模型检验（model checking）推理验证（theorem proving）模型检验 模型检验是一种自动验证有穷状态系统的技术。模型检验的基本思想是通过遍历系统模型的状态空间来检验系统模型是否满足给定的性质。模型检验 在模型检验中涉及两种形式说明语言：性质说明语言用于描述系统的性质;模型描述语言用于描述系统的模型。模型检验技术用于检验

18、由模型描述语言描述的系统模型是否满足由性质说明语言描述的系统性质。模型检验Finite-state modelTemporal logic formulaModel Checker (F W)OKError traceorLine 5:Line 12:Line 15:Line 21:Line 25:Line 27:Line 41:Line 47:模型检验中的关键技术问题 模型检验中的关键技术问题是如何设计数据结构和算法，用以表示和遍历大规模的系统模型状态空间。解决由多个系统模型的并行组合而形成的状态空间爆炸问题。解决状态空间爆炸问题的途径 状态空间的符号表示 （Symbolic represe

19、ntation of state space）McMillans ordered binary decision diagrams(OBDD),1992,10120 偏序规约技术（Partial order reduction）抽象技术（Abstraction）对称技术（Symmetry）模型检验 关于具有时序性质的并发系统的模型检验理论和技术在工业界已经得到实际的应用。目前模型检验理论和技术的研究热点已经转向实时系统和软件系统。实时和混成系统的模型检验 对于实时系统来说，由于时间的引入，其状态空间是无穷的。要设法遍历无穷的状态空间，这对研究人员来说是一个新的挑战。目前人们关注的主要问题包括：

20、针对典型实时性质开发检验算法 探索解决状态空间过大的有效途径混成系统 混成系统（Hybrid Systems）是一类复杂的计算机系统，这类系统的运行过程中既有连续的状态变化，又有离散的状态变化。混成系统实例水箱监控系统混成系统实例水箱监控系统 初始状态时，水箱中水面的高度为1英寸；水泵打开时，水箱中水面以每秒1英寸的速度上升；水泵关闭时，水箱中水面以每秒2英寸的速度下降；监控器发出信号打开（关闭）水泵到实际打开（关闭）水泵之间有2秒钟的延迟；要求监控器将水箱中的水面高度控制在1至12英寸之间。混成自动机（hybrid automata）S1x=1y=1y 10S2x=1y=1x 1S3x=1y

21、=-2x 2S4x=1y=-2y 5y=1.y=10?x:=0y=5?x:=0 x=2?x=2?混成自动机（hybrid automata）混成自动机是不可判定的；目前国际上相关领域的研究热点在于寻找混成自动机的可判定子集。线性时段性质 线性时段性质可以通过系统在各个状态上的累积时间来约束系统的行为。一个线性时段性质是如下形式的线性积分不等式：ie cisiM 其中si表示系统状态，ci是实型系数，M是实数。线性时段性质 在水箱监控系统中,要求监控器将水箱中的水面高度控制在1至12寸之间，可以表示成以下线性时段性质：s1+s2-2(s3+s4)11 s1+s2-2(s3+s4)0满足性问题 检

22、验混成自动机相对于线性时段性质的满足性问题：一个混成自动机满足一个线性时段性质当且仅当该混成自动机的所有行为满足该线性时段性质。混成自动机的行为表示 混成自动机的行为可以表示如下时间状态序列：(s1,t1)(s2,t2)(sm,tm)其中si表示系统状态，ti表示系统在si上的停留时间,t1,t2,tm必须满足相应的时间约束。带时段约束的规则表达式 在规则表达式中引入时段约束形成带时段约束的规则表达式。时段约束表示成如下形式：a ie cisi b带时段约束的规则表达式R=s0 (s0 (s1,s1=9)R1)(s0 (s1,s1=9)R1 (s2,s2=2)(s0 (s1,s1=9)R1 (

23、s2 s3,s2=2,2s3-s2=5)(s0 (s1,s1=9)R1 (s2 s3 s4,s2=2,2s3-s2=5,s2=2)其中R1=(s2 s3 s4 s1,s2=2,2s3-s2=5,s2=2,s1-2s4=5)*带时段约束的规则表达式 带时段约束的规则表达式不能描述所有混成自动机的行为；带时段约束的规则表达式对应于一类混成自动机；对应于带时段约束的规则表达式的一类混成自动机是可判定的。基于线性规划的验证途径 用带时段约束的规则表达式描述混成自动机的行为，从而线性时段性质相对于混成自动机的满足性问题转化成为相对于规则表达式的满足性问题；基于线性规划的验证途径 对于不包含*运算符的简单

24、规则表达式，由于规则表达式中所包含的时段约束形成了多组线性不等式，同时线性时段性质本身可以作为相应的目标函数，因此验证满足性问题可以转化为一组线性规划问题；基于线性规划的验证途径 对于任意包含*运算符的一般规则表达式R，我们可以找出一个简单规则表达式R，使得R和R在相对于某个给定的线性时段性质P的满足性问题上是等价的，即 R 满足 P 当且仅当 R 满足 P 从而最终将验证满足性问题归结为线性规划问题。模型检验工具 SMV http:/www.cs.cmu.edu/modelcheck/code.html SPIN http:/netlib.bell- HyTech http:/www-cad

25、.eecs.berkeley.edu/tah/HyTech/Kronos http:/www.verimag.imag.fr/PEOPLE/Sergio.Yovine/kronos/index.html UPPAAL http:/www.brics.dk/FormalMethods/UPPAAL/index.htmlSoftware Reuse（软件复用）软件复用定义 软件复用过程 软件复用种类和形式 软件复用经济学 构件 软件体系结构软件复用定义 软件复用是指通过对已有软件的各种有关知识来建立新的软件，这些知识包括：领域知识、开发经验、设计经验、设计决定、体系结构、需求、设计、编码、测试和文

26、档等。软件复用的目的是降低软件开发和维护的成本，提高软件开发效率，提高软件的质量。可复用的软件制品Caper Jones定义了可作为复用候选的10种软件制品（artifacts)：项目计划：软件项目计划的基本结构和许多内容（如进度表、风险分析）都可以跨项目复用，以减少用于制定计划的时间。成本估计：由于不同的项目中经常含有类似的功能，所以有可能在极少修改或不修改的情况下，复用对该功能的成本估计。体系结构：某些应用软件的体系结构往往非常相似，因此有可能创建一组公共的体系结构模板（如，事物处理体系结构），并将那些模板作为可复用的设计框架。需求模型和规约：类和对象模型及其规约是明显的复用候选者，此外，

27、用传统软件工程方法开发的分析模型（如数据流图）也是可复用的。设计：用传统方法开发的体系结构、数据、接口和过程化设计都是复用的候选者，系统设计和对象设计也是可复用的。可复用的软件制品 源代码：经过验证的程序代码是复用的候选者。用户文档和技术文档：即使特定的应用有所不同，但经常可复用部分用户文档和技术文档。用户界面：这是最广泛被复用的软件制品。由于用户界面部分约占一个应用软件的60%的代码量，因此其复用效率极高。数据：在大多数经常被复用的软件制品中，可复用的数据包括：内部表、记录结构以及文件和完整的数据库。测试案例：一旦设计或代码被复用，则其相应的测试案例也应被复用。软件复用的过程 抽象：对已有软

28、件制品的简要描述，从中抽取该制品的本质信息（即可复用部分），屏弃那些细节；选取：用户根据已有软件制品的抽象，寻找、比较和选择最适合他需要的制品（可复用件）；特化：对已有制品（可复用件）的修改或形成它的一个实例（例化后的复用件）；集成：将例化后的复用件集成为应用系统。软件复用的粒度代码和设计拷贝代码拷贝是指从熟悉的已有系统中成块地拷贝其中的源代码，设计拷贝是指拷贝一大块代码，删去其中的内部细节，但保持设计的总体框架。这类复用的特点是从已设计、实现、调试好的类似系统中尽可能多地成块地拷贝源代码。复用者通常是已有软件的开发者，或对已有软件比较熟悉的人，他能较容易地找到软件中可复用的部分，通过手工修改

29、原有的代码，使之符合新的系统要求，在集成时主要解决所拷贝代码与当前系统的命名问题。这类复用的优点是由于对原有系统很熟悉，所以不用花大力气去理解和修改代码，对简单的应用比较有效。其缺点是不同的开发者可能拷贝不同的片段；同时，由于对原有系统过于熟悉，容易受原有设计的影响，难以使其很好地适应新的系统；这类复用通常不适合于复杂的应用。软件复用的粒度源代码复用源代码复用是指复用存放在库中的某种高级程序语言书写的源代码构件。这类复用的特点是构件本身是为复用而开发的，可复用构件存放在一个供大家访问的库中。存放在库中的构件应有一段简明的描述，构件库必须提供有效的构件检索手段，使用者通过设置参数值将其特例化，通

30、过过程调用方式调用构件。这类复用的优点是：构件是参数化的，因此大大减少对构件的人工修改；由于构件已经经过充分的测试，因此可靠性比较高。其缺点是构件库极其庞大。同时，由于构件是为复用而开发的，因此构件一般尽可能的通用，从而增加了额外的开销。软件复用的粒度设计和软件体系结构复用 设计和软件体系结构复用是指对已有的软件体系结构和（或）设计的复用。这类复用的特点是不仅支持高层次的复用，也支持较低层次的复用。设计和软件体系结构可以存放在一个库中，并给以简单的描述。这种库必须对其提供有效的检索，使用者通过良好定义的接口进行集成。这类复用的优点是：可复用较大粒度的软件制品，修改具有局部性。其缺点是难以抽象出

31、简明的描述，存放体系结构的库难以管理。软件复用的粒度应用成序生成器（Application Generators）应用程序生成器是指复用整个软件系统的设计，包括整体的软件体系结构、体系结构中的主要子系统、特定的数据结构和算法等。这类复用的特点是：从高层的领域特定的规约自动生成一个完整的可执行系统，生成器可根据输入的规约填充原先没有 的细节，它通常只针对一些成熟的领域。这类复用的优点是自动化程度高，能获取某个特定领域的标准，以黑盒形式输出结果（应用程序）；其缺点是难以构造特定的应用成序生成器。软件复用的粒度领域特定的软件体系结构（Domain-Specific Software Architec

32、ture,DSSA)DSSA复用是指对特定领域中存在的一个公共体系结构及其构件的复用。DSSA的特点是：需要对领域有透彻的理解才能进行领域建模；库是针对特定领域的；领域模型、基准体系结构（reference architecture）和库随着领域的发展而不断发展。这类复用的优点是复用的程度高，对可复用构件的组合提供了一个通用框架。其缺点是前期投资很大。软件复用的形式垂直式复用和水平式复用 垂直式复用是指在同一应用领域中的复用。由于同一领域中的应用存在许多共性或相似性，因此复用面较广，且有助于获得系统的通用模型。水平式复用是指在不同应用领域中复用通用的软件元素，如数据结构、算法、人机界面等软件元

33、素。由于不同领域的应用一般差异较大，因此除了一些通用软件元素外，很难找到可复用的构件，所以水平式复用相对较少。但是，随着互联网的应用不断发展，中间件以及各种应用平台是水平式复用的典型发展趋势。软件复用的形式组装式复用和生成式复用 组装式复用是事先已有一个可复用构件库，开发软件时从库中选择合适的构件，然后组装成新系统（必要时还要开发一些库中没有的构件）。这类复用的基础是一个逐步完善的、高效的构件库系统，可复用的构件应有简明的便于检索的描述和标准的接口。这类复用主要着重于源代码级的复用。生成式复用是根据待开发软件的形式化描述，通过应用程序生成器自动生成相应的应用软件。软件复用的形式黑盒复用和白盒复

34、用 黑盒复用是指对可复用构件不作任何修改，原封不动地复用。这类可复用构件通常比较通用，它往往具有很好的封装性，并具有标准的接口。这类构件的复用率往往比较高，因此要求有很高的可靠性和质量。白盒复用是指在复用一个构件时需对其进行部分修改，以适应具体应用的需要。软件复用经济学 软件复用有效地缩短了软件开发的时间，降低了开发和维护的成本，提高了软件的质量。软件复用是有代价的：通常，创建和维护一个可复用构件的成本是在单个工程中实现同样功能的模块的成本的1.5-3倍；在开发软件系统时复用一个构件的成本大约是开发与其功能等价的模块的成本的四分之一。一个可复用构件通常要被复用3-5次才能收回其初期开发的成本。

35、软件复用对质量的影响 可复用构件在生产过程中都已经过严格的测试，虽然测试并不能发现可复用构件的所有错误，但在复用过程中，可复用构件的错误不断地被发现和排除，因此随着复用次数的不断增加，可复用构件可看成几乎是无错误的。据有关研究报告，被复用代码中错误率为每千行约有0.9个错误，而新开发代码中的所有错误率是每千行约有4.1个错误。对一个包含60%复用代码的应用程序来说，错误率是每千行约有2.1个错误，比无复用的应用程序错误率大约减少了50%。软件复用对生产率的影响 软件复用应该渗透到软件开发各个阶段，在开发的各个阶段都有可复用的软件制品，复用这些软件制品都能提高相应工作的生产率。影响软件生产率的因

36、素很多，如应用领域、问题的复杂性、开发队伍的结构和大小、方案的时效性、可应用的技术等。由于不同的应用中影响其生产率的因素不同，所以复用对生产率的提高程度也不同。一般来说，大约30%-50%的复用可使生产率提高25%-40%。软件复用对成本的影响 假设不采用软件复用技术开发一个软件系统所需的成本为C1，采用软件复用技术开发同一个软件所需的成本为C2，那么采用软件复用技术所节省的成本不能简单地用C1减去C2来估算。节省成本还应扣除复用相关成本。软件复用对成本的影响与复用相关的成本：领域分析和建模领域体系结构开发为促进复用所增加的文档量可复用软件制品的维护和改进对从外部获取的构件的版税和许可证费可复

37、用构件库的创建（或获取）和操作对生产和消费构件人员的培训 与复用相关的成本应由多个采用复用技术的项目来分担，通常要经过2-3个复用的生产周期（大约3年左右）复用才能带来显著的效益。构 件 构件是指可以被明确标识的软件制品，它可以是需求分析和设计阶段的产品、代码、测试案例、文档或软件开发过程中的其他产品。可复用构件是指可被其他系统的开发者复用，以开发新软件的构件（通常我们说的构件主要是指可复用构件）。对可复用构件的要求 构件设计应该具有较高的通用程度 构件应易于调整 构件应易于组装 构件必须具有可检索性 构件必须经过充分的测试构件模型3C构件模型：概念：是关于“构件做什么”的抽象描述，可以通过概

38、念去理解构件的功能。概念包括接口规约和语义描述两部分。内容：是概念的具体实现，描述构件如何完成概念所刻画的功能。本质上，内容是对一般用户隐蔽的信息，只有那些企图修改构件的人才需要了解这些信息。周境：描述构件和外围环境在概念级和内容级的关系，刻画构件的应用环境，为构件的选用和适应性修改提供指导。构件模型 REBOOT（Reuse Based on Object-Oriented Technology）模型：REBOOT是一种基于呈面（facet）的模型。通过对领域进行分析，得到一组基本的描述特征，这些特征称为呈面。呈面可以描述构件执行的功能、所操作的数据、构件应用的周境或任何其他特征。一个构件通

39、常包括以下呈面：（1）抽象：构件概念的抽象性描述。（2）操作：构件所提供的操作的描述。（3）操作对象：描述操作的对象。（4）依赖：描述构件与外界的依赖关系。构件系统 一个构件系统是提供一组可复用特性的系统产品。这些特性由相互依赖和相互连接的众多构件（包括各种类型、相关联的包和描述的文档）来体现。一个构件系统的规模可大可小，小的可能只有几个构件及其相关的文档。构件系统中的构件存在一些关系，如一个构件可以从其他构件那里继承其功能；可以发送消息给其他构件；可以与其他构件关联、支持协同工作等。一个构件系统不是任意的可复用构件的集合。构件系统通常通过公共的命名协定、标准的错误处理机制和统一的接口使集合中

40、的构件协同工作并工程化。构件库管理 构件的分类存储 构件检索 构件库游览 删除构件 构件使用情况评价建造可复用构件 创建领域构件的设计框架 构造通用性和可变性强的构件创建领域构件的设计框架 在建造构件时，除应遵循已有的设计概念和原则外，还必须考虑应用领域的特征。Binder建议在设计时考虑以下关键问题：标准数据：应该研究应用领域，并标识出标准的全局数据结构（如文件结构和完整的数据库），使得所有设计的构件都可以用这些标准数据结构来刻画。标准接口协议：应该建立三个层次的借口协议：构件内接口、构件外接口以及人机接口。程序模板：程序的结构模型可以作为新程序的体系结构设计的模板。一旦建立了应用领域的标准

41、数据、标准接口协议和程序模板，设计者就有了一个可在其中创建设计的框架，符合这个框架设计出来的新构件在以后该领域的复用中将会有更高的复用概率。构造通用性和可变性强的构件 为了使构件能够较为广泛地被复用，构件应具有较强的通用性和可变性。当一个构件被不同的应用复用时，构件的某些部分可能要修改。为此，我们在构件复用时可能发生变化的一个或多个位置上标识变化点，同时为变化点附加一个或多个变体，这样就形成了一个抽象的构件。当构件被复用时，可根据不同的应用指定不同的变体，使抽象构件例化，以适应特定应用的需要。这样建造的构件就具有较强的通用性和可变性。软件体系结构软件体系结构是指软件总体框架，它由结构元集、结构

42、形以及结构理三部分组成。结构元集为一组构成该体系结构之结构元（构件）。结构元有三类，即处理元、信息元与连接元。处理元为对信息元实施变换（处理）的构件，信息元为含有施与变换之可用信息的构件，连接元为用以连接其他构件的构件。结构形包括特性与联系。特性用以约束结构元的选取，联系则约束不同结构元之间的交互与组织。结构理刻画体系结构设计人员选取体系结构风格、选取结构元以及选取结构形的动因与根据，阐明对系统约束之满足所构成的需求与体系结构风格、结构元以及结构形之间的联系。软件体系结构风格 体系结构风格是各种特定体系结构中诸结构元及形式方面的抽象，它不如特定体系结构约束之严，亦不如特定体系结构完备。领域特定

43、的软件体系结构（DSSA）是适用于某个特定领域中多个应用系统需求的通用软件体系结构，它通常提供一个特定领域的基准体系结构，通过参数化方式定义虚拟机接口、复制机制和继承机制来支持体系结构的可变性和可扩展性。基于构件的软件体系结构风格层次体系结构（layered architecture）风格 层次体系结构是按层次组织软件的一种软件体系结构，其中较高层次中的软件比较低层次中的软件更特殊（或专用），同一层中的系统或子系统具有相同的通用性级别。较高层次是较特殊（或专用）的应用，较低层次是较一般（或通用）的应用。层次体系结构的层数、每层的名称和内容都不是固定的，可随情况而定。软件体系结构ATM出纳员开发

44、票现金管理付款Java发票管理NTWorkstationHP ORBPlus银行客户管理TCP/IP系统软件中间件特定业务应用系统软件体系结构C2体系结构风格C2体系结构风格基本组成包括构件和连接件。在C2体系结构中，构件之间不直接连接，构件之间通过连接件进行通信。当一个构件请求另一个构件服务时，它向与它连接的连接件发送一请求服务的消息，连接件再把消息转发到提供服务的构件。连接件扮演了中介人的角色，它管理与它连接的构件之间的通信。连接件也可与另一连接件连接，以向另一个连接件发送消息。这种体系结构风格能方便地在体系结构中增加、删除、更换构件，并易于实现构件的组装。同时这种体系结构风格也有力地支持分布式计算，一个构件在请求服务时，不必关心提供服务的构件位于分布式系统的哪个接点上，它完全由连接件控制。软件体系结构