面向组件和面向框架的软件系统开发方法

1.1面向组件和面向框架的软件系统开发方法
1.1.1面向组件的开发方法
1、面向组件（构件）的方法
（1）面向组件（构件）的方法简述
做为方法论层面的讨论，我们还必须研究一下所谓面向组件的方法，构件也称为组件，它包含了许多关键理论，这些关键理论解决了当今许多备受挑剔的软件问题，这些理论包括：
1)组件件基础设施
2)软件模式
3)软件体系结构
4)基于组件的软件开发
（2）组件可以理解为面向对象软件技术的一种变体
它有四点原则区别于其它思想------“封装”、“多态”、“后期绑定”、“安全”。

因此，从这个角度来说，它和面向对象是类似的。

不过它取消了对于继承的强调。

为什么？
（3）面向组件的方法中更看重“面向接口”开发而尽可能少用“面向继承”
因为，在面向组件的思想中，认为继承是个紧耦合的、白盒的关系，它对大多数打包和复用来说都是不合适的。

组件通过直接调用其它对象或其它组件来实现功能的复用，而不是使用继承来实现它，事实上，在我们后面的讨论中，也会提到面向对象的方法中还是要优先使用组合而不是继承，但在组件方法中则完全摒弃了继承而是调用，在组件术语里，这些调用称作“代理”（delegation）。

2、实现组件技术关键是需要一个规范，这个规范应该定义封装标准，或者说是组件设计的公共结构
理想状态是这个规范应该是在行业以至全球范围内的标准，这样基于该规范来构建我们的应用系统时，就可以在系统、企业乃至整个软件行业中被广泛复用。

3、面向组件的开发方法是如何被具体应用------组件利用组装来创建系统
在组装的过程中，可以把多个组件结合在一起创建一个比较大的实体，如果组件之间
能够匹配用户的请求和服务的规范，它们就能进行交互而不需要额外的代码，这通常被称之为“即插即用”（Plug-and-Play），这也是后期绑定的一种形式。

4、组件方法依赖于“构建基础设施”是不是能够创立
组件方法并不是某种新的思想，它能不能实现，依赖于“构建基础设施”是不是能够创立，这种基础设施的最大特征，就是需要建立一个对语言和平台不敏感的通用标准。

早在20世纪90年代，主要平台供应商就把它们的未来赌在了这个问题上，特别是微软的COM、Sun的EJB、CORBA的请求代理。

（1）微软在整个20世纪90年代一直在推广构件对象模型（Component Object Model ,COM）
COM 是一种用于说明如何建立软件组件的规范，由于使用了统一的接口规范，不同的开发人员创建的COM 组件，可被组合进不同的应用程序中，而且这些COM 组件所使用的语言，可以是完全不同的。

在COM标准中，一个构件也称为一个模块，它可以是一个DLL，称为进程内组件。

也可以是可执行文件，称为进程外组件。

OLE和ActiveX技术都定义了基于COM的构件接口，COM定义了一组API和一个二进制标准，让来自不同语言、不同平台的彼此独立的对象可以互相通信。

COM技术实际上是一种分布式开发的技术标准，这对于一个开发软件的集体来说，是有很大的意义的。

DCOM（Distributed Component Object Model）分布式组件对象模型，后来发展为COM+，这是一种分布式应用程序集成到网络的技术，一个分布式应用程序由多个进程组成，这些进程协作完成一项工作。

DCOM为COM 组件之间的通信透明的提供可靠、安全和有效的支持D，COM可将其应用程序分布到最适合于其顾客和应用程序的位置。

但是，自从微软.net出现以后，COM有明显的弱化趋势，这一点需要引起注意。

（2）Sun的Java语言已经是一个在业界具有很大影响力的语言了
为了在跨平台应用领域取得竞争优势，它在EJB的基础上发展了一系列构件模型，确实这些发展为团队开发提供了便利，但它还是缺乏一项关键功能：易于和其它语言交互，对团体项目而言，这可能是一个严重的限制，而且Java应用程序编程接口（API）不是标准的，比如JDBC这样的流行技术，必须要供应商开发相应的API作为补充。

（3）公共对象请求代理结构（CORBA）是一种用于分布式基础设施的开放系统标准
它得到了多个供应商、行业财团和正式实体的广泛支持，从一开始，CORBA就支持对象和构件模型，可以支持面向消息的中间键和特定领域的API标准，甚至微软的或者Sun 的产品，可以通过CORBA IIOP实现一定程度的互操作。

但是，CORBA也存在不足，比如内存泄漏、一致性、性能都存在一定的问题。

