Last decade’s all-pervasive software engineering panacea was object-orientation. More renowned for the abuse of it rather than its real use. It is part of the growing pain, when one undergoes growths of such fantastic proportions. Software Engineering had the precocious desire to grow up much like its other engineering cousins and hence was perpetually stuck to this notion, the whole of last decade, reusability.

It suddenly seems to have realized what Billy Joel sung in ‘Vienna’ and discarded its infantile ambition of assembling an application just from pre-packaged reusable components a.k.a. the Lego metaphor.

Software development is definitely an endeavor that is not trivial enough to be built from simple components, like Lego blocks. So, Software Engineering got real and pushed reusability to the backseat, when compared to the more urgent need of the hour, the need to cope up with change.

This is the foundation of all component-based development, i.e., the ability to manage change seamlessly and efficiently and would become apparent as we move forward.

This is a very important question that we need to get a good handle on. How are components different from objects? Are they one and the same? When object-orientation came in, there were lots of tips to implement some of the object-oriented features in a procedural programming language such as C. We could go through the gory details of the subtleties between object-oriented and component-based development and miss the forest for the trees.

In a similar light, component technology should be regarded as evolutionary rather than revolutionary. Let us construct some simple axioms about object technology: Objects are thingies that hold both data and methods and neatly segregates interface from implementation. Component Technology rides on these few simple axioms and builds a framework for managing change with the incidental reusability gain. We would soon see how.

There is a distinction between the notions of an interface and implementation right from the good old OO days. In fact, right from the procedural programming days. You would recall the C programming language has the notion of the header and implementation files. Anyone who wishes to use a library, would consult the header file, to find out, the functionalities offered, the parameters that need to be passed and the values that would be returned on execution of the functionality. Component Technology strengthens this notion of the separation of interface from implementation, and builds a new web of concepts around it.

According to the Component Technology Parlance, an Interface could be regarded not a mere declaration provided by a component, but as a contract, that it will oblige, provided, the pre-conditions are met with. Such a discipline was enforced in an early OO language, called Eiffel, by way of assertions. Eiffel’s Creator Dr.Bertrand Meyers had great foresight in including such a feature. Oh! so, is it all new wine in an old bottle? Wait a minute. Don’t jump the gun just yet!

The divide-and-conquer strategy has been employed effectively at various stages of progress in software engineering; modules and functions in the procedural programming practice; objects in the OO world. Component Technology fine-tunes this strategy further to facilitate change management effectively. Thus we have five salient characteristics of a component-based development, the first and foremost being architecture.

Constructing Software is more complex than constructing from Lego blocks. Complex components depend on other components providing specific functionality. In to order to facilitate reusability of components, the context of use must be well understood. This is determined by software architecture. Quoting Desmond D’Souza of the Catalysis Approach, Architecture can be regarded as a set of principles and decisions, rules or patterns about any system that keeps its designers from exercising needless creativity. So, once the business domain is understood by detailed analysis and business modeling, we move to the solution space of identifying the patterns that are relevant to the context, in consideration. 

There are innumerous Patterns Catalogs, including the recent J2EE Design Patterns Catalog by JavaSoft, to fit a pattern for our endeavor. Hence, component-based reuse is possible only as a consequence of architecture-based reuse.

Once the landscape of the solution space is sketched, we move on to the design of the interface to the components that collaborate to provide the solution. Recalling, what we mentioned earlier, we employ the principle of design by contract and the three key principles on which it is based, viz., invariant, pre-conditions and post-conditions. Using a non-software trivial example of the notion of contract. Let us assume that, we want to travel by air from Boston to Miami. The Pre-Condition would be that, the customer would be at the gate at least 15 minutes before departure, with only allowable baggage and with a valid ticket for the journey. The Post-Condition would be that, the customer would be in Miami on the same day. The Invariant would be that the customer would reach Miami with a reasonable delay, or else the money for the ticket would be refunded.

Once the important task of interface design is completed, we set out to design the Component. We employ the three principles of Precision, Pluggability and Abstraction for our component design.

All it means is that, the Components should all be at the same level of abstraction and should be designed precisely and should be designed so that it is pluggable enough with other Components. The emergence of the Object Constraint Language (OCL), which is part of the Unified Modeling Language (UML), would facilitate such a precise and structured way of modeling and specifying components.

J2EE, CORBA, COM+ and other Component Technology enablers provide a framework for managing different versions of a component and a whole array of services to facilitate development and deployment of component-based development.

