Software Engineering: What is a Component? | An Object-Oriented View | The Traditional View

What is a Component?

A component is a modular building block for computer software.
As per OMG Unified Modeling Language Specification defines
A component is a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.
The true meaning of the term component will differ depending on the point of view of the software engineer who uses it. Based on that,

Three different views of Components

Three important views of what a component is and how it is used as design modeling proceeds.

In the context of object-oriented software engineering, a component contains a set of collaborating classes.
Each class within a component has been fully elaborated to include all attributes and operations that are relevant to its implementation.
As part of the design elaboration, all interfaces that enable the classes to communicate and collaborate with other design classes must also be defined.
To accomplish this, you begin with the requirements model and elaborate analysis classes (for components that relate to the problem domain)

Explanation of Figure :

To illustrate this process of design elaboration, consider software to be built for a sophisticated print shop.
The overall objective of the software is to collect the customer’s requirements at the front counter, cost a print job, and then pass the job on to an automated production facility.
During requirements engineering, an analysis class called PrintJob was derived. The attributes and operations defined during analysis are noted at the top of Figure.
During architectural design, PrintJob is defined as a component within the software architecture and is represented using the shorthand UML notation shown in the middle right of the figure.
Note that PrintJob has two interfaces, computeJob, which provides job costing capability, and initiateJob, which passes the job along to the production facility. These are represented using the “lollipop” symbols shown to the left of the component box.
Component-level design begins at this point. The details of the component PrintJob must be elaborated to provide sufficient information to guide implementation. The original analysis class is elaborated to flesh out all attributes and operations required to implement the class as the component PrintJob.

In the context of traditional software engineering, a component is a functional element of a program that incorporates

Processing logic,
The internal data structures that are required to implement the processing logic,
An interface that enables the component to be invoked and data to be passed to it.

A traditional component, also called a module, resides within the software architecture and serves one of three important roles:

(1) A control component that coordinates the invocation of all other problem domain components,
(2) A problem domain component that implements a complete or partial function that is required by the customer,
(3) An infrastructure component that is responsible for functions that support the processing required in the problem domain.

Assume that the component is being designed from scratch or used an existing components for new development.
That is, you have to create a new component based on specifications derived from the requirements model.
There is, of course, another approach.
The software engineering community has emphasized the need to build systems that make use of existing software components or design patterns.
In essence, a catalog of proven design or code-level components is made available to you as design work proceeds.
As the software architecture is developed, you choose components or design patterns from the catalog and use them to populate the architecture.
Because these components have been created with reusability in mind, a complete description of their interface, the function(s) they perform, and the communication and collaboration they require are all available to you.