Component-Based Software Engineering: How to Eat the Software Elephant
In this post, Eric Zwirner, Senior Engineer at Tangram Flex, discusses the impacts of component based software engineering in our software-driven world. Eric has a rich background in software engineering for avionics systems and cross domain solutions and provides leadership and expertise in developing solutions for Tangram customers.
There’s a famous saying that claims there is only one way to eat an elephant: one bite at a time. Of course this saying isn’t really about eating an elephant, it’s about taking a task of seemingly insurmountable size and breaking it down into sub-tasks that can be reasonably accomplished. Today’s systems have become the proverbial elephant. Even the average car on the road has tens of millions of lines of code running on all of its onboard computer systems– just one example of how we encounter software in our day to day lives without realizing it. Software is everywhere and in everything now, and though it has been central in creating the advanced world in which we live, there are numerous examples of how a failure to comprehend all of its details has resulted in catastrophic consequences.
The complexity of modern software systems is also forcing the need for software reuse. Renowned Dutch computer scientist Edsger Dijkstra has said that the programmer “has to be able to think in terms of conceptual hierarchies that are much deeper than a single mind ever needed to face before.” As software has become increasingly layered and exponentially more complex over time, it is no longer realistic or even desirable to build most new systems from the ground up– in fact, the cost and time associated with such an effort is prohibitive. Software reuse is becoming more the rule than the exception.
It’s time to look at software development in a different light. Component-based software engineering (CBSE) is an approach to developing software in a way that promotes the separation of functional components, each of which can be developed, tested and maintained more effectively. The concept isn’t new and there are a number of variations associated with its implementation. The following discussion, though, considers a more strict definition of CBSE with greater emphasis on separation of components and well-defined interfaces connecting them. These concepts support a more robust software system that is better tested, more secure, more maintainable, and more interoperable as is required by our modern technology driven world.
One Bite at a Time: Understanding What You Have
Individual software components are easier to develop and understand than a complete system. This should be an obvious claim. Once the required components have been identified at the system level, it’s easier to develop them and it’s easier to understand how they work. Identification of components can be the result of good upfront system engineering or as part of a software archaeology activity conducted to better understand legacy code. The latter case can also lead to a refactored code base that better resembles a component-based paradigm. Regardless of how the code gets into well-defined components, the benefits can still be realized.
Testing is Easier and More Focused at the Component Level
Developing good software tests is not an easy task. In fact, it’s often very labor intensive. The larger the code base, the harder it is to develop test cases that provide reasonable coverage. Testing at the component level is far more manageable since the scope is reduced and the tests can be more focused. There are also more automated testing methods that can be easily applied at the component level but not to a complete system. Consider techniques such as fuzz testing where massive amounts of pseudo-random data are sent to the code trying to break it. Fuzzing is easily achievable at the component level but becomes increasingly difficult as code size grows. This is also true for symbolic execution, where the program is analyzed to find inputs that cause all parts of the code to execute. Symbolic execution often fails due to what’s called “path explosion” when too many paths are found, which is directly related to code size and becomes a much more useful testing method at the component level.
Effective software testing is critically important, and a variety of automated methods should be used together to help harden the code. When software is architected with better testing methods in mind, this is a realistic goal for all systems.
Well-Constrained Interfaces Promote Security
Components that are designed to use well-constrained interfaces are more secure. A well-constrained interface is one that accepts only specific kinds of inputs as required to perform the function of the component. Inputs that do not match expectations are rejected, reducing the attack surface since only limited, constrained inputs are permitted. The fewer permutations of inputs that are accepted by a component the lesser the chances of malicious data getting in and causing harm. CBSE introduces a layered approach to system safety in this way, providing component-level and system-level assurance that is nearly impossible to achieve otherwise.
Components Are More Maintainable
Software source code is read more often than it is written. With a component-based design, a programmer who has never worked on a given component has a much better chance of understanding it when maintenance is required. Using tools with Component Libraries like those provided in a Component Software Integration Platform (CSIP) aid in preserving and sharing information about the individual components and provide better control over their updates and changes.
Many safety or security critical applications will require accreditation testing prior to deployment. When changes need to be made, a component-based implementation makes the re-accreditation process easier since the accrediting authority can more readily assess code changes and their impact.
Component-Based Designs Promote Interoperability
If a software interface is developed to be compliant with a known specification, interoperability becomes likely and probably was the reason for that design choice to begin with. Imagine the number of times you have used a software product that uses the term “plugins.” This term is often applied to a software component that has been written to comply with a known interface that is made available for software components to be added for the purpose of enhancing the functionality of the main software product. This is just one example of component interoperability.
Components Support the Low Code/No Code Paradigm
Low code and no code environments are becoming more common today. With such systems, less software engineering is required to achieve a functional system. With a component based design, it’s possible for a system engineer or even a user to assemble the components and connect them using compatible interfaces to achieve a working system. Imagine a library of well-defined, well-tested components with understood interfaces. These can become building blocks to be swapped in and out as needed to achieve the end goal. This does not replace or eliminate the need for software engineers- rather, CBSE allows their efforts to be more directed to developing the parts that make up the system instead of assembling and connecting them together each time a system upgrade is required.
Setting the Table
There are many motivating reasons for adopting a CBSE development approach. Eating the proverbial “software elephant” one bite at a time helps us build flexible, more easily maintained systems with processes that software engineers can more effectively manage during development, testing and maintenance activities. The additional benefits of interoperability, reuse and enhanced security add to the value of CBSE. There are quantifiable benefits to embracing this approach, which are realized more fully when teams are properly equipped with tools like those in a CSIP that tie models to code, improve component management, and integrate component-level testing throughout the engineering lifecycle.
About Tangram Flex
Tangram Flex simplifies software integration for mission-critical defense systems. Every system is unique, but the mission is clear: the people on the ground need dependable, adaptable equipment to get the job done. At Tangram Flex, we understand the challenges of security, speed, and safety. Our team combines engineering expertise with our Component Software Integration Platform (CSIP), Tangram Pro™, to arm engineers with customized toolkits for meeting mission needs.
Tangram Flex is headquartered in Dayton, Ohio. Our staff has experience from DoD, Fortune 500 companies, and innovative software startups. We are dedicated to walking alongside our customers to keep pace with changes in technology. Get in touch: hello@tangramflex.com.
