Software Components

Introduction

This is the 12th article in the System Design and Software Architecture series. In this article, we are discussing Software Components.

What is a Software Component?

A component is a well-defined set of modular, portable, replaceable, and reusable functionalities.

A component is a software object that is intended to interact with other components, integrating a certain function or group of functions. It has a clearly defined interface and conforms to a generally recommended behavior for all components in the architecture.

A software component can be defined as a unit of composition with a specified interface and clear context dependencies. It can be deployed independently and is subject to third-party composition.

Characteristics of Components

• Reusability: Components are generally designed to be used again in different applications at different times. However, some components are designed for a specific purpose.
• Replaceable: Components can be freely replaced with other similar components.
• Context-Independent: Components are designed to function in different environments and contexts.
• Expandable: A component can be extended from existing components to provide new behaviors.
• Encapsulated: The component interface allows the caller to use its functionality without revealing information about internal processes or internal variables or status.
• Independent: Components are designed with minimal dependence on other components.

Views of a Component

A component can have three different views—object-oriented view, traditional view, and process-related view.

Object-Oriented View

• A component is considered as one or more cooperating classes. Each problem domain class and infrastructure class is explained to identify all the properties and operations relevant to its implementation. It also includes defining interfaces where classes can communicate and collaborate.

Traditional View

• It is considered a module of a program that integrates a functional element or processing logic. It must provide an interface and data that allows it to appeal to the internal data structures and components needed to execute the processing logic.

Process-Related View

• According to this view, instead of creating individual components from scratch, the system is built from existing components maintained in a library. As software architecture is developed, components from the library are selected and used to populate the architecture.
• The User Interface (UI) component includes buttons, called Grids and Controls, while the Utility component exposes a specific set of functions used in other components.
• Other common components are resource-intensive, frequently inaccessible, and must be activated using Just-In-Time (JIT) access.
• Many components are distributed in Internet web applications such as Enterprise Business Applications, Enterprise Java Beans (EJB), .NET components, and CORBA components are invisible.

Conducting Component-Level Design

• Identify all design classes that correspond to the problem domain as defined in the analytics model and the architectural model.
• Identify all design classes that correspond to the infrastructure domain.
• Describe all design classes that have not been acquired as reusable components and specify message descriptions.
• Identify the appropriate interfaces for each component and describe the data types and data structures needed to implement them.
• Duplicate codes or UML activity diagrams describe the processing flow in detail in each operation.
• Describe continuous data sources (databases and files) and identify the classes needed to manage them.
• Develop and expand behavioral representations for a class or element. This can be done by expanding the UML state diagrams designed for the analytics model and examining all use cases relevant to the design class.
• Expand deployment diagrams to provide additional implementation details.
• Indicate the location of keystrokes or components in a system by using class opportunities and naming specific hardware and operating system environments.
• The final decision can be made using established design principles and guidelines. Well-experienced designers consider all (or most) of the alternative design solutions before settling on the final design model.

Advantages

• Ease of Deployment: When new compatible versions become available, it is easy to replace existing versions with other components or the system as a whole without any impact.
• Reduced Cost: This allows you to spread development and maintenance costs by using third-party components.
• Ease of Development: Enables component public interfaces to provide defined functionality, allowing development without affecting other parts of the system