基于构件的软件工程的成功因素 整合的架构进程和组织.doc

基于构件的软件工程的成功因素：整合的架构，进程，和组织简介产品线是一整套应用程序，他们共享同一组的需求，但是在需求也体现重要可变性。CBSE使用这种共性和可变性降低开发的整体成本和时间。产品线式CBSE，系统性的复用，构件基础设施和形成产品线的过程和组织，在它们之间存在着重要的联系。很多组织通过使用将新技术和业务需求和组织的处理成熟度（process maturity）相匹配的方法成功的逐步采用了CBSE。为了有效的开发一个产品线，你需要一个连贯的方法构架系统，设计和构造构件和构件的基础环境（infrastructure），组织架构师、设计和实现人员，并且将开发和商业处理过程转换为基于CBSE的方法。为了有效的开发一个产品线，你需要一个连贯的方法构架系统，设计和构造构件和构件的基础环境（infrastructure），组织架构师、设计和实现人员，并且将开发和商业处理过程转换为基于CBSE的方法。采用了业务处理工程UML建模和SEI处理成熟度框架实现了我的这种目的。这一章内容起初是出现在我的书“Software Reuse: Architecture, Process and Organization for Business and Success”(Jacobson, Griss and Jonsson, 1997)和最近的文章中(Griss 1998, 1999, 2000)。复用驱动的软件工程商业组织(RSEB)是实施基于构件的大规模产品线开发和系统性地复用的一种软件开发组织。业务处理流程和基于模型的技术提供了一种易于理解和系统性的方法适合大规模投资和可变的需求，建立一种基于构件的复用过程。在一些方面，优化和特殊环境将能够允许和要求一些步骤能够删除和修改。构件有效复用的障碍很多的团体通过代码共享或者设计模式进行着一种非正式的复用活动。然而，通过多个应用和项目进行软件构件的系统性复用还处在一种萌芽状态。在从传统的软件开发过渡到基于构件的企业级软件开发的过程中，你得面对很多障碍(Frakes 1994)。为了克服这些障碍，必须探讨下面的这些问题(Jacobson, et al, 1997; Favaro et. al 1998; Pour 1998; Bosch 1999)：1. 商业 ：如何投资构件开发，维护和培训；缺乏对于出售构件的了解；缺乏令人信服的商业案例和能够长期投资经济模式；同时产品线定义过于模糊。2. 过程：:团体开发过程成熟度的低下；面向复用方法和过程的不明确的定义和不熟悉；新合作和管理方法的需要；同时，对构件集和可变性缺少有效的测试和归档方法和模型。3. 组织：:缺乏针对复用活动和企业构件开发的系统性实践；缺乏这方面管理的专业技术和支持。4. 工程：缺乏适当的技术和工具识别，设计，归档，测试，包装和分类可复用的软件构件；极少的易理解标准模式和架构。5. 基础环境：缺少类似UML的广泛使用的标准设计符号；缺少工具和构件；过多不同的编程语言和环境；同时还缺少对于多团队配置管理的支持。在这些软件公司为快速变化的市场，例如基于Web的应用或者电子商务系统，开发软件密集型的产品的时候，他们必须做很多的决定(Griss 1997, 1998)。这些决定包括：1. 时间：在开发分布式软件产品时，快速产品开发和市场敏捷是十分重要的。这种时间的压力是如何影响过程、新的架构、和构件的基础环境、商业评估和组织结构？2. 过程：如何将软件开发过程从严格地特征驱动转变为以复用驱动过程？这意味着取代基于特征称述计划发布（planning releases），采用复用元素驱动的特征的优先级。应该如何选择标准的过程和过程成熟度级别（例如SEI的CMM）？如何使用最敏捷的方法达到广泛使用的目的？复用和CBSE之间有怎样的关系？3. 组织：也许存在着一些阻碍架构系统和构件有效工作的文化和组织问题。谁拥有标准、架构和构件基础环境？谁为构件开发支付费用？构件构件共享有什么缺点？需要什么样措能够施促进组织、管理和度量的变化？4.协调：协调新的和当前的技术和过程改进要避免冗余或冲突的努力。构件开发的新技术和策略与提升过程可预测性，提高质量和降低软件生命周期之间有怎样的关系？优先权如何？需要什么样的标准？5.技术：共同架构、模式和构件基础环境，可复用构件和中介平台是降低软件生命周期的关键。应该使用什么样的符号、标准和技术？他们应该如何引入？应该使用什么样标准工具？图 1 ：产品线CBSE的重要的成功因素商业驱动的产品线l 软件机构在大幅度改善生产周期、成本、生产率、生产柔性和/或协同性方面必须有明显、关键和迫切的需求。l 软件机构生产的软件（应用软件、嵌入式系统或核心构件）必须是这样的软件：形成一条明显的产品线、应用家族或连贯一致的“领域”。面向过程的l 必须为产品架构和构件基础环境、构件和应用程序设计一个清晰的软件开发和维护过程，并遵照执行。l 这些过程必须明确地与复用相结合。它们系统地识别并表述共同点和可变点。它们还包括设计和封装可复用构件的相关标准。构架的l 应用软件、系统或构件必须精心设计和组织以保证它们彼此协调并能满足家族或领域的需求。l 一个良好定义的、分层的、模块化的结构以及各种设计和实现标准（例如UML和设计模式）将大有裨益。有组织的l 需要长期的管理承诺以保证软件机构在机构、训练和人员方面遵循构件复用过程以及和标准一致。l 需要专门的下级团队来负责创建、复用和支持可复用构件。这些团队必须接受训练以遵循特定的程序工作。l 人员必须安排明确的面向复用的工作。为有效地进行复用工作，这些人员应当接受过适当的培训、有合适的技能和合理的报酬。产品线CBSE的重要的成功因素你需要一个系统的方法来有效地调整管理和开发的努力和资源。在Hewlett Packard的工作中以及对Ericsson、 Rational、 Intecs Sistemi和许多HP客户的学习中，我发现成功的大规模的构件复用必须是内部一致和全盘考虑的。首先，基于构件的软件复用计划必须由一个迫切的商业动机驱动，并且和该动机保持一致。这样的动机例如加快产品上市时间和提高市场竞争力。商业动机和产品线开发提供了一种组织性承诺的环境。在该环境中，CBSE将被经济地、技术地、战略性地调整。这将确保过程和技术的变革。一个有效的产品线CBSE计划有如图1所示的重要成功因素。因为变动的巨大和需要细致的合作，我倡导一种为大规模复用而重组软件工程组织的商业过程工程策略(Griss 1995)。这些过程基于Jacobson的使用用例驱动的方法(Jacobson et. al., 1992, 1994)来产生复用驱动的软件工程商业组织(reuse-driven software engineering business ,RSEB)，一种综合的模型驱动的方法。整合架构、过程和机构一个RSEB 是作为一种软件工程商业组织来运行。软件工程目标是实现机构商业目标的关键。因此，软件机构自身运行时必须保证有一定的客户以及财政目标。所有的过程和工作产品应该和这些商业目标保持一致。例如，在许多HP的部门，一个占统治地位的迫切的商业目标就是减少商品的开发时间，但还要在跨越产品家族时保持市场柔性。公司期望这样的产品家族通过使用可复用构件来满足不同客户和国家的需求。例如在HP的一些部门（现在在Agilent）在生产微波设备时，从通常的固件构件出发去生产一个家族的可兼容的能够通过设置以适合多种环境的测试设备。建立了一个跨部门的团队来创造产品家族的架构和设计最初的构件。部门中其他的团队按照该架构生产一致性的构件，或使用它们来开发应用程序。一个最终的团队被建立起来，它负责支持和维护构件。启动和整合这些部门的努力需要高级管理层的支持。高级管理层必须制定决策来建立一个或多个复用驱动的部门，并且创建一个它们能够共同工作的环境。这些部门将生产多个相关的应用，这些应用由构件产品和构件复用优化，由此形成一条清晰的基于构件的产品线。一个机构只有在得到一个适合的管理承诺时才发生变革，例如来自高级管理层的战略声明（比如提高产品开发速度）和一个足够的长期预算。商业得失的权衡，例如成本、上市时间和利润必须通过使用定义良好的经济、产品和工程措施来管理。使用标准建模语言来进行模型驱动的开发图2 概括了使用统一建模语言（UML，Booch,et al. 1999，一种OMG标准建模语言）的RSEB的关键元素：椭圆形代表了表示软件工程过程的商业用例，而标签化的矩形是代表UML模型因素集的系统。带箭头的人形图像是行为者，代表了与RSEB交互的人或组织。图2中的每个系统都是通过一套UML模型来表示。UML为软件设计者提供了广阔的空间来设计和重用准确的而又被广泛理解的软件设计和可重用基本构架。如下所述，我们使用同样的符号来为RSEB过程建模。架构当我试图按照第1章和第3章的术语调整我的词汇时，因为CBSE的这些领域还不成熟，词汇还是有一些不一致。在软件工程领域人们越发重视软件架构的重要性(Jacobson et al., 1997; Griss et al.,1998, Garlan and Shaw, 1996, Kruchten, 1995;Buschmann, et al. 1996; Mowbray and Malveau, 1997)。“架构描述了在子系统层面的软件的静态组织，这些子系统通过接口互连；架构还从很重要的高度定义了这些软件子系统是怎样互连的。” (Garlan and Shaw, 1996) 其它的定义还通过使用用例和交互图来包含一些重要的行为和关键的机制。和一个建筑架构师如何同客户和公司一起分析需求和设计建筑的技术趋势的过程类似，一个软件构架师“设计和维护一个系统的架构，也就是说，用例、设计、实施和测试模块的核心部分；构架决定了系统中使用的架构的风格和模式。”(Jacobson, 1994) 我相信对于大规模系统家族和产品线来说，架构师和架构的独特作用是至关重要的。构件和构件系统在我的书中，我使用术语构件来表示任何一个开发模块的可复用元素，该元素和其他的元素松散耦合，并且为复用而设计和封装。由于这泛化了第一章和第三章中的定义，并且可能会和本书中的其它概念混淆，我们将使用一个稍作修改的术语来区分可复用构件和其它的可复用元素，这些可复用元素是构件详细规范和精心成果的一部分。我们称这些可复用元素为构件元素（component element）。然而，为了和RSEB书籍保持一致，我们不能创新全新的词汇。当一个新的工作产品被开发出来时，任何一个模型元素或软件工程工作产品都能为复用而设计和复用。意欲被系统复用的工作产品必须为复用而设计、封装和归档。这样的候选者包括：用例、类、接口、模式、测试和源文件(例如Java Beans, Ada 包, C+ 代码, VB script)。在RSEB书籍中，我们称所有这些为构件。这些不仅仅是模块，因为它们设计时与一种架构保持一致，并补足和完善一个构件。一个构件系统是一组互联的可复用构件和构件元素。它们通过关联和接口连接。这些接口在一个多层的构件的基本环境中交互。一个构件系统在潜在的重用者面前，是通过一个包含最小信息量的正面（faade）以及模块元素来表现的。需要通过这些模块元素来有效地复用构件系统。（请注意faade是一个UML1.3和RSEB的术语，该术语描述了一些公共元素的一个封装，以供外部引用；它不同于接口的概念，并可能包含任何下述的模型元素：意欲成为在将要创建的应用中被复用的模型。Faade主要表现为一个描述构件系统的一致的外部视图的子集模型。在某些程度上，faade扩展并丰富了常见的接口的概念。）一个产品线的公共性和可变性是通过构件和可复用构件元素的可变点和变量来明确表示的。一些可复用工作产品可以直接使用，另外一些使用前要做一些修改。如下图所示，许多机制都能被用来实现可变性（例如参数化、继承、扩展、模版和生成器）。分层的构件基础环境即使是使用通用平台和类库，对现有的软件进行复用来生产一个兼容的、可复用的、可维护的内部一致的软件集也是困难的。你只能通过开发和维护一个作为组织资产的复用基础环境（架构、框架集和构件集）来生产可复用软件集。我们把应用程序设计成有着一个模块化的分层的架构的分层的系统。每一个应用程序表现为一个单独的应用系统（模型和其它工作产品的一个一致的集合）。系统在构造时低级的构件和构件元素是从更低级的构件系统中抽取。应用层下面的层次包含了面向特定商业或应用领域的构件（例如银行系统或微波设备）、通用跨领域中间件构件（包括对象访问代理（ORBs）、数据库和图形用户界面（GUIs）和平台相关（硬件和软件）的软件构件和接口（例如操作系统、网络和特定设备）。这种分层的架构和构件基础环境为机构中的每个员工理解和应用所需的工程实践提供了构件并指明了方向。构件基础环境支持跨平台的公开的灵活的接口。相同接口的不同实现将具有插口兼容的特性。一种典型的情况是：提供的所需接口将在一个或多个正面中与其它相关的可复用模型元素包装在一起。最后，当新的技术和机遇出现时，基础环境给构件系统提供了独立升级的空间。应用软件和应用系统应用软件是通过一组互联的UML模型和其它被称为应用系统的工作产品来定义的。应用软件工程师（架构师、设计师和开发人员）和其它的“重用者”（例如高级工程师）通过选择构件和把构件集成为系统来生成应用软件。在软件开发的早期阶段，他们将使用可重用的模块化的用例。在后来的阶段，他们使用可复用的设计构件或代码类。试图从多个构件中集成用例对于开发者而言很重要，因为在这个过程中，他们将发现各种构件在集成时产生的问题。产品线CSBE过程和组织CBSE的产品线方法通过一个或更多的团队复用其他团队开发的构件来建立基于构件的系统。软件机构并不是彼此独立地创建每一个相关的应用软件，而是有目的地提前地生产可复用资产，这些资产以后可以被快速并经济地用来生产应用程序。RSEB联系了过去的独立的项目，引进了新的构件基础环境，改变了开发过程，引进了针对可复用构件的管理和投资行为，改变了设计师、过程工程师和开发工程师以及管理人员的角色。总之，引入了重大的组织变革。RSEB把商业过程管理引入软件工程组织之中。商业用例对核心软件开发过程进行建模，这种核心软件开发过程例如构件工程师和应用工程师所遵循的开发过程。这些模型今后进一步完善，并被用来定义工人的角色和职责、他们应用的工作流、他们使用的信息系统和工具。不同的商业模型结构可以让我们对不同的组织建模。如图2中一个商业用例所示，在一个RSEB中三个重要的软件工程过程分别是：应用软件家族工程、应用系统工程和构件系统工程。应用软件家族工程应用软件家族工程为产品线方法创建分层的系统架构和构件基础环境，并决定如何把所有的应用软件集分解为应用系统和支持构件的系统。设计这个构架过程是为了努力创造完全支持产品线方法的子系统的层次、正面和接口，以及构件系统。应用软件家族工程师（架构师或高级设计师）必须：1理解类似系统现在用户的需求，以及潜在用户在将来的应用软件中可能的需求；2. 开发一个分层的基本环境，该环境要求足够的强壮以至于能够经受今后不可避免的发生变化的考验；3. 鉴别构件系统以及单独的应用软件；4. 对已有的软件进行包装、重构或界面处理。这样的软件包括遗产系统和/或构件生成器系统。应用系统工程应用系统工程过程从一个或多个构件系统（人们通过一个适当的正面发现这些构件系统）中选取、改造和组装构件和构件元素来形成完整的应用系统。这一过程使用构件系统明确提供的合适的工具、方法、过程和指南。当用户需要一个应用软件的新版本的时候，这一过程开始。开发者（也是包括架构师）首先从一些信息源，主要是客户和终端用户，那里得到需求。然后开发者用手头能得到的构件基础环境来表达需求。某些需求通过复用或改造一些构件就可以满足。如果整个基础环境设计良好，而且能获得足够的构件，那么开发者（由构件库管理员协助）能够找到一个合适的构件或构件元素来复用。当不能获得合适的可复用构件或其它工作产品时，开发者可能就得设计一个新的构件和软件来满足需求。复用者可能要运用可变机制来改造构件以适合特定的应用软件。在对一个应用或构件系统建模和实现过程中，复用者为生产一个专门的组件在特定的变化点将会插入预先提供的或定制的变量（该变量可能是一个完整的辅助构件或其它的可复用构件元素，或其他复用者开发的软件元素）。例如，如果一个黑箱构件的可变机制是说明清晰的参数，那么把参数置为确定值，其中可能包括把一些引用绑定到其它的构件，这一过程就是附系“attaching”。对于另外一种情况，如果构件明确定义了需要的接口，那么必须插入匹配这些接口的较小的构件或其它计算元素。最后，如果构件是定义抽象或具体类的框架，那么必须提供继承这些基类的具体的子类来完成应用程序。这样，一个应用系统不但是可定制的，而且是可配置的。构件系统工程构件系统工程过程设计、构造、封装构件从而形成构件系统。这一过程使用合适的代码、模版、模型、字典、文档和可能的定制工具。这一过程开始于复用组织确定需要设计一个新的构件系统的时候。架构师和设计师必须从多种渠道，包括商业模型、架构师、领域专家和应用系统的用户，得到并分析当前的需求和未来的趋势。目标是创建一组指明适合于产品应用家族的共同点和变化点的可复用构件。架构师和开发者（依据决议的范围来）计算把一定数量的功能和变化点加入构件所需的成本和所带来的好处。许多构件设计时将带有变化点和预制变量（pre-built variants），以此来增加它们的可用性。除了使用继承（很不幸，有时被滥用了）这种广为人知的特殊化机制，你还可以使用面向问题的语言、外表（aspects）、参数化的模板和生成器(Bassett 1996; Griss 2000)。工程结束于潜在复用者可获取的构件系统的确证（包括内部测试、最终审核和接受性测试）和封装（包括文档、分类、示例以及和其它构件的比较）工作的完成。请参阅Hedley Apperly的相关章节。成为一个RSEB的渐进变革RSEB使用的是一种商业过程再工程方法，该方法是用来系统地把一个现有组织转化为一个RESB(Jacobson, 1994)。过程中的每一步包括了明确的组织变革管理指导方针，例如对拥护者的使用；包括了一些复用语用论（pragmatics），例如对增量的实验驱动（pilot-driven）的采纳复用的使用；还包括了明显不同的复用成熟度阶段。为了制定合理的转变计划，一个组织必须评定重要的商业驱动因素和领域驱动因素，以及组织过程成熟度。复用和过程成熟度当考虑向系统的CBSE转变时要面临的一个重要的问题是组织过程成熟度，特别的，是指软件工程过程成熟度，象软件工程研究院的能力成熟度模型（CMM）(Paulk 1993; Humphrey 1996)所表述的那样。实际上，复用和CMM是密切相关的，因为引入系统的软件复用就是一个意义深远的过程改进，而改进源于重要的商业需求。CMM是一个过程改进框架，该框架概括了成熟软件过程的关键指导方针，而这些方针可以直接被用于改进的复用实践(Humphrey 1996; Paulk, 1993)。要得到一组并发的、已管理的、受支持的多项目生产过程，需要重大的组织变革和贯穿整个组织的标准化的生产过程。一般说来，制定一个有效的计划把增量式的采纳复用规划和SEI过程改进规划结合起来有很深远的商业意义(Griss 1998a, 1998b)。许多知道CMM的软件工程师和管理者认为在达到CMM3级（已定义级）之前应该推迟复用。也就是说，要等到整个组织能够遵循一个明确定义的生产过程的时候才行。然而，尽管有成本效益的、全组织的软件复用需要CMM3级或更高级的规范和正式的过程特征，但是对于低级别CMM，也可以采用渐增复用的重要过程。即使是更少量的复用在达到某些商业目标时也具有很大的价值，例如缩短商品上市时间。更多的细节参阅(Griss 1998a, 1998b)。渐进式的CBSE的采用我发现在引入CBSE时最好采用渐进的方式，也就是说，对组织和过程的改进要通过一系列的步骤。对于大多数的组织来说，最好把分阶段的改进步骤集中在一组小规模的试验计划之上。各阶段被概括为如图3所示的简化的复用成熟度模型。该模型部分基于在HP的工作经验和对CMM的使用。当组织的商业需求变得非常迫切以至于要引发变革的时候，组织就准备好从一个阶段转变为另一个阶段。这些阶段是：RMM1-没有复用：可能会共享一些代码，但人们的工作在互不相关的项目中独立工作。他们并不对各自的代码进行交流，而且还对“全部是自己做的”做法引以为豪。RMM2-非正式的代码救助：当开发者彼此信任（包括代码）的时候，他们开始从一个系统拷贝和调整代码段到新系统中。尽管他们可能更愿意重写代码，但是他们还是拷贝代码以减少项目消耗的时间。RMM3-已计划的黑盒代码复用：非正式的代码救助可以减少开发和测试时间，但维护的问题凸现出来。必须管理构件的多份拷贝，每一份略有不同。一份拷贝中发现的缺陷必须被多次查找和修正。下一阶段是已计划的黑盒代码复用，在这一阶段中经过精心选择的代码实例被再次加工成为构件，并且为了复用而进一步测试和归档。这些代码实例被不加改变的复用。RMM4-已管理的工作产品重用：为了在全组织范围内推广复用，你需要一个能够支持数量不断增加的复用者的过程。是不是每个人都应该被“强制”使用唯一的标准版本？多个版本都应该被维护吗？允许改写吗？谁来决定？哪些还可以复用？这一阶段通向一个已定义的构件管理过程，该过程有着明确的创建和复用计划，以及一个支持性的组织。员工在使用这些构件时需要接受培训和帮助。还需要强有力的配置管理过程和工具。RMM5-已架构的