May 24, 2004

Is Component-Based Software Engineering The Future?

While Henry Ford did not invent the automobile, the moving assembly line is generally attributed to Henry Ford, but he did not invent this process. As Automotive History discusses, Henry Ford devoted many years to making more and better cars in a shorter period of time that would be affordable by everyone.

Prior to implementing this great degree of efficiency and production cost savings, wagon builders built cars, and cars were built a few at a time. When a piece did not quite fit, the builder would take the time to make it fit, and this made the assembly of an automobile a slow, tedious, and error prone process.

In 1914, Henry Ford opened the first assembly line, but he saw problems in building parts. He then visited Arthur O. Smith, who was producing 12 pressed steel frames a day for Peerless Motor Company. Henry Ford challenged Arthur Smith by ordering 10,000 frames, which would have to be delivered within four months, and by 1921, A. O. Smith Corporation was capable of producing that number in a day.

Computers have transitioned from using a single vacuum tube and transistors in the 1950's to having integrated circuits in 1975, each with dozens to hundreds of transistors combined into one. Hardware engineers combine these individually tested circuits and assemble them together to make new functionality. Because these circuits are mass produced and individually tested, this increases the reliability and productivity of the circuits.

The above discussions are very typical introductions to Component-Based Software Engineering (CBSE). A recent assignment asked me to do look into CBSE as the wave of the future.

At first, I thought this assignment was going to be easy. That is, at least, until I started googling over the topic. Although a lot of material came up, a good portion of it were web sites that once talked about it, but no longer do, such as The Component-Based Development Headquarters. Usually fairly good in providing links to object-oriented material, I was surprised at how the Centus Links section had so many 404's itself. ACM's Digital Library had many links, but I could not find anything of an introduction to CBSE, except for Towards Component-Based Software Engineering.

A book that has been on my wish list for quite sometime was Component-Based Software Engineering, and I decided to purchase it for this very reason, and I am amazed at how some of my ideas expressed in The Need for Software Design and A Comment on Comments dovetail so nicely with it. Although the book states that it is web-enhanced, the web site is unfortunately rather idle.

The foreword to this book is written by Ivar Jacobson, author of Object Oriented Software Engineering and a major contributor to UML, and he starts the book off by stating that components are not a new idea. Several decades ago, users had to create their own operating systems, because there was nothing available, and if they did not want to program in a machine language, they had to create their own high-level language to do so, again, because there was nothing available.

Today, things are different. It is rare you see a software company create everything from an operating system all the way up to end-user applications, since there are many operating systems available for common hardware, and in the few cases there are, they are highly specialized systems. In general, we also do not need to develop programming languages, since you have languages like C, C++, Java, and many more available on most systems, and again, those organizations that do develop their own languages are creating specialized languages.

For these reasons, Ivar Jacobson believes that we can now produce higher quality software with less effort in less time. And I think he is right. Thanks to the C++ Standard Library, STL, and a variety of other libraries, I can save valuable development time by reusing instead of reinventing. As an example, I no longer have to write a linked-list, and risk common errors and code duplication, because the STL provides a component for me to easy make lists. In the cases that I do not use the STL, there are very specific and specialized reasons of why.

But CBSE is a lot more than just software reuse. It instills a methodology to build stable components that deal with errors without crashing or corrupting data. The crashing and corruption problem, the authors continue, is based on the current states of affair in Software Engineering.

Although we would like to continue thinking of software engineering as derived from an engineering discipline, engineering disciplines require theory that guides practice, standards exist and are regulated, and reusable components exist. Software engineering does not have these characteristics. Because of this, in many cases, software engineers will make decisions that are quasi-scientific and pseudo-engineering, and this trend will continue as computer science graduates do not have a grounding engineering sciences, which include planning, designing, development, testing, integration, and maintenance of complex systems.

The crashing and corruption problem is caused by lack of regulations and standards to guide software development. Because of this, users have unfortunately gotten accustomed to rebooting, crashes, and losing data and time. As software engineers, we must create stable and reliable applications period, regardless of what else you believe in and think. In this regard, it takes some planning and experience to write stable applications.

As I cannot say it better myself, I shall quote the book: "For too long a so-called engineering discipline has not trained its practitioners in engineering practices, not subjected its students to internships and then tested their knowledge and expertise, and not prevented untrained and undisciplined employees from taking jobs of authority. Meanwhile, project managers are not engineering-trained software engineers or managers with full knowledge of the complete life cycle. ... Project managers must know the intricacies of design, development, testing, and component management..."

CBSE focuses on providing components with well-designed, well-documented, standardized interfaces with preconditions and postconditions, and well-documented use cases and interactions. The key words here are standard and documented interfaces. This allows multiple vendors to create components that provide the same service, but for different needs, licensing, or what have you.

If you think about components, I would actually find it rather hard to believe that you have never used a Standard component. For example, XML has the SAX and DOM API's, which are implemented by a variety of vendors, on a variety of platforms. If you are going to write a DOM-based XML processor, you have your choice of programming languages and libraries, however, which ever library you pick, the DOM interface to that library will be exactly the same no matter which language you utilize. Another example is JDBC, where the API again is the same no matter which underlying database is utilized. In this latter case, the driver implementation is a component that dynamically plugs into the JDBC. And for C++ developers, there is the STL.

On the other hand, we must be careful what we define as an component. In some of my earlier entries, I was a little lose on what I called a component and what I called a library. For example, earlier I called ACEtm a component, but in reality, it is a library. The ACE toolkit does not abide to a standard interface, where another vendor could implement this interface in a compatible fashion with ACE. On the other hand, TAOtm (a CORBA implementation based on ACE) is a component, since it abides to the CORBA standard, as defined by the OMG. As such, TAO should be replaceable by another CORBA implementation, such as MICO, quite easily.

This is not, however, to say that ACE cannot become a component. Should an interface be standardized, classes could be implemented in terms of the ACE toolkit, should the ACE functionality meet the standardized interface.

The OMG is interesting in the sense that for CORBA, they produced an interface without an implementation. A number of vendors have now taken the interface specification and implemented it, and because of this, we now have the choice of CORBA vendors, which are interoperate together.

Unfortunately, some corporate culture dictates that you cannot use components that were not developed in house. There are some valid reasons for this, such as licensing constraints, coupling, etc., however, in order to develop a component in house, you need the expertise to design, develop, test, and maintain this component. In some cases, you must create the component in-house, such as to optimize for certain performance characteristics, to provide an interface to some specific hardware or software, or because the component required does not yet exist. However, Frederick Brook's classic The Mythical Man-Month reminds us to buy before we build, and to reuse before we buy.

It is important to realize the CBSE does not mean building a new application completely with COTS components. It is important to break the application that you are building into pieces, and then see what components are available to help you solve those pieces. Even if you find some components, it is important to quantify these components against the requirements for the application that you are building. In choosing components, the book really highlights that decisions cannot be made in isolation, and the choice is based on professional assessment, best practices, experience with the component, whether it meets the design goals, and budget and staffing constraints.

Whether CBSE will be more of an an engineering discipline than Software Engineering will take some time and experience with it, and a shift in the way Software Engineers are trained. Either way, when given the choice to reuse tested and well documented components that meets my requirements or rolling my own, I will being using a component. And as Christopher Alexander (credited for inspiring the software patterns movement) says in The Timeless Way of Building, "If it has the power to make a single building live, it can be used a thousand times, to make a thousand buildings live."

Filed In