Part 6: Component-Based Software Engineering — 15 Questions and Answers on Developing Business Architecture for the Future
1. Introduction
Component-Based Software Engineering (CBSE), sometimes also called Component-Based Development, is a relatively obscure topic that, in my 18+ years of experience in software development, I cannot recall having encountered in generic discussions of software development.
This obscurity of CBSE is intriguing since when you understand what it means, you will immediately recognize that it’s part and parcel of how we normally think about software architecture.
In this article, we will trace the origins of CBSE to its creator and the circumstances under which it was conceived. Next, we will examine CBSE in detail, using examples of modern software systems to illustrate its relevance to current software development projects. Finally, we will try to fit CBSE into our main framework for Operational Excellence.
The discussion has been structured as 15 questions and answers, which we hope will give the reader enough information about the topic to continue the research independently if required.
2. What Does This Series on Solution Design Cover?
This article on CBSE is one of several articles on solution design. You can access the rest of these articles using the links below:
3. Top 15 Questions and Answers on Component-Based Software Engineering
3.1 What is Component-Based Software Engineering?
Component-based development (CBD) is the creation and deployment of software-intensive systems assembled from components, as well as the development and harvesting of such components.
— Philippe Kruchten, Modeling Component Systems with the Unified Modeling Language
Component-based software engineering (CBSE), or component-based development (CBD), is a software engineering methodology that prioritizes composing software applications through integration over implementing these from scratch every time.
The philosophy of CBSE is as follows: if you want to build high-quality software at lower costs and higher qualities, systematic reuse of existing components must be your principal strategy.
CBSE relies on the availability of ready-made software components that allow the assembly of a large software system from loosely coupled, modular, reliable components. Central to CBSE is the concept of separation of concerns among the different subsystems of the software application.
3.2 How did Component-Based Software Engineering start?
3.2.1 The Software Crisis of the 1960s
Component-based software engineering (CBSE) was first introduced as a topic of discussion during the height of the software crisis.
The “software crisis” of the mid-1960s was a period during which the field of software development faced significant challenges and difficulties in managing the growing complexity of software systems. This term gained prominence as the demand for software increased, and developers struggled to cope with the scale and intricacy of creating and maintaining large software applications.
Several factors contributed to the software crisis:
3.2.2 Mass-Produced Software Components
To address these challenges, the software engineering discipline emerged, focusing on systematic approaches to software development. This led to the development of methodologies, such as the Waterfall model, and the establishment of principles like modularity, encapsulation, and abstraction. Over time, these efforts helped mitigate the software crisis and laid the foundation for modern software engineering practices.
One conference in particular set out to counter the so-called software crisis and was hosted by NATO in the Bavarian town of Garmisch in 1968. During this conference, Douglas McIlroy presented his approach to solving some aspects of the software crisis in an address titled Mass Produced Software Components.
Brad Cox of Stepstone subsequently redefined the concepts of software components to fit a more modern view. Afterwards, IBM led the path with their System Object Model (SOM) in the early 1990s. Some claim that Microsoft paved the way for deploying component software with OLE and COM. As of 2010, many successful software component models exist.
3.3 What are the building blocks of Component-Based Architecture?
In Component-Based Software Engineering (CBSE), the below vocabulary is often used when discussing system architecture and design:
We have attempted to modernize the language in which application design and architecture are discussed by introducing the Multi-Layer, Multi-Perspective Paradigm (M2LP), a set of concepts that provide more flexibility than the raw ones we saw above. We invite the interested reader to look at those ideas for further information.
3.4 Can you give an example of Component-Based Software Engineering?
3.4.1 Software Components and Java Beans
A common example of a software component is a Java Bean. JavaBeans are reusable software components for Java that follow specific coding conventions. They are used to encapsulate many objects into a single object, known as a bean. JavaBeans aims to promote the development of modular, reusable code.
Here are some key characteristics and conventions associated with JavaBeans:
3.4.2 Example of a Java Bean
Let’s consider a simple example of a Java Bean representing a “Person” with name, age, and email properties. This example will illustrate how JavaBeans adhere to certain conventions for creating reusable components:
import java.io.Serializable;
public class Person implements Serializable {
// Properties
private String name;
private int age;
private String email;
private PropertyChangeSupport mPcs = new PropertyChangeSupport(this);
// Default Constructor (no-argument constructor)
public Person() {}
// Getter and Setter methods for the 'name' property
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
// Getter and Setter methods for the 'age' property
public int getAge() {
return age;
}
public void setAge(int age) {
int oldAge = age;
this.age = age;
mPcs.firePropertyChange("age", oldAge, age);
}
// Getter and Setter methods for the 'email' property
public String getEmail() {
return email;
}
public void setEmail(String email) {
this.email = email;
}
public void addPropertyChangeListener(PropertyChangeListener listener) {
mPcs.addPropertyChangeListener(listener);
}
public void removePropertyChangeListener(PropertyChangeListener listener) {
mPcs.removePropertyChangeListener(listener);
}
}
In this example, the following Java Bean rules are observed:
JavaBeans are ordinary Java classes that follow specific rules to enhance reusability, introspection, and compatibility with tools and frameworks. This makes them ideal for building modular and reusable components in various application domains.
3.5 What is a Software Component?
3.5.1 The Original Definition of Software Component
The quote below is from the NATO Software Engineering conference we mentioned earlier, specifically from M. D. McIlroy’s address, in which he states that the idea of modularity and subsystems in software engineering was already common and well-established. However, he believed software houses producing standard parts and catalogues of such items were missing.
The idea of subassemblies carries over directly and is well exploited. The idea of interchangeable parts corresponds roughly to our term ‘modularity’ and is fitfully respected. There are no manufacturers of standard parts, much less catalogues of standard parts.
— M.D. MCILROY, NATO SOFTWARE ENGINEERING CONFERENCE 1968
McIlroy’s ideas referred to software components as understood and seen fit for a software industry that just took off. Things look very different today, and a revised concept of software components is required. This is exactly what we will try to do in the next paragraphs. So, what is a software component in modern software engineering? Here are some thoughts:
From P. Kruchten’s paper on the topic: A software component is a nontrivial, loosely coupled, semi-independent, and replaceable part of a system, fulfilling a clear function in the context of a well-defined architecture.
Again, from P. Kruchten’s paper: A software component conforms to and provides the physical realization of a set of interfaces. This is not the same as a class in object-oriented programming; a software component can be a group of classes working together. This level of complexity is what makes it non-trivial.
A software component can also be a dynamic bindable package of one or more programs managed as a unit and accessed through documented interfaces that can be discovered in runtime.
3.5.2 Characteristics of Software Components
Kruchten goes to some length in defining the characteristics of his envisaged software components. They look something like this:
Kruchten also had to refer to abstraction levels and architectural contexts in his definition, both of which merit some exploration:
3.6 What is the objective of Component-Based Software Engineering?
The quote below is from the NATO conference convened in 1968 to address the software crisis of those times and belongs to M. D. McIlroy, whom we introduced earlier and where he defines the intended objective of Component-Based Software Engineering.
‘Mass production’ of software means a multiplicity of what the manufacturing industry would call ‘models’ or ‘sizes’ rather than a multiplicity of replicates of each.
— M.D. MCILROY, NATO SOFTWARE ENGINEERING CONFERENCE 1968
McIlroy’s idea for CBSE was to mass-produce reusable components. However, mass production in software radically differs from manufacturing, as he attempts to explain.
In manufacturing, a model allows an assembly line to mass-produce replicas, spare parts identical in every shape or form. In software engineering, particularly CBSE, mass production refers to creating a family of routines based on an original model.
To illustrate this idea, McIlroy describes a family of routines, theoretically derived from one parent routine, which can calculate the value of a sine function, such as sin(pi/3), with varying speeds, precisions, and robustness. While these concepts were relevant in the 1960s, they have been radically updated to mean something else.
Component-Based Software Engineering (CBSE) aims to lower the implementation costs of software-intensive systems while simultaneously increasing quality and reducing implementation timelines.
CBSE encourages the design and development of reusable code, which reduces the overhead associated with the design, documentation, and development of new components, subsystems, and systems. It also assumes that with every reuse, the component’s quality is refined by discovering and eliminating bugs.
3.7 Does Component-Based Development apply to Business Architecture?
3.7.1 CBSE Extended to Platforms and Software Solutions
Component-Based System Engineering (CBSE) and Development (CBD) have allowed software businesses to build on earlier successes and maximize their investments by systematically reusing software components.
The concepts of CBSE have been extended to cover entire platforms whereby software firms acquire those platforms through mergers and acquisitions (M&A) to replace their aging ones or enhance them with new capabilities.
When organisations acquire smaller software companies, they also inherit their tech stack and all the development and operations resources looking after it. Product managers and architects then step in to identify the software platforms in the newly acquired stack that would enhance the company’s value proposition and discard the rest. Qualified platforms will then take the place of legacy ones. These activities occur as part of the integration process between the two companies.
3.7.2 CBSE and Business Architecture
Like how CBSE works (see below discussion on CBSE Process) for software components, with engineers designing reusable components and architects composing and integrating components rather than requesting new ones, business architects apply the same methods to large software platforms.
The business architecture of the old and new companies, now merged into one, has evolved to enhance its position in the market with newer and more capable technology and products.
3.8 What does a Component Lifecycle consist of?
3.8.1 Software Component Lifecycle
In the original discussions on how software components can be managed and what their lifecycles consisted of, the authors identified three stages:
3.8.2 Platform Lifecycle
As mentioned earlier, the modern view of a component covers anything from runtime classes to entire platforms, depending on our chosen abstraction level. Does this change of scale have any impact on a component’s lifecycle? The answer is yes; the details will differ while the main concepts remain unaltered. Let’s see how.
Imagine you have a legacy system that uses very old technology or has become too expensive to maintain. Here also, you have three options:
3.9 How is Component-Based Development different from the SDLC?
The Software Development Lifecycle (SDLC) consists of sequential stages that start with a business requirement and end with a finished product. Within the SDLC, multiple processes can operate, and the methodology that governs these processes can be guided either by Agile or Waterfall principles.
One of those processes can be Component-Based Development (CBD), while the other is the more familiar feature development process. The component can be a JavaBean or a platform (see question 8 on Component Lifecycle).
The Component-Based Development process can be described as follows:
3.10 What frameworks can be used to describe Software Components in CBSE?
One of the most common models for representing architectural concepts in software engineering is the C4 model. Created by Simon Brown, the C4 model is a framework for visualizing the architecture of a software system.
The “C4″ stands for Context, Containers, Components, and Code,” representing different levels of abstraction in the system.
However, the C4 model has its drawbacks. While it may work perfectly fine for relatively simple systems, it can be easily overwhelmed with large and more complex ones, as we have aimed to describe in Software Application Design — Part 1: A Multi-Layer, Multi-Perspective Paradigm for Thinking about Applications.
The Multi-Layer, Multi-Perspective Paradigm or M2LP adds a layer of abstraction that differentiates between the views of development, operations, product management, architecture and any other aspect of the system’s design or functionality. This is necessary as modern applications have become so complex that it is almost impossible to represent every facet of their design in one diagram at a predefined level of abstraction.
M2LP also replaces the three tiers represented by Container, Component, and Code with a more flexible approach based on two distinct abstraction levels, Blocks and Components, where these can be freely defined by the designer depending on the story they wish to tell.
3.11 What is “Separation of Concerns” in software design?
Separation of concerns is the philosophy behind modularization in software design. Modularization of a system works by dividing it into loosely coupled and semi-independent components, each responsible for a specific area of functionality.
This architectural concept aims to enhance maintainability, scalability, and flexibility by isolating different concerns within the system.
3.11.1 History
Let me try to explain to you what, to my taste, is characteristic of all intelligent thinking. It is that one is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency […]. We know that a program must be correct, and we can study it from that viewpoint only; we also know that it should be efficient, and we can study its efficiency on another day, so to speak. […] But nothing is gained —on the contrary!— by tackling these various aspects simultaneously. It is what I sometimes have called “the separation of concerns”, which, even if not perfectly possible, is yet the only available technique for effective ordering of one’s thoughts that I know of.
— On the Role of Scientific Thought, Edsger W. Dijkstra
The concept of separation of concerns can be traced back to the 1970s, and it gained prominence in the field of software engineering. The term was popularized by Edsger W. Dijkstra, a renowned Dutch computer scientist, in his 1974 paper “On the Role of Scientific Thought.” Dijkstra advocated for separating concerns as a means to simplify complex software systems and improve their comprehensibility.
3.11.2 Definition
Separation of concerns involves organizing code and design so that each module or component addresses a specific aspect of the overall functionality. Ideally, these concerns should not overlap.
Separation of concerns and modularisation promote a clean and modular structure where changes to one concern do not impact others, facilitating easier maintenance and modifications. Components in such a design connect through well-specified interfaces, where components can be swapped with other components as long as they implement the same interface.
Modularisation requires that interfaces be fixed, while implementations can vary. This allows designers to have one component communicating with multiple heterogeneous and distinct components without worrying too much about their specific implementation.
3.11.3 Example
A classic (and partially antiquated) example illustrating the separation of concerns is the Model-View-Controller (MVC) architectural pattern. In MVC, data management, user interface, and application logic are separated into these three distinct components.
However, even at the level of Data alone, User Interface, or Business Logic, the view has become so complex that it merits further “separation of concerns”, something that we aimed to achieve in an upcoming series of articles, the first of which is Software Application Design — Part 1: A Multi-Layer, Multi-Perspective Paradigm for Thinking about Applications.
3.12 What are the top advantages of Component-Based Software Engineering?
3.12.1 Is CBSE Relevant Today?
We don’t hear many commentators today discussing component-based software engineering (CBSE), and that is because, in my view, it has become a concept that we take for granted.
Every smartphone, tablet, or personal computer is an improvement over its predecessor. Android systems run the same Android software, Apple systems run iOS, and personal computers run MS Windows. Things were very different in the 1960s and 1970s; hardware and software were created in close collaboration, and interoperability was not a thing. Back then, CBSE represented an intellectual leap into new territories.
Is CBSE still relevant today? The answer is Yes. When building modern software applications or software systems, reminding ourselves of the advantages of CBSE is beneficial as it helps us understand the theory behind our taken-for-granted assumptions.
3.12.2 Advantages of Applying CBSE
CBSE offers several distinct advantages rooted in fundamental principles of efficiency, integration, interoperability, design maturity, rapid development, and sustained quality improvement. Let’s articulate these ideas fully:
In conclusion, Component-Based Software Engineering stands as a paradigm that offers tangible advantages across multiple dimensions of software development. Its principles, grounded in efficiency, integration, interoperability, design maturity, rapid development, and sustained quality improvement, position it as a compelling approach for contemporary software engineering endeavours.
3.13 How does Component-Based Software Engineering help us deliver faster?
I once attended a meeting where our salespeople discussed a solution integration project proposal with our client. The client’s senior manager was adamant about the project schedule not exceeding a calendar year. To me, this limitation sounded arbitrary and unreasonable.
This twelve-month limitation turned out to be more psychological than anything else. Still, it was deep-rooted and ancient (in relative terms), as the following quote from NATO’s 1968 software engineering conference shows.
Experience… has led some people to have the opinion that any software systems that cannot be completed by some four or five people within a year can never be completed; that is, reach a satisfactory steady-state. […] Define a subset of the system that is small enough to bring to an operational state within the ‘law’ mentioned above, then build on that subsystem. This strategy requires that the system be designed in modules that can be realized, tested, and modified independently, apart from conventions for inter-module communication.
— E.E. DAVID, NATO SOFTWARE ENGINEERING CONFERENCE 1968
So, how can we build arbitrarily large software systems in less than twelve months? It turns out that the magic recipe has two essential ingredients:
3.14 What role does standardisation play in the success of Component-Based Software Engineering?
The standardization of interfaces, APIs, design, and architectural patterns plays a pivotal role in the success of Component-Based Software Engineering (CBSE).
CBSE emphasizes creating and assembling software components, which are modular, reusable code units. The effectiveness of CBSE relies on several factors, and standardization is a key enabler for achieving efficiency, interoperability, and maintainability in software systems. Below are the specific contributions of standardization to the success of CBSE:
3.15 How does Component-Based Software Engineering help achieve Operational Excellence?
If we define Operational Excellence as “an organisation’s ability to continuously modify its course to implement its management’s vision with minimal effort and impact on the quality of its products“, how would Component-Based Software Engineering help such organisations achieve Operational Excellence?
Component-Based Software Engineering (CBSE) can significantly contribute to achieving Operational Excellence within organizations because of its inherent qualities that align with the principles of Operational Excellence.
The following points elaborate on how CBSE supports this organizational objective:
4. References
- Report on a conference sponsored by the NATO SCIENCE COMMITTEE, Garmisch, Germany, 7th to 11th October 1968
- On the Role of Scientific Thought, by Edsger Dijkstra
- Modeling Component Systems with the Unified Modeling Language, by Philippe Kruchten
- Component-Based Development, Application in Software Engineering, by Debayan Bose