5、面向组件的软件开发模式
面向组件技术的特色在于：迅速、灵活、简洁，面向构件技术之于软件业的意义正如由生产流水线之于工业制造，是软件业发展的必然趋势。

软件业发展到今天，已经不是那种个人花费一段时间即可完成的小软件。

软件越来越复杂，时间越来越短，软件代码也从几百行到现在的上百万行。

把这些代码分解成一些组件完成，可以减少软件系统中的变化因子。

（1）面向组件方法模式
●面向组件技术的思想基础在软件复用，技术基础是根据软件复用思想设计的众多组
件
面向组件将软件系统开发的重心移向如何把应用系统分解成稳定、灵活、可重用的组件和如何利用已有组件库组装出随需而变的应用软件。

●基于面向组件的体系结构可以描述为：系统=框架+组件+组建
框架是所有组件的支撑框架，每个组件实现系统的每个具体功能。

组件，可以视为组件的插入顺序，不同组件的组成顺序不同，其实现的整体功能也就不同。

●面向组件技术将把软件开发分成几种：框架开发设计、组件开发设计、组装系统中
的各个组件
如果用现代的工业生产做比喻，框架设计就是基本的生产机器的开发研究，组件开发就是零件的生产，组装就是把零件组装成汽车、飞机等等各种产品。

（2）面向组件的方法也存在一些必须解决的问题
●组件的质量
面向组件的软件开发技术将系统分解成不同的组件，因此，组件是否高效稳定势必影响整个系统性能。

●标准化和知识产权限制了组件的复用
标准化和知识产权分别从技术角度和法律角度限制了组件的复用。

如何让组件得以更好的储存复用，降低劳动重复劳动量应该从这两方面考虑。

●应用框架技术还不够成熟完善
●关于组件组建技术
要把珍珠串成项链，选择牢固可用的链子是重要的。

同样的，如何把独立的组件组建成一个可用系统，组建技术同样也是举足轻重的。

（3）面向构件开发的不足之处
●系统资源耗费
从软件性能角度看，用面向组件技术开发的软件并不是最佳的。

除了有比较大的代码冗余外，因为它的灵活性在很大程度上是以空间和时间等为代价实现的。

●面向组件开发的风险
从细节来看，组件将组件的实现细节完全封装，如果没有好的文档支持，有可能导致组件的使用结果不是使用者预期的。

比如，组件使用者对某组件的出错机制认识不够
6、面向过程、面向对象和面向构件三种方法的深入思考
我们已经讨论了面向过程方法、面向对象方法和面向构件方法三种方法论的问题，下面的问题是，这三种方法到底是矛盾的还是统一的？
（1）在面向过程方法中，程序是由完成各种算法的过程所组成的
在系统中，过程与数据是分开的，过程要通过直接存取数据来操纵数据，这也是当初存储过程编程系统的直接结果。

当程序与数据相分离的时候，在程序的各部分之间会出现潜在的依赖关系。

如果数据的表现形式变了，则在程序的各个地方会出现各种各样的冲突。

一个最典型的例子就是“千年虫”问题，这个问题简单的只是需要在日期表达上附加“世纪”数字，但不幸的是当初主要系统都是面向过程的方法建立的，人们为了修改错误不得不逐行阅读源代码，产生了灾难性的后果。

（2）面向对象的方法是把访问放到抽象的数据类型（类）里，也就是支持数据封装这样各个模块的关系被分离的，程序被分成了被称为对象（Object）的较小的部分。

每个对象包含了所属系统的一些数据，也就是要对数据存取，只能通过与它们关联的对象。

在这样的情况下，系统能够被分割成模块，这些模块能够分别地加以修改，而数据的改变只是部分的影响直接封装他们的对象。

对象之间通过消息进行通信，消息能够影响对象的状态。

面向对象的方法虽然有它独到的优势，但是我们还会发现，面向对象的方法对软件体系结构的描述还是有缺陷的。

在大多数面向对象的资料里，都缺乏对于软件体系结构的实质性内容。

如此一来，往往给面向对象的方法造成不需要仔细研究软件体系结构的假象，给设计造成一定的混乱，比如坚持使用面向对象的方法控制系统的复杂性和可扩展性，但这样的任务单纯使用面向对象的方法往往力不从心，一定程度上这也是为什么现在很多系统仍然坚持面向过程方法的原因。

面向对象方法饱含了对象模型的连续精化，大多数分析时候的类（通过领域建模）最
终都会转变为体系中的对象，鼓励的是一种渐进迭代的方式完善设计。

这和体系结构本身的思维是矛盾的，结果对象方法往往看重系统的外在表现而忽视可维护的内部系统本身的任何结构需求，伴随着对体系结构原则的无情忽视，快速而反复的原型开发成为成为一种习惯。