This is very essential because, interface is a promise for realizing business functionality. As business changes, there is a need for a new interface to cope up with this change. Also, the realization of an interface, which is a component, can change as well. So, there is a need for multiple versions of interfaces and components and hence the component technology enabler would and should support such versions effectively.

It should also be noted that, a component could collaborate with other components, which can be in the same machine or a remote machine as well. Procedural Programming Paradigm had the ability to call procedure calls from other machines, which was called Remote Procedure Calls (RPC). Component Technology relies on this remote method calling and implements some form of RPC to facilitate method invocation from components regardless of its residing machine.

The Lego metaphor is applicable only for trivial Lego blocks and not for complex software development. Component Technology is an evolutionary technology and has its foundation on three basic elements, viz.,

1. Object Technology that regards the attributes and methods as a composite whole.
2. Segregation between interface and implementation in a software system.
3. The notion of versioning facilitates and manages change in a software system effectively, which has now become the foundation for component-based software systems. The notion of reusability thus should be regarded as an incidental gain.

During difficult times, I avoid the trapped feeling by trying new things in the hopes it will be fun and profitable. Many of you are experienced and capable, but don’t know how to prove or demonstrate your skills when not working. May I suggest that writing about your experience, and coding tricks and techniques might be a way of doing this and promoting yourself at the same time. We are looking for experienced programmers and system designers who would like to write.

To get an idea of what appeals to our readers and the formats that we use, take a look at our past issues online (at www.accu-usa.org/DownloadNLL.html).

While we are on the topic of writing, is there anything that you would like to see in ACCent? We are geared for you, the programmer and system designer. We also try to bridge the gap between being a national magazine/e-zine and being very local. We are a non-threatening way of beginning your writing career.

Buy now, all of you must have used a search engine. Some of you have used engines that dump millions of hits on you, most of them duplicates of each other. There are also the search engines that give you results without letting you know that they have paid for the positioning. Other search engines are much better and more honest.. For example, I use Google extensively. However, none of the search engines that I know of have good semantics when it comes to searches. For example, I wanted a list of all the members of the House of Representatives with their party affiliations and email addresses, suitable for use as a email list.. It must exist somewhere out there, but I could not find it. Worse, the number of false positives made it difficult to research. Keywords alone did not seem to cut it. Let us know if you have found a better search engine?

Book Reviews

Extreme Programming Applied by Ken Auer & Roy Miller, Addison-Wesley, ISBN 0-201-61640-8

Recommendation: I enjoyed reading it.

Having spent an interesting evening with our discussions about eXtreme Programming (Extreme Programming Roundtable, ACCU meeting December 2001), I thought it would be natural to review one of the many books from A-W's "XP Series". So I choose the XP Applied title, since I had not read that one yet, and it also seemed similar to our talk's topic.

But I also have to admit this choice was a bit random. I never know what to expect when I read one of the many book titles from this series: XP Explained, Applied, Examined, Explored, Installed, in Practice, this sounds just too similar for my brain.

My first question was if it is only another nice-looking book (I love their layout), or if there is also some valuable information in it. So instead of reading it from the first page to the last, I started jumping from one chapter to another, and without any problems I found a lot of interesting pieces of information, just the right stuff for somebody who wants to give XP a try.

I also tried to get answers to some questions I had about XP (e.g. does it encourage or prevent written documentation), and I always found enough pointers in the index to interesting answers and examples (e.g. the tendency is to avoid *unnecessary* documentation; some people use Wiki for documentation purposes).

One of the characteristics of this book is that it has zillions of so-called pioneer stories, that is insertions or side-bars with separate stories, many of them from different authors (and always clearly separated from the main text by a different background color).

I liked these a lot since they supported my jumping around in the book, you have some nice distractions on almost every other page. If you prefer reading a book from front to back, this might be a disadvantage, though.

I think XP Applied is not the best book if you have never read about XP before, it's not exactly an introduction to XP, but it's more tons of experiences, motivations, examples of what others did and how they survived or even used XP to finish projects.

— Lutz Birkhahn

I have often been asked about the popularity of a given language. The most often mentioned languages are C/C++ and Java. Figure #1 shows the ratio of total job openings in Silicon Valley by language over the last 34 months. At best, Java demand stood at 85% of the demand for C/C++. Now it is running at about 35% of C/C++ job openings.