面向组件的大规模软件架构


1 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 1 面向组件的大规模软件架构 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 2 面向对象技术弱点 z 在中小规模的软件中,对象和对象之间的协作 关系就能够满足需要。但是当软件规模扩大, 复杂度上升的时候,面向对象技术强调的协作 却表现出另一个极端的特点-耦合度太高导致 的复杂度。这时候就需要有一种新的方法来弥 补面向对象技术的弱点。 2 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 3 大规模软件的特点 z 大规模软件主要特点是复杂度。比较典型的例 子是集成性的项目。软件系统需要将各种各样 的硬件、遗留系统、外部接口整合起来。其间 可能遇到不同的硬件接口,不同的操作系统, 不同的语言,不同的平台,不同的数据库,不 同的消息中间件,不同的网络介质。这些都使 得系统变得非常的复杂。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 4 z 面向对象技术的特点是通过对象之间的职责分 工和高度协作来完成任务。这样的好处是代码 量较少,系统布局合理,重用程度高。但是当 对象的个数大量增加的时候,对象之间的高度 耦合的关系将会使得系统变得复杂,难以理解 。 3 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 5 z 以前对于这个问题的方法是采用包(请参考拙作面向对 象软件开发中对包的相关讨论)作为容器来组织对象, 对象之间的依赖性将转化为包之间的依赖性。这种方法 听起来有道理,但是在实际中仍会出现难以解决的问题 。 z 包仅仅只是容器。这意味着对对象的组织可以是任意的 ,而包之间依赖关系的设计则还是取决于对象的依赖。 此外,包的设计和对象一样,缺乏一个统一的风格。而 统一的风格正是大规模软件设计所必须的,因为这样可 以有效改进系统的可理解性,这一点非常重要。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 6 面向组件编程 z 面向组件编程的缩写是 COP。COP是对OOP的补充,帮助实现更 加优秀的软件结构。组件的粒度可大可小,需要取决于具体的应用 。 z 在COP中有几个重要的概念:服务,服务( Service)是一组接口 ,供客户端程序使用。例如,验证和授权服务,任务调度服务。服 务是系统中各个部件相互调用的接口;组件,组件( Component) 实现了一组服务,此外,组件必须符合容器订立的规范,例如,初 始化,配置、销毁。 z COP是对一种组织代码的思路,尤其是服务和组件这两个概念。在 下文会提到的 Spring框架中,就采用了 COP的思路,将系统看作一 个个的组件,通过定义组件之间的协作关系(通过服务)来完成系 统的构建。这样做的好处是能够隔离变化,合理的划分系统。而框 架的意义就在于定义一个组织组件的方式。 4 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 7 理解组件 z 组件不是一个新的概念,Java中的javaBean规范和EJB 规范都是典型的组件。组件的特点在于他定义了一种通 用的处理方式。例如,JavaBean拥有内视的特性,这样 就可以通过工具来实现JavaBean的可视化。而EJB规范 定义了企业服务中的一些特性,使得EJB容器能够为符 合EJB规范的代码增添企业计算所需要的能力,例如事 务、持久化、池等。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 8 z 组件比起对象来的进步就在于通用的规范的引 入。通用规范往往能够为组件添加新的能力( 就像上面所讨论的),但也给组件添加了限制 ,例如你需要实现EJB的一些接口。以下我们将 讨论组件的一些相关问题: • 组件的粒度 • 针对接口 5 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 9 组件的粒度 z 组件的粒度是和系统的架构息息相关的。组件的粒度确 定了,系统的架构也就确定了。在小规模的软件中,可 能组件的粒度很小,仅相当于普通的对象,但是对于大 规模的系统来说,一个组件可能包括几十,甚至上百个 对象。因此,对使用COP技术的系统来说,需要正确的 定义组件的粒度。较好的定义粒度的方法是对核心流程 进行分析。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 10 针对接口 z 接口和实现分离是COP的基础,没有接口和实 现的分离,就没有COP。接口的高度抽象特性 使得各个组件能够被独立的抽取出来,而不影 响到系统的其它部分。 6 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 11 接口和实现分离好处 z 在模块/组件/对象之间解耦。 z 轻松的抽换实现,而不用修改客户端。 z 用户只需要了解接口,而不需要了解实现细节 。 z 增加了重用的可能性。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 12 Inversion of Control(IOC) z IOC是Inversion of Control的简称。它的原理是 基于OO设计原则的好莱坞原则(The Hollywood Principle):不要访问我,我们将访 问你。也就是说,所有的组件都是被动的( Passive),所有的组件初始化和调用都由容器 负责。 7 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 13 IOC实现的类型 z 基于方法参数调用的Method-based(M) IoC,它把组件 传递给每个方法调用 z 基于接口的Interface-based(I) IoC(通常称为类型1), 它使用接口来声明组件之间的依赖性,例如, Serviceable,Configurable z 基于Setter方法的Setter-based (S) IoC(通常称为类型2 ),它使用setter方法来设置组件之间的依赖性 z 基于构造函数的Constructor-based(C) IoC(通常称为类 型3) ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 14 z IOC模式称为Dependency Injection模式。 z IOC是框架开发的一个基本原理。 z 在开源软件中,不少的容器类框架都采用了IOC 的思路。例如: • PicoContainer(http://www.picocontainer.org/) •Spring(http://www.springframework.org/) 8 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 15 组件污染 z 在IOC的第一类型中,由于组件需要实现一些特定的接口,或是从 某个类集成。这将使得组件受到一些约束(称为 Invasive),例如 组件移植不便。另一种情况是组件需要依赖于一个特定的容器,最 为典型的就是 EJB,组件无法脱离容器单独存在,这也使得组件受 到约束。这两种情况都属于组件污染。 z 最理想的组件是只专注于自身工作的组件,它没有其它额外的逻辑 。不过按照这种标准,目前大部分的代码都是不符合的。因此,目 前在开源软件界出现了一些轻量级的容器框架,典型的如上文提到 的PicoContainer和spring。他们的定位就是提供一个对组件管理的 统一模式,而组件可以单独的使用,也可以放在另一个容器中,容 器仅仅只是为组件提供了一些额外的功能,和组件本身没有直接的 依赖。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 16 z 为什么我们说接口比继承好,很重要的一个原 因就是接口更加灵活,组件的依赖性更弱,同 样的,目前另一种做法则是采用一些标记性的 语言来实现比接口更大的灵活度。例如基于xml 的配置文件,以及J2SE1.5中将要引入的属性。 9 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 17 组件的测试 z 组件和容器的依赖脱离为组件测试提供了一个很好的环 境。我们在测试一节中讨论过容器内测试往往是比较麻 烦的,其原因就是在于上面所说的组件污染问题。例如 在spring框架中,组件是一个标准的JavaBean,你可以 直接编写代码来设置组件的属性和定义组件之间的依赖 关系(适用于自动化测试),也可以把这项工作交给 spring容器(适用于开发和部署)。 z 组件测试在测试的分类中属于集成测试。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 18 理解服务 z 在讨论组件时我们谈论了组件粒度的问题。当组件的粒 度不仅仅限于单个对象的时候。在构成组件的多个对象 中,有些对象处于组件内部,不和其它的组件交互,有 些对象需要和外部组件进行交互。后一种对象起的就是 服务的作用。 z 在设计模式中,这种设计被称为Fa?ade模式。而在OO 语言中,他们相当于接口的概念。不管如何比喻,服务 订立了组件和组件之间的契约。这种契约是稳定的(如 果业务需求是稳定的),不会随着组件内部的变化而发 生变化。 10 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 19 z 要理解这一点也非常的容易。对于一个提供用户认证的 组件,一个可能的服务对用户进行认证和授权,至于组 件内部采用LDAP还是关系数据库来存放用户信息,对 服务来说没有任何的差别。 z 这样做的好处有很多,一是组件之间能够以一种稳定的 方式存在,组件内部的变化不至于扩散到整个软件系统 。二是软件设计将会转向重点设计组件之间的服务,而 组件的实现细节将会隐藏起来,这不但有助于设计者更 好的把握软件的全局架构,而且有助于分工的细化。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 20 z 服务并不是什么新颖的概念,RPC、IDL都是类 似的技术。但我们谈的服务侧重架构和理念, 不涉及到具体的技术,这一点同SOA和 WebService的关系类似-SOA是一个结构性的 概念,而WebService是实现SOA的一种适合的 技术。 11 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 21 z 服务最好实现为接口。原则上服务可以是任何一种技术 :JMS、WebService、RPC、或是简单方法调用。但 是出于服务的稳定性的考虑,我们不应该将一个服务和 具体的技术绑定起来,这样会使的服务发生变化的可能 性增大。在Java语言中,接口是具有极大的灵活性的, 因此,将接口实现为普通的Java接口是较好的选择。不 过,这样做的话,我们也许就不能够使用远程调用, Web服务之类的功能了,不过这并不要紧,以下就是原 因。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 22 服务适配器 z 客户端可以直接使用接口,也可以通过适当的 适配器来将普通的接口服务转换为特定技术实 现的服务。 z 个普通的接口通过适配器模式转换成和特定技 术相关的服务。在JMX技术中,也采用这种方 式,JMX平台能够将一个普通的服务端口通过 适配器进行转换,以适用于各种的协议,例如 http、sock、snmp等等。 12 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 23 AOP技术对服务的帮助 z AOP作为OO技术的补足,能够以一种优雅的方式来处 理系统的横切点。服务层面是应用AOP的绝佳位置 z 一个普通的用户注册服务通过AOP可以动态的添加各种 各样的能力。AOP提供了几个好处,一是能够通过简单 的代码为所有的服务添加功能,而不用为每个服务编写 代码,从而大大节省了代码量;二是把横切点分离出来 ,这样服务仅保留了核心的代码,提高了系统的模块化 程度;最后一点是模块化的增加使得为服务动态的增加 或删除功能成为可能,例如,可以通过配置动态的将新 的Aspect添加到用户注册服务上。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 24 服务的测试 z 服务测试在测试的分类中属于接受测试。服务 概念的引入使得自动化的接受测试变得容易了 。在大规模的软件设计中,业务流程往往涉及 到各种组件通过服务介面的相互协作。所以这 就是测试的重点。回到我们之前讨论的组件粒 度问题,如果此时你编写出的测试代码过于繁 琐,说明组件的设计粒度太小了,如果组件的 粒度太大,你会发现有些测试代码根本无法编 写。 13 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 25 服务的管理 z 服务的管理是一个比较大的话题。一方面,在一个大规 模的系统中,虽然通过组件和服务的形式能够降低系统 的复杂度,但是服务仍然很多,需要进行管理;另一方 面,服务的状态,服务的可用性需要监控和管理,这对 于大规模应用来说是必须的。因此,服务需要一种管理 形式。 z JMX规范提出的目的也是一个对各种不同的组件进行统 一管理。和我们所阐述的有类似之处。JMX分为规范和 远程接口两个部分,在J2SE1.5版本中,JMX已经纳入 到J2SE的范畴中了 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 26 软件总线和软件工厂 z 直到目前为止,软件开发仍然属于手工作坊阶段,如果 要和制造业的水平相对应的话,基本上是处于蒸气机发 明之前的水平。随着软件开发技术的发展,软件开发也 将象制造业一样,步入“工业”时代。不过对于软件开发 来说,机器仍然是代码,只不过这些代码是用来代替开 发人员的编码活动的,他具有比手工编码更高的生产力 。 z 我们把这些高产量的"机器"描述成现代化的软件工厂。 那么,软件工厂到底是什么?要了解软件工厂,我们需 要先了解软件总线的概念。 14 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 27 z COP仅仅只是提出了一个系统划分的基础,要 构成一个完整应用,光有组件和服务还不够, 还需要将组件和服务以一种有效的方式组织起 来,有些文章把这种组织性的代码称为Fabric, 有结构和组织的意思。而在我们的文章中,称 之为软件总线(bus)。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 28 z 软件总线是什么?他和计算机的总线一样,它负责在各个组件中传 递信息流,将各个组件组织起来,完成一个具体的任务。总线是一 个抽象的概念,在实际中总线也是由具体的技术构成。例如,一个 总线可能是一段代码,负责调用各个组件;总线也能是一个消息系 统,负责收集和分派消息;总线也可能是一个工作流系统,负责系 统信息的流转;总线还可能是一个 JMX,负责将消息路由到目标组 件。但无论总线的实现技术是什么,总线的特点就是采用一种松耦 合的方式将组件组织起来。这样,总线本身和挂接在总线上的组件 就是松耦合的,至于组件挂接到总线的形式,也就是我们之前讨论 过的服务和服务适配器要做的事情了。 15 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 29 z 目前的软件总线有三种可能的实现:直接调用 /远程调用 /WebService,MOM,以及工作流,根据应用系统的特点可以采用 不同的总线实现。例如以调用为主的总线适用于那些流程比较明确 的应用,因为流程是硬编码的,变化起来相对麻烦一些。工作流为 主的总线适用于流程比较灵活,需要复杂的分支和人为的干预。 MOM为主的总线则适用于大型的分布式,或是异构的应用,不同 的应用之间以一种松散的方式进行协作。 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 30 z 但是无论采取哪一种的总线实现方式,组件和服务是不变的,变化 的是服务适配器, MOM的服务适配器和工组流的服务适配器是不 同的。MOM的服务适配器主要的工作是将消息中的内容翻译为 POJO,并调用服务;而工作流的服务适配器可能就只是一个基于 当前工作流状态的调用。这样形成的系统架构就是相对稳定、松散 耦合的,不论是组件发生变化,还是总线的技术发生变化,只要服 务和总线的规范是稳定的,整体的软件系统就是稳定的。而服务和 总线规范才是软件组织的核心竞争力所在,而这也正是软件总线的 主要目的。 16 ©中国科学院软件所 2006 Software Engineering, 7th edition. Chapter 1 Slide 31 z 软件工厂在组件和软件总线的基础上发展,并根据组件和软件总线 的技术特点,定义了一系列的管理活动,以提高开发效率。软件工 厂是我们定义的软件质量框架的一种实现方式。对于不同的软件组 织来说,根据自身的研发特点来定义软件工厂的构成是非常重要的 。具体的内容包括管理实践的选择,组件的积累,软件总线的技术 实现。在本系列文章中推荐的前两项实践都属于管理实践范畴的内 容,而第三项实践则偏重于建立软件工厂的底层支撑框架。 z 软件工厂的概念代表了一种新的软件开发模式。他的优势在于能够 把技术和管理结合起来,提高生产力。
还剩15页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 5 金币 [ 分享pdf获得金币 ] 1 人已下载

下载pdf

pdf贡献者

phylong

贡献于2011-08-30

下载需要 5 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf