几乎每一个软件设计的基础上，都有一个感知、抽象和分解的方法论。这种理念采用了特定的抽象和分解技术，可以带来更好的设计。在处理变更的场景中，主要有软件开发的组件方式和服务方式，本文分析了它们处理变更的区别。一、核心问题：需求的变化对于企业来说，应对变化是日常生活中必须利用和实现的事实。合并、收购和新技术的引入是商业环境变化的驱动力。业务敏捷性是指企业在不断变化和不可预测的环境中蓬勃发展的能力。了解哪些领域更有可能发生变化，哪些领域不会发生变化对于应对变化至关重要。虽然业务中的许多事情都会发生变化，但有些元素往往会保持不变。中期来看，企业的核心竞争力相对稳定；由于业务程序的变化或采用新技术，企业的经营方式可能会受到变化的影响。从长远来看，企业的几乎每个方面都可能发生变化。为了满足不断变化的业务需求，软件系统必须不断发展。业务系统需求的变化是软件设计的一个事实，但并不是所有的软件开发方式都能解释。对于如何分解系统以应对变化，不同的方法有不同的哲学。在20世纪70年代，开发了结构化分析来处理由许多程序员协作开发的复杂系统。结构分析主要基于功能分解。自上而下的功能分解从系统的顶层描述开始，然后逐步细化这个视图。随着每一次改进，系统被分解成更低级别和更小的模块。自上而下的分解需要确定主要的系统需求和功能，然后在连续的步骤中分解它们，直到可以设计特定功能的模块。虽然功能分解对于更稳定的系统类型是成功的，但它在处理业务变化和后续系统维护方面效果较差。更改数据结构通常需要更改与该结构相关的所有函数。因此，系统很容易变得不稳定，因为微小的修改可能会产生严重的连锁反应。面向对象范式通过将数据及其相应的操作封装在类中来解决重用和维护问题。问题域中的对象概念比数据结构和函数更稳定；因此系统的整体架构通常是稳定的。此外，面向对象范例的内部细节的变化不会延续到系统架构中。软件开发方法大致可以分为两类：需求预测方法和需求适配方法。第一个假设几乎所有问题都可以在编码之前被识别和解决。后者采取更务实的方法，认为业务系统开发是一个渐进的过程，变化是软件设计的一个不可避免的方面，并且预计在每个阶段都会发生。为了满足不断变化的业务需求，软件系统必须不断发展。因此，软件开发过程和维护过程的分离变得越来越不重要。在这里，有两种支持软件持续演化的设计方法：基于组件的开发和基于服务的开发。2、适应需求的变化：组件化和服务化软件生产的灵活性是技术和非技术因素综合作用的结果。在处理变更时，组件和服务之间的差异受到此处讨论的因素的影响。2.1组件：预制装配组件化开发的思想是将软件开发过程工业化，通过装配预制的软件组件来生产软件应用。为了应对变化和不断变化的需求，基于组件的开发有两个基本思想。首先，如果可以从预制软件组件快速组装应用程序，则可以显着改进软件开发。其次，将为开发人员提供越来越多的可互操作的软件组件，包括通用的和专用的。2.2服务：需求与需求实现机制的逻辑分离当客户预订从A到B的火车票时，他既不控制火车的运行也不选择乘务员。在这种情况下，客户只对结果感兴趣，而无法控制实现结果的机制。服务被定义为：“任何一方可能提供给另一方的东西本质上是无形的，不会导致任何行为或所有权的履行。它的生产可能与实体产品相关，也可能不相关。”在Software中，这被称为“松散耦合”。软件服务是一个粗粒度的、可发现的实体，作为单个实例存在并与应用程序和其他服务交互。服务的概念不同于组件的概念，因为服务不定义任何结构约束，而是定义接口。2.3约束面向服务的软件开发模式和基于组件的开发模式虽然有共同的特点，但也有很大的不同。它们的共同特点是软件系统的每一部分都可以独立开发，然后添加到系统中（bind）。但是，它们绑定的方式却大不相同。基于组件的软件假定组件的早期绑定，也就是说，调用单元在运行前就确切地知道要联系哪个组件。基于服务的开发采用更灵活的方法，将绑定推迟到运行时，允许每次都更改供应源。服务方法不仅允许提供者灵活变化，而且随着时间的推移适应需求质量的变化。在基于组件的开发中，软件组件被“开箱即用”并插入到系统中，可能还添加了一些“胶水”代码。在这种情况下，所需功能的确切来源是在运行前确定的。基于服务的应用程序是动态的。一个应用程序可以包含许多服务。对于每项服务，可能存在许多提供相同服务但具有不同质量特征组合的供应商。每次调用服务时，都可以选择不同的提供者来协商条款和条件，然后再最终绑定服务。服务提供者和用户是松耦合的。在这里，一个服务由许多不同的服务组成，以提供某种结果。但是，这种组合对服务消费者来说是透明的。2.4抽象和粒度影响软件变更机制的一个因素是变更的粒度。粒度是指要更改的工件的规模，从粗粒度到中等粒度再到非常细的粒度。粒度是一个相对的概念，只有在特定场景下才能精确定义。例如，如果一项服务实现了银行系统的所有功能，则它可以被认为是粗粒度的。如果它只支持信用余额检查，那么它被认为是细粒度的。在20世纪90年代初的面向对象革命之后，很明显面向对象技术不足以满足现实世界软件系统快速变化的需求。尽管面向对象方法提供了丰富的模型来描述问题域，但它不足以适应不断变化的需求。具体来说，对象过于细粒度，没有明确区分计算和组合方面，并且提出了组件来封装一组对象的计算细节。服务应该在与现实世界的活动或可识别的业务功能相对应的抽象级别上发布。服务及其方法的适当粒度级别相对较粗。服务通常支持单个不同的业务概念或流程。它包含实现业务概念的软件，因此可以在类似的环境中重复使用。2.5传输和通信组件和服务之间交付机制的差异可能是一个革命性的概念。作为面向产品的概念，软件工程主要侧重于为软件生产提供技术和管理支持。组件是面向产品的，其中软件通过CD或其他媒体交付。然而，基于Internet的计算的普及带来了新的概念、机遇和挑战，不仅在提供广泛的一般服务方面提供了机会，而且在重新思考软件交付的方法和模型方面提供了机会。将软件作为服务交付的主要好处包括通过松散耦合提高业务敏捷性的潜力，以及随着业务需求变化而发展的能力。在面向服务的模型中，软件功能作为服务交付，其中需要识别功能的每个服务元素，协商条款和条件，强制执行，然后“丢弃”这允许即使在最小的功能上也可以灵活地进行更改单元级。除了技术模型的差异之外，以服务形式交付软件还带来了新的商业模式，这些模式建立在这一愿景所带来的机遇之上。示例包括计费软件服务的业务模型、服务协商规则以及信任评估和供应。2.6架构组件架构是管理组件间通信的一组接口和交互规则的规范。大多数组件架构代表了一种紧耦合的情况。例如，在CORBA（一种基于组件的体系结构）中，客户端和服务器之间存在紧密耦合，因为两者必须与客户端的框架和服务器端的相应框架共享相同的接口。此外，大多数基于组件的体系结构的实现都是封闭系统，因为它们只能处理专有技术。面向服务的架构（SOA或微服务）是一种设计软件系统的方法，该系统通过已发布和自动发现的接口向最终用户应用程序或其他服务提供服务。服务消费者通过代理与服务提供者分离。面向服务的架构在现有IT环境之上添加了一个抽象层。通常，可以在组件基础设施之上添加一个服务层。3.挑战通过组件或服务实现软件灵活性涉及技术和非技术挑战。在解决方案成为商业现实之前，必须解决这些挑战。3.1信任在软件的上下文中，信任是相信组件或服务将交付其功能性和非功能性义务，如与其相关的描述中所承诺的那样。通过检查源代码来测试组件不是一个实用的解决方案。但是，可以通过在使用前多次测试来部分解决来自未知来源的信任组件。此外，对源代码的任何更改都可能使组件合同规范无效。在基于服务的开发中，信任问题要复杂得多，因为很难预测提供者是否会达到约定的服务水平。当软件作为服务交付时，必须监控服务级别协议的遵守情况。对于由其他服务组成的服务，问题变得更加复杂。在这种情况下，服务的最终质量将取决于组成服务的服务质量。3.2组合管理与动态服务组合相比，由许多组件组成的系统相对可控。随着越来越多的服务提供者在大型分布式系统中暴露他们的服务，人工管理和组合服务变得不可行；该过程必须完全自动化。与这个开放环境相关的是管理回滚、计费、许可和事务语义的问题。3.3适应和高级发现组件选择是一个设计时活动，随后可能需要一些适应。这种改编有时称为胶水代码。在基于服务的开发中，服务发现和选择发生在运行时；也就是说，在确定提供的来源之后。这使得在使用之前测试服务几乎不切实际，因为服务的来源以及使用它的条件可能在两次连续调用之间不同。基于服务的开发中的自动发现是比其前身基于组件的开发最重要的进步。使用组件构建软件的一个主要限制是如何指定组件。专有标准和依赖于实现的组件规范阻碍了基于组件的开发实现其促进重用的主要目标。基于服务的开发中的连接点是服务规范，而不是实现。这提供了实施透明度，并最大限度地减少了变更对软件系统的影响。3.4执行效率运行时绑定的关键概念是服务固有的。虽然实现这样的概念有利于灵活性，但它也会带来执行开销，尤其是在每次调用函数时都需要服务发现和匹配的情况下。4.总结需求变更在许多软件系统的生命周期中至关重要，尤其是那些服务于高度不稳定的业务领域的软件系统。组件和服务虽然相似，但并不相同；它们有不同的方法论和抽象，都支持一定程度的进化。方法论和抽象级别的差异使服务成为更好的变更解决方案。未来的所有软件都可能是基于服务的吗？它更多的是炒作而不是实用性。事实上，服务的概念适用于需求经常变化的系统，其中可以容忍某种低效率。虽然组件是实现服务的好方法，但理想的基于组件的系统不一定会产生理想的面向服务的系统。因此，服务不会完全取代组件，而是补充组件。