今天面向对象的方法得到广泛的应用，一般来说，面向过程的方法起源于学术组织，在学术界的影响恐怕更大。

而面向对象的方法起源于商业组织，在实际软件行业中影响恐怕更大。

事实上面向对象的思想出现，是市场需求的多样性和易变性引发了方法论层面的思考。

结果尽管有种种非议，但面向对象方法还是成为现在最主要的商业软件范型。

软件技术的几乎每个供应商都提供了对象解决方案，政府和商业组织也使用对象技术开发了许多项目，而且引人注目的是，它实现了一些新的业务流程，这些业务流程为组织提供了竞争优势，通过软件复用机制，对象方法可以快速实现一个系统，同时节省各方面的资源。

结果，在学术领域也就开始认真对待这个思想，这是商业和市场影响学术的一个很有意思的范例。

（3）对这些深层次的思考
经过对这些问题进行深层次的思考后，则迫使我们重新审视几种几乎对立的方法！我们不能极端的强调哪种方法更加合理，而是要仔细的研究它们的思维特点，合理的思索和分析我们的设计过程，取其精华互相补充。

要十分的理解两种方法各自的强项是什么？弱项是什么？一般的建议还是面向对象的方法为基础，但在项目控制、整体体系结构设计和分析、数据组织等等方面，面向过程的方法还是可以很好的应用的。

因此在软件架构设计中选取何种方法，根据实际情况，如软件系统特点、规模、技术现状等等，都会决定我们选用何种方法更合适。

甚至只要有需要有可能，我们可以选取其中的一种、两种甚至同时使用两种。

比如，在系统分析过程中，采用面向对象方法具有很强的优势，将整个系统分解成各个对象，分别设计；在各个对象的分析设计中，找出可复用部分，采用面向构件的方法可能会兴利除弊；在特定部分，特别是体系结构和数据的交互，采用面向过程的方法有其优点。

1.1.2面向框架的应用开发
1、什么是框架
（1）框架（framework）是可重用的，半成品的应用程序，可以用来产生专门的定制程序人们将相同类型问题的解决途径进行抽象并提供基本的资源，从而抽取成能够解决某一应用问题的模版；框架其实就是某种特定应用的半成品，也就是一组组件（可重用的业务组件和应用服务组件），同时也是成熟的不断升级的软件。

（2）为什么会出现应用框架
一个应用系统主要是由业务功能组件和应用服务组件所构成的，而其中的应用服务组件是可重用的。

把在不同应用系统中有共性的“内容”抽取出来，做成一个半成品程序——这样的半成品就是所谓的程序框架。

2、框架所体现出的特性
（1）框架是针对特定的问题领域提供服务的
例如，Struts是一个针对Web开发的框架；Spring是一个针对对象管理的框架；而Hibernate是一个针对系统持久层开发的框架
（2）框架和普通软件或类库的区别
开发者不仅可以实现对代码的重用，也能够实现对设计的重用。

3、为什么要用框架
（1）了解面向对象编程和面向组件编程之间的差别
面向对象技术促进了软件重用，但是也只实现了对类和类继承等级别的重用——可重用率是比较低的。

尽管面向组件编程进一步完善了OOP，并使得软件能够以组件等更高的形式来被重用。

但它在系统分析、架构和设计思想等方面并不能加以重用或者重用率并不高——另外，在系统的分布式异构互操作等方面也没有良好的解决方法。

因此，在软件开发中提出了许多方法——如系统体系结构、框架、设计模式等的流行及应用的普及。

（2）为什么要用框架
因为软件系统发展到今天已经很复杂了，特别是服务器端软件，涉及到的知识、内容、
技术问题太多。

在某些方面使用别人成熟的框架，就相当于让别人帮我们完成一些基础工作。

高效开发，提升可延展性，同时降低软件系统的需求变化所可能给软件设计和编码实现带来的“振荡”。

4、采用“应用框架”方式的系统开发的优点
（1）能够实现在分析、设计、类等多层次上的重用
（2）使软件开发与工业化中的大工业生产是一样的模式，利用组件和框架来生产软件产品。

1.1.3面向服务的架构（Service Oritented Architecture，SOA）
1、面向服务的架构
面向服务的架构能帮助企业有效地使用IT资源，使IT系统灵活配合业务需求。

为了使客户能够更加简单地实现向面向服务架构的转变，现在提出了一种新的服务构件模型。

它提供了一种统一的调用方式，从而使得客户可以把不同的组件都可以通过一种标准的接口来封装和调用。

这种服务构件的编程模型可以大大简化客户的编程，提高应用的灵活性，这就是面向服务构件的架构SCA(Service Component Architecture，SCA)。