基于组件的企业级开发.pdf

基于组件的企业级开发软件复用软件复用思想的产生60年代的“软件危机”使程序设计人员明 白难于维护的软件成本是极其高昂的，当 软件的规模不断扩大时，这种软件的综合 成本可以说是没有人能负担的，并且即使 投入了高昂的资金也难以得到可靠的产品,而软件重用的思想是解决这一问题的根本 方法。软件复用软件危机:软件发展第二阶段的末期，由于计算机硬件技术的进步，一些复杂 的、大型的软件开发项目提出来了，但软件开发技术的进步一直未能满 髓集的髓灌髓篝堞髀髀鼬噩决的办法，使问题积主要表现在以下几个方面：a.经费预算经常突破，完成时间一再拖延。b.开发的软件不通满足用户要求。c.开发的软件可维护性差。d.开发的软件可靠性差。软件复用软件危机产生的原因是由于软件产品本身的特点以及开发软件的方 式、方法、技术和人员引起的：a.软件的规模越来越大，结构越来越复杂。b,软件开发管理困难而复杂。c,软件开发费用不断增加。&软件开发技术落后。e.生产方式落后。f.开发工具落后，生产率提高缓慢。软件复用软件复用是指重复使用“为了复用目 的而设计的软件”的过程。软件复用是提高软件生产效率和质量 的有效途径。软件构件（组件）技术是支持软件复 用的核心技术。软件复用软件复用的根本因难(1)技术因素。构件与应用系统之间的差异。一些开发者开发的构件，要做到在被另一些人开发的系统中使用时正好合适，从内容 到对外接口都恰好相符，或者作很少的修改，这不是一件简 单的事；构件要达到一定的数量，才能支持有效的复用，而 大量构件的获得需要有很高的投入和长期的积累；发现合用 构件的困难，当构件达到较大的数量时，使用者要从中找到 一个自己想要的构件，并断定它确实是自己需要的，不是一 件轻而易举的事；基于复用的软件开发方法和软件过程是一 个新的研究实践领域，需要一些新的理论、技术及支持环境,目前这方面的研究成果和实践经验都不够充分。软件复用软件复用的根本因难(2)人的因素。软件开发是一种创造性工作，长期从事这个行业的人 们形成了一种职业习惯：喜欢自己创造而不喜欢使用别人 的东西，特别是当要对别人开填的软件作一些修改再使用 时，他们常常喜欢自己另写一个。(3)管理因素在软件生产的管理中，从以往沿习了一些与复用的目 标很不协调的制度与政策，如计算工作量时，对复用的部 分打很大的折扣，甚至不算工作量；另外，不是在项目开 始时自觉地向着造就可复用构件的方向努力，而是在它完 成之后，看看是否能从中找到一些可复用构件。这些弊端 妨碍了复用水平的提高和复用规模的扩大，甚至会挫伤致 力于复用的人员的积极性。软件复用软件复用的根本因难(4)教育因素在软件科学技术的教育与培训中，缺乏关于软件复用的内容，很 少有这方面的专门教材及课程，即使在其它教材及课程中提到软件复 用，其篇幅及内容也知当薄弱。(5)法律因素在法律上还存在一些问题，例如，一个可复用构件在某个应用系 统中出现了错误，而构件的开发者和应用系统的开发者不是一个厂商,那么责任应该由谁负？止匕外，在版权、政府政策等方面也存在一些悬 而未决的问题。另外，软件产品是一种精神产品，它的产生几乎完全是人脑思维的结果，它的价值，也几乎完全在于其中所凝结的思想；它的物质载体的制造 过程与价值含量都是微不足道的。物质产品的生产受到人类制造能力 的限制，现有的一却物质产品的复杂性都没有超过这种限度，软件却 没有这种限制，只要人的大脑能想到的问题，都可能要求软件去解决,人脑所能思考的问题的复杂性，远远超出了人类能制造的物质产品的 复杂性，因而使软件的复用更为困难。向构件的演变你需要把事物追究到最早的起源，并且考察它们因何并且如何变为退化的，但是仍要向古今两个时代都去求教；向古时要问何者是最良好的；向现时要问何者是最适当的。培根，培根论说文集软件构件实乃一种思想、一种方法，从本质上说，就是 将需求分配到诸如类、包、服务等构件中。其核心思 想还是来自于分割的原理，就像我们研究物质一样，自然界一切物质都由有限数量的元素组成，每种元素 对应着相应的分子或原子等。所以，通过与传统行业 的构件化进程的对比，也许是理解软件构件化的一个 最佳起点。汽车行业的构件史 1.从第一辆蒸汽汽车的产生到第一个汽车构件工厂的诞生1769年，法国人Cugnot制造了世界上第一辆蒸汽驱动三轮 汽车。1885年，德国人KartBenz制成了第一辆苯茨专利机动 车，此车具备了现代汽车的一些基本特点，如火花点火、水冷 循环、钢管车架、钢板弹簧悬架、后轮驱动前轮转向和制动手 把等。这代表第一个汽车构件工厂的产生。2.基于构件的组装，使大规模的快速生产成为可能20世纪80年代，汽车模块化生产方式初露锋芒，技术实力雄 厚的零配件生产商德尔福系统公司相继推出了座舱、接口盘制动、车 门、前端、集成空气/燃油等模块，在现代汽车装配线上注入了新的 概念。计算机软件行业的 构 件史 1,面向机器阶段 2.面向过程阶段 3.面向对象阶段 4.面向构件阶段软件发展的 四个阶段的比较发展阶段关注点思维层次代表性语言面向机器阶 段指令、存 储机器汇编语言面向过程阶 段算法、功 能问题C Fortan等面向对象阶 段抽象、封 装系统C+、Java等面向构件阶 段组 航 复装组织无或XML1.1构件（组件）构件是一个封装的、规范的、可 重用的软件模块，是组织系统的 基本单位。12基于构件（组件）的开发（CBD）把基于组件的开发定义为：通过把现有组 件组装、适配和“挂接”为一种不同配置,构建所有工件的一种方法，包括可执行代 码、接口规格说明、体系结构、业务模型,规模从完整的应用程序和系统，一直到单 个组件。CBSE:基于构件的软件工程(Component-Based Software Engineering)是一本中 软件开发新范型，它是在一定构件模型支 持下，复用构件库中的一个或多个构件或 者并发开发构件，通过组合手段高效率、高质量地构造应用 软件系统的过程。构件模型构 件模型分为 理论模型和 技术模型。理论模型用自然语言给出了构件的定义,例如3c模型。构件的技术模型包括：微软的 COM,Sun J avabean/E JB,C0RBAo3c模型概念：（concept）描述软件构件做什么。它包 括接口规约和语义描述。概念将传达构件的意 图。内容：（content）描述软件构件的概念如何实现。一般来讲，内容是对外来用户隐蔽的信息，是 只有试图修改或测试该构件的人才需要了 解的 信息。上下文：（context）将可复用 的构件安置到 它的 应用论域中。就是说，上下文将通过定义概念 的、操作的和实现的特征，使软件人员能够找 到合适的构件以满足应用的需求。CBSE的终极目标“组装而不创建”软件行业构件化的基本特征(P10)说到戴尔的商业模式，很多人都知道是直接模式。如果再深究一下，什么是直接模式的核心竞争力，那么，供应链管理、按单定制、基于标准等都可能是答案。马文方，你应该知道的戴尔秘密现在，让我们从传统行业出发，简单总结出 面向构件的基本特征。以我们上一节所引述的汽车业为代表，总结 出传统行业已经具备的很多构件化特征，包括以下四点：软件行业构件化的基本特征(P10)按单定做整个生产过程是根据客户的具体要求，“在预先定义 的产品框架之内”，通过“组装预先定义的零件”来 提供个性化产品。第三方零件市场第三方零件市场 在一个成熟的行业里，通常存在一 个繁荣的第三方零件市场，那里所有零件都按照精确 定义的规格和结构制造。有一批公司专门制造高质量 或低成本零件，而不做产品。例如，任何大型汽车厂 商仅生产他们汽车或引擎上的某部分零件。软件行业构 件化的 基本特征(P10)通过更换零件来维护当零件出现故障时，更换整个零件要比修理它来得更 省钱、更轻松。即使我们的消费者并不喜欢这样，但 是在汽车修理行业而言，往往更换一个新的零件比修 理故障零件更经济而高效。供应链生产成本与总体供应链比起来只是很少的一部分。成 功的企业能降低整个供应链的成本(包括生产)，但 同时涵盖分销等环节。CBSE的意义 CBSE从根本上改变了软件生产方式 CBSE提高了软件重用率，保护了已有的投资 CBSE使开发者将更多的注意力放到业务流程 和业务规则上去 CBSE开发的系统维护十分方便 CBSE降低了对系统开发者的要求CBSE的生命周期ACBSE的生命周期分为单个构件的生产和 基于构件的软件开发两个并发的过程，由两个不同 的生产实体来完成。A单个构件的生产分为：构件需求分析、构件生产；A基于构件的软件开发分为：软件需求分 析及设计、构件验证、构件定制、系统 集成、系统测试、系统维护。构件（组件）与类（模块）的区 另1J 封装特性：构件中数据（属性）是完全封装的,只能通过接口来访问数据成员；对象（类）的 使用者与对象往往在同一个程序模块中，可直 接使用。总之，构件的数据成员的封装以构件 模块为边界，对用户是透明的；类的封装特性 是语义上的封装，对用 户是可见的。可重用性：构件的可重用性表现在构件使用另 一个构件的所有功能，在另一个系统中复用；类的可重用性表现在继承。CBSE与00技术的联系与 区别 00*CBSE CBSE更重视封装第二章业务组件方法1组件粒度层次2体系结构视点3开发过程4业务组件方法5业务组件工厂6场景7业务组件方法的适应性2.1组件粒度层次 语舌类 分布式组件 业务组件 业务组件系统 系统级组件联邦分布式组件是指具有以下实现特征的软件工 件：1.具有定义完备的构建时和运行时接口。2.可以独立地插入运行时环境3.可通过网络寻址业务组件是自治业务概念或业务过程的软件 实现。业务组件由必须具备的软件工件组 成，这些工件用来表示、实现和部署一个 给定的业务概念，使业务概念在大型分布 式系统中成为一个自治的、可重用的元素。什么是业务流程业务流程是为达到特定的价值目标而由不同的人分别 共同完成的一系列活动。活动之间不仅有严格的先后 顺序限定，而且活动的内容、方式、责任等也都必须 有明确的安排和界定，以使不同活动在不同岗位角色 之间进行转手交接成为可能。活动与活动之间在时间 和空间上的转移可以有较大的跨度。而狭义的业务流程，则认为它仅仅是与客史价值的满 足相联系的一系列活动。比如说销售业务流程、采购业务流程、银行业务流程寺寺业务流程的意义业务流程对于企业的意义不仅仅在于对企业关键业务的 一种描述；更在于对企业的业务运营有着指导意义，这种意义体现在对资源的优化、对企业组织机构的优 化以及对管理制度的一系列改变。这种优化的目的实际也是企业所追求的目标：降低企业 的运营成本，提高对市场需求的响应速度，争取企业 利润的最大化。业务组件系统是一组组装在一起，以提供业 务问题解决方案的协同业务组件。系统级组件联邦是一种组成联邦，满足属于 不同机构的多个最终用户信息处理需要的 协同系统级组件。2.2体系结构视点体系结构是一套关于软件组织的重要决策,是结构要素及其接口的选择。系统正是通 过这些接口进行组合的，是对这些结构要 素的行为的选择，这些行为相互协作，逐 渐形成更大的子系统和体系结构风格，而 体系结构风格为组织结构提供了指导，也 就是指导这些要素及其接口、它们的协作 和组合。(1)Dewayne Perry和A1 ex Wolf曾这样定义：软件体系结构是具有 一定形式的2吉构化元素，即构件的集合，包括处理构件、数据构件和 连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息,连接构件把体系结构的不同部分组组合连接起来。这一定义注重区分 处理构件、数据构件和连接构件，这一方法在其他的定义和方法中基 本上得到保持。(2)Mary Shaw和David Garlan认为软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。体系结构问题包括总体组织和全局控制、通讯协议、同步、数据存取,的组织，规模和性能，在各设计给设计元素分配特定功能，设与兀系方案间进行选择等。软件体系结构处理算法与数据结构之上关于整体 系统结构设计和描述方面的一些问题，如全局组织和全局控制结构、关于通讯、同步与数据存取的协议，设计构件功能定义，物理分布与 合成，设计方案的选择、评估与实现尊(3)Kruchten指出,软件体系结构有四个角度，它们从 不同方面对系统进行描述：概念角度描述系统的主要构件 及它们之间的关系；模块角度包含功能分解与层次结构；运行角度描述了一个系统的动态结构；代码角度描述了各 种代码和库函数在开发环境中的组织。(4)Hayes Roth则认为软件体系结构是一个抽象的系统 规范：主要包括用基行为来描述的功能构件和构件之间的相互连接、接口和关系。(5)David Garlan和Dewne Perry于 1995年在IEEE软件 工程学报上又采用如下的定义：软件体系结构是一个程序/系统各构件的结构、它们之间的相互关系以及进行设计 的原则和随时间进化的指导方针。(6)Barry Boehm和他的学生提出，一个软件体系结构 包括一个软件和系统构件，互联及约束的集合；一个系统 需求说明的集合；一个基本原理用以说明这一构件，互联 和约束能够满足系统需求。(7)1997年,Bass,Ctements和Kazman在使用软件 体系结构一书中给出如下的定义：一个程序或计算机系 统的软件体系结构包括一个或一组软件构件、软件构件的 外部的可见特性及其相互关系。其中，”软件外部的可见 特性”是指软件构件提供的服务、性能、特性、错误处理、共享资源使用等。2.3开发过程业务组件内的开发过程是以组件为中心的,这是它的主要特征，是一种以体系结构为 中心的方法，它关注的是自治，提供一种 协同方法，表现出很强的迭代属性，假设 连续集成，由风险管理驱动。2.4 业务组件方法业务组件方法定义了大规模分布式业务系 统开发和集成和概念框架，是一种理念、一种实现分布式业务系统的方式，一套技 术、过程、方针、启发性提示、经验规则 和手段。业务组件方法不只是方法论，还 是关于构思、体系结构确定、设计、构建、测试、管理、部署和进化应用系统的一种 完整理念。一种统一概念开发成本,最低依赖5种要素2.5业务组件工厂业务组件工厂是能够经济、快速地以可重 复的方式，为企业大规模生产高质量软件 的高效软件开发能力。2.7 业务组件方法的适用性 基于OLTP的应用程序 批处理应用程序 基于WEB和电子商务应用程序 基于个人计算机的应用程序第3章分布式组件 分布式组件的定义：分布式组件（DC）是能够作为可插入运行 时组件执行环境的二进制组件部署的自治软件 工作产品的一种设计模式。组件执行环境的定义：组件执行环境（CEE）是一种分布式组件 插入并在其中执行的运行时“插座”。组件执 行环境包括已定义的服务、工具和中间件，是 业务组件虚拟机的运行时部分。分布式组件定义中的最重要方面是，它是 一种逻辑概念，一种设计模式。把组件独 立于具体实现技术的一种思考方式。设计模式广义：设计模式是一套被反复使用、多数 人知晓的、经过分类编目的、代码设计经 验的总结。使用设计模式是为了可重用代 码、让代码更容易被他人理解、保证代码 可靠性。狭义：23种设计模式 1.工厂模式：客户类和工厂类分开。消费者任何时 候需要某种产品，只需向工厂请求即可。消费者无 须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向 客户端提供。-2.建造模式：将产品的内部表象和产品的生成过程 分割开来，从而使一个建造过程生成具有不同的内 部表象的产品对象。建造模式使得产品内部表象可 以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过 程。3.工厂方法模式：核心工厂类不再负责所有产品的 创建，而是将具体创建的工作交给子类去做，成为 一个抽象工厂角色，仅负责给出具体工厂类必须实 现的接口，而不接触哪一个产品类应当被实例化这 种细节。-4.原始模型模式：通过给出一个原型对象来指明所 要创建的对象的类型，然后用复制这个原型对象的 方法创建出更多同类型的对象。原始模型模式允许 动态的增加或减小产品类.产品类不需要非得有件 5.单例模式：单例模式确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例单例模 式。单例模式只应在有真正的“单一实例”的需求 时才可值角。-6.适配器（变压器）模式：把一个类的接口变换成 客户端所期待的另一种接口，从而使原本因接口原 因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。7.桥梁模式：将抽象化与实现化脱耦，使得二者可 以独立的变化，也就是说将他们之间的强关联变成 弱关联，也就是指在一个软件系统的抽象化和实现 化之间使用组合/聚合关系而不是继承关系，从而使 两者可以独立的变化。-8.合成模式：合成模式将对象组织到树结构中，可以用来描述整 体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得 客户端把一个个单独的成分对象和由他们复合而成的合成对象同 等看待。-9.装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给 一个对象增加功能，这些功能可以再动态的撤消。增加由一些基 本功能的排列组合而产生的非常大量的功能。10.门面模式：外部与一个子系统的通信必须通过一个统一的门 面对象进行。门面模式提供一个高层次的接口，使得子系统更易 于使用。每一个子系统只有一个门面类，而且此门面类只有一个 实例，也就是说它是一个单例模式。但整个系统可以有多个门面 类。O O O O O O 设计模式（可复用面向对象软件的基础）分布式组件的基本元素功能代码代理网络可寻址接口接口实现器依赖关系插头插座特征：可跟踪性分布式系统支持黑盒与白盒分开考虑组件模型分类：用户分布式组件（UDC）工作间分布式组件（WDC）企业分布式组件（EDC）资源分布式组件（RDC）功能开发人员的程序设计模型规格说明代码隔离分层分布式组件包含两个主要部分：一是功能 程序员要考虑的源可移植的代码，二是特 定于组件实现技术而生成的代码或通用代 码，这些代码是不可移植的。语言类分类业务语言类（表3-1）隔离分层语言类（表3-2）接口接口是对一组客户可以向对象请求的可能 操作的描述。如果对象可以说明为该接口 所描述的每个潜在请求的目标对象，则这 个对象满足该接口。业务数据类型接口操作的参数说明包括操作名称和一 个参数清单，我们把这种参数叫做“业务 事件类型”。业务设计类型是一种软件工件，具有可以传值的 标准业务解释，即用作对业务组件接口操作的一个参 数，或用于在组件和系统之间传递的一个信息元素。第4章业务组件 概念：业务组件是自治业务概念或业务过程的 软件实现。业务组件由必须具备的软件工 件组成，这些工件用来表示、实现和部署 一个给定的业务概念，使业务概念在大型 分布式系统中成为一个自治的、可重用的 元素。一种组件 针对业务组件 所有软件工件 自治业务概念派生概念:拥有关系 修改单元 部署单元 重用单元 管理单元 实现考虑：具有各种体系结构原则和概念的业务组件 可以用任何语言或由业务组件虚拟机支持 的任何组件技术实现。内部要素分布层：用户层 工作间层 企业层 资源层外部要素分布式组件接口的不用可视级:1、业务组件内2、系统内3、系统外运行时接口业务组件的运行时接口是所有系统内和系 统外分布式组件运行时接口的并集。组件的扩展接口描述对该组件的一组访问 点。一个组件访问点是由该组件开发时输 出的，在开发生命周期的任何时刻，从任 何体系结构视点，或在任何分布层上的任 何软件工件（或软件工件的组合）。依赖关系业务组件的外部世界由接口、依赖关系和 插座组成。插座业务组件插座这个次可用来表示一组把业 务组件虚拟机带给业务组件的（扩展）接 口，而相应的业务组件插头这个词表示业 务组件为了满足插座提供的接口要求而提 供的软件工件。开发生命周期:需求阶段 分析阶段 设计阶段 实现阶段 测试阶段 部署阶段相关软件工程才既念 业务对象 模块 UML 包第5章业务组件系统 业务组件系统定义为在一起协同提供业务 问题解决方案的一组业务组件。“业务组件级”这个词表示单个业务组件。“系统级”表示业务组件系统。业务组件组装 把一组业务组件看作一个单元，即把一个 给定业务组件和它所依赖的所有业务组件 作为一个单元处理，我们把这种单元叫做 业务组件组装。产品组装产品组装是一组可以作为一种特有的、有 用的和有完备标识单元向客户交付或销售 的一个或多个业务组件。业务组件图通过图形表示业务组件系统的方法很有用，叫做业务组件图。业务组件图是业务组件方法5维（即粒度维,体系结构视点维，分布层维，功能分类维 和开发生命周期维）中的两维表示。特征定义的含义应用的形式基本和系统业务组件内部要素实用业务组件实体业务组件过程业务组件 辅助业务组件外部要素业务组件系统的运行时接口要么是其组成 业务系统的外部接口的合并，要么是其网 关的接口，可以有两种方式为业务组件系 统提供接口：黑盒方法和白盒方法。