The Rational Unified Process: An Introduction (3rd Edition)

COMPONENT-BASED DEVELOPMENT

The Rational Unified Process supports component-based development (CBD), which is the creation and deployment of software- intensive systems that are assembled from components , as well as the development and harvesting of such components.

Component-based development is about building quality systems that satisfy business needs quickly, preferably by using parts rather than handcrafting every individual element. It involves crafting the right set of primitive components from which to build families of systems, including the harvesting of components. Some components are made intentionally; others are discovered and adapted .

A definition of component must be broad enough to address conventional components (such as COM/DCOM, CORBA, and Java-Beans components) as well as alternative ones (Web pages, data-base tables, and executables using proprietary communication). At the same time, it shouldn't be so broad as to encompass every possible artifact of a well-structured architecture.

A Definition of Component

A component is a nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces.

Note that component and architecture are two intertwined concepts: the architecture identifies components, their interfaces, and their interactions along several dimensions, and components exist only relative to a given architecture. You cannot mix and match your chosen components if they have not been made to fit.

There are several perspectives on components:

• Runtime components

  The things that are delivered, installed, and run, such as executables, processes, and dynamic link libraries (DLLs). They live at runtime on the deployment platform.

• Development components, as seen from the development organization point of view

  Implementation subsystems that have high internal cohesion and low external coupling and are reusable by other developers. There may not always be a one-to-one relationship between runtime components and development components, but they provide a useful "first cut" at the runtime components.

• Business components

  Cohesive sets of runtime components (or development components) that fulfill a large chunk of business-level functionality and are units of sale, release, or upgrade.