基于软件架构的设计 (Architecture Based Software Development，ABSD) 强调由商业、质量和功能需求的组合驱动软件架构设计。它强调采用 视角和视图 来描述软件架构，采用 用例和质量属性场景 来描述需求。
基于构件的软件工程（Component-Based Software Engineering, CBSE）将开发的重点从程序编写转移到了基于已有构件的组装。工程师的焦点从“实现”变成了“集成”。
用于 CBSE 的构件应该具备以下特征。
可组装型：对于可组装的构件，所有外部交互必须通过公开定义的接口进行。同时它 还必须对自身信息的外部访问。
可部署性：软件必须是自包含的，必须能作为一个独立实体在提供其构件模型实现的 构件平台上运行。构件总是二进制形式，无须在部署前编译。
文档化：构件必须是完全文档化的，用户根据文档来判断构件是否满足需求。
独立性：构件应该是独立的，应该可以在无其他特殊构件的情况下进行组装和部署， 如确实需要其他构件提供服务，则应显示声明。
标准化：构件标准化意味着在CBSE过程中使用的构件必须符合某种标准化的构件 模型。
这种 CBSE 过程与传统的软件开发过程存在几点不同。
CBSE 早期需要完整的需求，以便尽可能多地识别出可复用的构件。而增量式开发中， 早期并不需要完整的需求。
在过程早期阶段根据可利用的构件来细化和修改需求。如果可利用的构件不能满足用户需求，就应该考虑由复用构件支持的相关需求。通过劝说用户修改需求，以便能节省开支且快速开发系统。
在系统体系结构设计完成后，会有一个进一步的对构件搜索及设计精化的活动。可能 需要为某些构件寻找备用构件，或者修改构件以适合功能和架构的要求。
开发就是将已经找到的构件集成在一起的组装过程。其中包括将构件与构件模型基 础设施集成在一起，有时还需要开发适配器来协调不匹配的构件接口，可能还需要开发额外的功能。
构件和对象相比：
| 构件的特性 | 对象的特性 |
|---|---|
独立部署单元 | 一个实例单元，具有唯一的标志 |
作为第三方的组装单元 | 封装了自己的状态和行为 |
没有可见状态 | 可能具有状态，此状态外部可见 |
此外，一个构件可以包含多个对象。但是一个对象只能属于一个构件。
逻辑构件模型用功能包描述系统的抽象设计，用接口描述每个服务集合，以及功能之间如何交互以满足用户需求，它作为系统的设计蓝图以保证系统提供适当的功能。
物理构件模型用技术设施产品、硬件分布和拓扑结构，以及用于绑定的网络和通信协议描述系统的物理设计，这种架构用于了解系统的性能、吞吐率等许多非功能性属性。
原子构件
构件是一组需要同时部署的原子构件。构件和原子构件的区别在于：
大多数原子构件不会被单独部署。
大多数原子构件都属于一个构件家族，一次部署往往涉及整个家族。
一个原子构件是一个模块和一组资源。 原子构件是部署、版本控制和替换的基本单位。
构件模型
逻辑构件模型用功能包描述系统的抽象设计，用接口描述每个服务集合，以及功能之间如何交互以满足用户需求，它作为系统的设计蓝图以保证系统提供适当的功能。
物理构件模型用技术设施产品、硬件分布和拓扑结构，以及用于绑定的网络和通信协议描述系统的物理设计，这种架构用于了解系统的性能、吞吐率等许多非功能性属性。
面向构件的编程
面向构件的编程(Component-Oriented Programming,COP)关注于如何支持建立面向构件的解决方案。
基于一般OOP风格，面向构件的编程需要下列基本的支持：多态性（可替代性）、模块封装性（高层次信息的隐藏）、后期的绑定和装载(部署独立性）和安全性（类型和模块安全性）。
面向构件的编程仍然缺乏完善的方法学支持。现有的方法学只关注于单个构件本身，并没有充分考虑由于构件的复杂交互而带来的诸多困难，其中的一些问题可以在编程语言和编程方法的层次上进行解决。
构件失配
失配是指在软件复用的过程中，由于待复用构件对最终系统的体系结构和环境的假设与实际状况不同而导致的冲突。在构件组装阶段失配问题主要包括：
由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配。
由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配。
由于系统成分对全局体系结构的假设存在冲突引起的失配等。要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。
CORBA
CORBA 分为三个层次：对象请求代理（Object Request Broker, ORB）、公共对象服务和公共设施。
ORB 规定了分布式对象的定义、接口和语言映射。实现了对象间的通信和互操作。对分布式对象系统间的“软总线”。
公共对象服务：定义于 ORB 之上的服务，提供了并发服务、名字服务、事务、安全等服务。
公共设施：定义了构件框架。提供了可直接被业务对象使用的服务。规定了业务对象有效协作需要的规则。
CORBA CCM(CORBA Component Model) 是一个用于开发和配置分布式应用服务的服务端构件模型规范。主要包括了：
抽象构件模型：描述了服务端构件结构和构件间互操作的结构。
构件容器结构：用以提供通用构件运行和管理环境。支持对安全、事务、持久状态等系统服务的集成。
构件的配置和打包规范。
组件是 CCM 中的一种基本元类型。组件由组件引用表示，而组件引用由对象引用表示。
组件支持多种接口以与其他元素进行交互，这些接口被称为 Ports。CCM 中一共有四种 ports：
Facets
Receptacles
Event sources
Event sinks
属性。
对象适配器（Portable Object Adapter, POA）主要的作用就是在一个 ORB 和真正接收调用并且返回结果的对象实现之间进行协调。
ORB（Object Request Broker，对象请求代理）扮演着至关重要的角色。ORB 是 CORBA 架构的核心部分，它负责管理客户端和服务端之间的通信
对象管理组织 (OMG) 基于 CORBA 基础设施定义了 4 种构件标准：
实体 (Entity) 构件需要长期持久化并主要用于事务性行为，由容器管理其 持久化。
加工 (Process) 构件同样需要容器管理其持久化，但没有客户端可访问的主键。
会话 (Session) 构件不需要容器管理其持久化，其状态信息必须由构件自己管理。
服务 (Service) 构件是无状态的。
J2EE
在一个典型的基于 MVC 的 J2EE 应用中，其构件构成于作用如下：
在一个典型的基于MVC (Model Vlew Controller）的J2EE应用中：
系统的界面由JSP 构件实现。
分发客户请求、有效组织其他构件为客户端提供服务的控制器由 Servlet 构件实现。
数据库相关操作由 Entity Bean 构件实现。
系统核心业务逻辑由 Session Bean 构件实现。
EJB
EJB是企业级Java构件，用于开发和部署多层结构的、分布式的、面向对象的Java应用系统。
EJB分为会话Bean、实体Bean和消息驱动 Bean：
会话Bean：用于实现业务逻辑，它可以是有状态的，也可以是无状态的。每当客户端请求时，容器就会选择一个会话Bean来为客户端服务。 会话Bean可以直接访问数据库，但更多时候，它会通过实体Bean实现数据访问。
实体Bean：用于实现O/R映射，负责将数据库中的表记录映射为内存中的实体对象，事实上，创建一个实体Bean对象相当于新建一条记录，删除一个实体Bean会同时从数据库中删除对应记录，修改一个实体Bean时，容器会自动将实体Bean的状态和数据库同步。
消息驱动Bean是EJB3.0中引入的新的企业Bean，它基于JMS消息，只能接收客户端发送的JMS消息然后处理。MDB实际上是一个异步的无状态会话Bean，客户端调用MDB后无需等待，立刻返回，MDB将异步处理客户请求。这适合于 需要异步处理请求的场合，比如订单处理，这样就能避免客户端长时间的等待一个方法调用直到返回结果。