项目研究开发方法和技术路线(并包括实践方法和安排

项目研究开发和技术路线(并包括实践方法和安排 二、 正文: 2.1 项目研究开发方法和技术路线(并包括实践方法和安排、计算方法等) 2.1.1 构件模型 构件是由内容和接口两部分组成的，而接口实际上包括两个部分:构件功能以及该构件与外界的关系。这完全符合3C模型，3C模型是Will Tracz在1989年的“Reuse in Practice Workshop”提出的一个具有指导性的构件模型。该模型是从三个不同方面来描述构件的，即概念(concept)、内容(content)和语境(context)三个方面: , 概念:关于“构件做什么”的抽象描述，可以通过概念去理解构件的功能。 概念包括语法结构和语义描述两个部分，其中语法结构部分负责描述构件 中每个操作的语法结构(如参数个数、参数类型以及返回值类型等)，而语 义描述部分至少包括构件中每个操作的前后置条件以及整个构件的不变 式等内容。 , 内容:概念的具体实现，描述构件如何完成概念所刻划的功能。 , 语境:构件和外围环境在概念级和内容级的关系。语境刻划构件的应用环 境，为构件的选用和适应性修改提供指导。 在不同的层次、从不同的角度，人们所关心的构件的内容自然是有所不同的，因此导致目前存在多种不同的构件模型。构件组装所关心的构件模型主要有实现模型和规约/组装模型。 首先，从构件实现和系统生成/构造的角度，需要构件的具体实现模型，这类模型实际上是和具体的运行平台相关联的，该模型用于指导(当然，可在源代码和目标码两个层次上进行)。这类模型可以称之为构件的基础设施模型(Infrastructure Model of Component)或构件的实现模型(Implementation Model of Component)，CORBA、COM/DCOM、JAVABEANS是这类模型的典型代表。 5 其次，从构件制作和构件组装的角度来看，需要为可以直接复用的构件建模，该模型的重点应该是放在对可直接复用构件的规约和组装的支持上，称为构件的规约/组装模型(Model for Component Specification/Composition)。复用的目的最终自然是为了构造可运行的系统，因此，凡是以本来面目或某种变体存在于最终系统的构件，即是可直接复用的构件。在这个意义下，可直接复用的构件通常应该呈源代码或目标码表示形式。如果做适当推广，考虑需求规约和系统也是最终系统不可分割的一部分，而且在需求规约和系统设计过程中使用了已有构件，那么这类构件也可称为可直接复用的构件，本期课开发的构件组装工具就是针对包含了需求规约、系统设计、源代码或目标码的完整构件。构件规约/组装模型的目标是给出这类构件的规约，同时该模型也通过描述构件规约间的关系来组装构件。 直觉上，定义一个统一的满足不同需求的构件模型是一个诱人的目标，但现有的实现级构件模型的特点及其应用决定了这一目标是不切实际的。同时，由于软件体系结构的兴起，构件组装关注的构件模型已经从构件自身的构造与实现转向构件间关系的描述与实现。 2.1.1.1 构件的规约/组装模型 目前最流行的实现级构件模型是SUN公司的Enterprise JavaBean (EJB)，OMG的CORBA Component Model (CCM)，和Microsoft的Component Object Model (COM)。由于抽象层次的不同，构件的实现模型无法满足构件规约和组装的需求，必须定义相应的构件模型，这类模型已经有许多，当然能力大小各有不同，各类的MIL、IDL、CDL、ADL的语言模型也就是规约/组装模型。我们的构件组装模型是对青鸟构件模型的扩展，如下图所示。其中， , 外部接口 构件的外部接口是指构件向其复用者提供的基本信息，包括:构件名称、功能描述、对外功能接口、所需的构件、参数化属性。 , 内部结构 构件的内部结构包括两方面内容:内部成员，以及成员之间的关系。其中，内部成员包括具体成员与虚拟成员，而成员关系包括内部成员之间的互联，以 6 及内部成员与外部接口之间的互联。 在我们的研究中，通过扩展青鸟的构件描述语言CDL,即增加构架的描述能力、增加连接件的描述能力、加强语义表达能力、描述构件交互的动态行为等，形成了体系结构描述语言ADL(这部分将在构件描述语言中详述)。同时由于现有实现模型的特点及应用范围，决定了规约/组装模型不可能取代而只能利用现有的实现模型，因此，如何将规约/组装模型自动或半自动地映射到某个具体的实现模型，或者针对某具体实现模型研究自动或半自动的辅助工具也是关键技术(这部分将在构件组装工具中详述)。 2.1.1.2 面向SA的构件组装 正是由于目前构件的实现模型在构件自身的定义、外部标识、内部构造、开发与运行环境的支持等方面已经趋于完善，并得到广泛应用，构件组装关心的构件模型的研究重点已经由构件自身转向构件之间的关系，为此，本课题的构件模型在完善JBCOM的ADL的同时，着重研究软件体系结构及面向SA的构件组装模型。 .1) 软件体系结构 对任意大型软件系统而言，当前一个基本的共识是:其总体结构，即其计算元素和它们之间交互的高层组织，是系统设计的一个关键方面[Garlan,93]。软件体系结构(SA)的研究和实践旨在使得一个系统的体系结 7 构显式化，以在高抽象层次处理诸如全局组织和控制结构、功能到计算元素的分配、计算元素间的高层交互等设计问题[Allen,94]。目前没有关于SA公认的定义，但从各个定义可以归纳出，SA必定包含构件和连接子(或连接、交互)这两种系统中最主要的实体，其中构件是系统中的计算元素，连接子是计算元素之间的高层交互。目前SA研究与实践致力于显式化系统的体系结构，处理高层的设计问题，为计算单元分配功能，考虑这些单元之间的高层交互。SA研究的一个重要贡献就是:将原来隐藏和散布在系统的模块中的连接子显式化并独立出来，视为系统中的一阶实体，从而提供了一种在系统的高抽象层次观察、设计系统并推理系统行为和性质的方式，也提供了设计和实现可复用性更好的构件、甚至复用连接子的途径。 目前已提取的连接子有procedure call, data sharing, file I/O, RPC, RTScheduler, PLBundler, pipes, event broadcast, client-server protocols等，同时也在研究用户自定义连接子和组合连接子。这些工作仅仅是将连接子视为一个设计概念，在系统的SA设计阶段才引入连接子的存在。但连接子不仅仅是一个设计空间的概念，它也是一个存在于问题空间的概念，从而，连接子应该在需求阶段，甚至在软件生命周期的其它阶段得到与构件同等的处理(都是一阶实体，first-class entity)，即在基于构件的软件工程中，构件与连接子是同等重要的。 连接子在软件生命期中可分为三类，问题域连接子、设计域连接子、运行期连接子: ? 问题域连接子:从用户需求定义中提取，实际上这种连接子指定了构件之 间的交互。可分为复杂和简单两类:简单连接子是可以直接由以存在 的设计域连接子精化或实现，而复杂连接子则无法由设计域连接子直接实 现，此时就要使用用户自定义连接子。注意，在需求阶段不用考虑两者的 区别，只需提取并标示即可，实现是设计阶段的问题。 ? 设计域连接子:这类连接子精化或实现问题域连接子。从实现角度而言， 可分为用户自定义连接子和原语连接子两类。用户自定义连接子指定了复 杂的交互协议，可能需要一组对象来实现，原语连接子就是已经存在的连 接子。从设计阶段所起的作用而言，又可分为真实连接子和人工连接子两 8 类，前者用于实现来自问题域的构件之间的交互，后者则是实现某些由于 设计的考虑而添加的非问题域构件之间的交互。(可见，构件在设计阶段与 需求阶段不是一一对应的) ? 可运行连接子:这是设计域连接子的最终实现。设计域连接子有两种实现 途径，大多数用户自定义连接子都用具体的程序模块实现，因此这些连接 子是独立的实体，可称为用户实现连接子;而原语连接子是由基架 (infrastructure)提供的，如编程语言、操作系统、中间件等提供的通信 功能，可称为基于基架的连接子，从用户程序的角度看，这类连接子不是 独立的实体。 .2) 面向SA的过程模型 考查软件开发方法学发展的历史，一个有趣的现象是:新的思想和技术通常源于并应用于软件生存周期的后期阶段，而最终将被引入到早期阶段。在软件开发中使用的概念和原则越一致，方法学也就越好和越有效。从开发方法学的角度来看，保持在需求和设计间的概念的一致性和可追踪性总是我们追求的目标。例如，起源于60年代的结构化方法学是伴随着结构化程序设计的概念发展的，已存在大量的结构化方法。对每个方法而言，均必须建立结构化分析和结构化设计间的可追踪性，因此研究者们发展出一些技术来机械地将DFD图映射到MSC图以帮助建立在结构化需求规约和结构化设计间的正向和逆向追踪。然而，DFD和MSC在概念和原则上的根本性差异造成了在结构化分析和结构化设计间的缝隙，正是这个缝隙被视为结构化方法学的弱点之一。在过去十年，面向对象方法学正逐步成为流行的软件开发范型，OO方法学的发展类似于结构化方法的发展，起源于面向对象程序设计。OO范型最主要的优势之一是克服了结构化方法的缺点，在OOA和OOD阶段使用一致的基本概念和原则，从而使得OO需求规约和OO设计的映射自然而直接，易于保持可追踪性并支持机械的转换。 人们已经普遍认识到，软件体系结构(SA)是软件开发过程中的一个重要的产品，软件体系结构设计是软件生存周期中的必要阶段。无疑，作为一个重要的设计概念，SA将对软件开发方法学和过程，包括需求工程，产生重要 9 的影响。正如有的研究者已经指出，“SA可以作为整个软件生存周期中的关键里程碑”，“SA对系统工程师、客户、开发者、用户和维护人员的需要的支持蕴含了SA将涉及软件及系统生存期的所有阶段”[Cristina,95]。因此，将SA概念引入需求工程是自然的和合理的。可以想象，如果我们采用传统的方法来产生需求规约，那么，我们要建立需求规约和SA设计间的映射关系将是一件相当困难的事。另一方面，从复用的角度来看，也有必要将SA的概念和原则引入到需求分析和规约中，需求规约也是一种重要的可复用资源。引入SA概念到需求工程阶段至少可以使我们以一种可构造的结构和更利于复用的形式来组织需求规约，作为对传统需求工程途径的一个重要补充[Hong Mei,00]。 下图是一个基于SA的过程模型，这也是我们的构件组装所遵循的过程模型。之所以采用OO范型是因为OO是软件开发的主流范型，能更好地支持复用，目前的构件技术大都是基于OO的。当然，也可采用非OO范型。 面向SA的面向SA的需求分析设计 面向对象的面向对象的实现测试维护需求分析设计 图面向软件体系结构的构件组装过程模型其中各个阶段的主要工作如下: , 面向SA的需求分析:主要活动包括界定问题域边界、明确系统用户及其责 任、从用户角度分析全部的外部行为、提取并定义构件和连接子、制作面 向SA的高层需求规约、检查规约。这些活动是迭代的。本阶段的成果是面 向SA的需求规约，包括构件规约和连接子规约。此规约将作为软件体系建 立和OO分析的基础。 , 面向SA的设计(软件体系的建立):本阶段将通过系统体系设计精化需求 规约，并确定一些全局的设计决策。主要的活动包括研究需求规约、精化 问题域的构件和连接子、创建必须的人造构件和连接子、完成软件体系设 计(包括静态和动态模型)、建立需求规约和SA之间的映射关系、检查SA、 10 给出OOA和OOD阶段的限制。本阶段的成果是系统的SA设计(将作为系统 开发的参考模型)。 , 面向对象的需求分析OOA:本阶段的工作基于面向SA的需求规约和SA设 计中的一些知识细化需求规约。主要活动类似传统的OOA，只是系统已经 得到了适当的划分。本阶段的成果就是最终的需求规约，包括传统OOA中 的不同模型加上SA分析的成果。 , 面向对象的设计OOD:本阶段基于SA设计和详细的需求规约完成完整的系 统设计。主要活动与传统的OOD类似。成果为系统设计，包括不同角度的 模型，是SA和OO需求规约的精化与实现，将作为系统实现的指导。此阶 段中设计者应尽量复用已有的构件、连接子、设计模式和框架。 , 实现阶段:编码，包括构件和连接子的实现以及系统集成。 , 测试阶段:包括类测试、构件测试、连接子测试和集成测试。 , 维护阶段:在保持软件体系结构不变的前提下进行系统的维护和升级。 .3) 用户自定义连接子 连接子是与构件同等重要的一阶实体，是计算实体之间连接和通信关系。目前提取出的连接子是按照SA风格进行划分的，如procedure call, data sharing, file I/O, RPC, RTScheduler, PLBundler, pipes, event broadcast, client-server protocols等。这种连接子其实仅仅是对构件之间通信机制的描述，即描述了构件之间关系的文法，并没有考虑任何语义信息的描述。这就使得构件自己必须维护与其它构件交互的语义信息，这大大降低了构件与连接子的可复用性，因为文法的约束无法解决接口失配的问题。因此，必须允许用户在连接子中描述具体的应用语义，即提供用户自定义连接子。 直觉上，用户自定义连接子需要实现交互协议语义的形式化，这是目前公认的未决难题之一，也是我们在将来(不是现在)必须面对的挑战。我们提出一种交互协议的分类方法，基于此实现了用户自定义连接子，并预留了支持语义形式化的接口。对于连接子而言，通信机制是基础，不论多么复杂的应用协议也必须以通信机制为基础，因此，考察交互协议使用通信机制的方式，有助于区分那些简单的、易于实现的交互协议和复杂的、难以实现甚至目前无法实 11 现的交互协议。假设一条消息就是使用通信机制进行一次通信，下面将从交互协议使用的消息数量、消息是否需要附加处理功能两个方面对交互协议进行分类: 消息无需附加功能 消息需要附加功能 交互协议仅仅使用一条消息，也无交互协议使用一条消息，但必单 需任何附加功能。非用户自定义连须对该消息进行额外的处理。 消接子就是这类。 如基于事件通信机制的生产者 /消费者交互模型，为了避免消息 费者收到无用的事件，需要对 事件进行过滤，如果现有事件 连接子不支持这一功能，就必 须使用用户自定义连接子增加 这一过滤功能。 交互协议使用多条消息才能完成交交互协议使用多条消息，且其多 互，但每条消息无需附加功能。典中至少一条需要附加功能。如 消型的例子就是如CORBA事件服务的果在CORBA事件服务连结初始 使用，客户与事件通道之间连接的化中，在绑定通道的消息传递息 初始化工作包括绑定通道、获取客中需要对客户进行隐式的安全 户管理器、获取代理对象、将自身认证，就需要在这个消息上附 的引用告知代理四个步骤，这四条加安全认证的功能。 消息都是为了完成初始化这个交互 协议，显然，将它们合为一个连接 子比分成四个要合适。 我们对ADL进行了扩展，允许用户从消息数量和消息附加功能两种角度自定义连接子(详情见“构件描述语言”)。目前的组装工具ABCTool也有可视化支持(详情见“构件组装工具”)。当然，目前的附加功能必须由用户提供，ADL及ABCTool仅仅保留该项目的入口，进一步的完善有待于在交互协议形式化上展开。 .4) SA与中间件的集成 在本质上，SA提供了一种自顶向下实现基于构件的复用的途径。任何软件开发技术和方法学的目标是支持有效和高效地生产可执行的系统，但是，由于缺少自动地或机械地将高层抽象转换到低层抽象，特别是从设计到实现，的理论和技术，使得这成为一个非常困难的目标。因此，ADL应该更多地关注 12 体系结构描述的求精和实现，提供支持转换或组装自动化的能力。不幸的是，当前的SA研究大都是局限于体系结构描述和一些高层的性质验证，对体系结构的求精和实现的支持能力明显不足[Hong Mei,00]。 另一方面，基于构件的软件开发(CBSD)提供了一种通过使用现存的中间件基础设施自底向上地实现基于构件的软件复用的途径，强调使用已经开发好的构件来构造软件系统。CBSD的兴起主要是源于下面四个背景[Meyer,99]，研究方面:现代软件工程思想，特别是对复用技术的强调;产业方面:支持用构件建造GUI、数据库和应用的其他部件的一些理论上质朴但实际可用的技术的成功;政治方面:某些主流互操作技术，如CORBA、COM和EJB，的开发者的推动;在软件界:对象技术的广泛使用，提供了建造和使用构件的概念基础和实用工具。CBSD提供了一种自底向上的、基于预先定制包装好的类属元素(构件)来构造应用系统的途径，但是，当前讨论的重点主要局限于基于COM、CORBA和EJB等的二进制构件，这些中间件技术仅仅提供了在实现层次上支持构件交互的基础机制，缺少指导CBSD过程的系统化的方法学，特别是对高抽象层次的构件组装无能为力。实际上，我们没有理由仅仅从这个局限的角度来看待构件，也不应该仅仅是局限于代码级的构件，而是应该涉及到整个软件生存周期。 一种自然的解决是组合这两种途径来实现基于构件的复用，即将SA作为系统蓝图、将中间件技术作为构件组装的运行时支撑框架、使用映射规则和工具来缩小设计和实现间的距离，这也是构件规约/组装模型向构件实现模型映射的理论基础，“构件组装工具”中将详细描述这一方案的实现。 13 14