Sterling's Heart Is in the Right Place

Software Magazine, Oct, 1998 by Dan Kara

Component-based development is the future of development, and modeling is the key to CBD.

In my August column I stated that generative modelers (modeling tools capable of generating applications) provide better support than visual 3GLs for building medium to large-scale business systems accessing multiple databases using component-based development (CBD) technologies and techniques. These are the systems on which you run your business as opposed to, say, those that simply report on your business.

Most development managers understand that some form of analysis and design before the fact is required to build complex systems. Vendors understand this as well and that is why most development tools now have some type of modeling tie-in. However, not all forms of modeling support are created or engineered equally. The products should support component development techniques and technologies, but this support, while necessary, is often not sufficient. For example, while generating component interfaces from models is unquestionably useful functionality, in many UML-based (Unified Modeling Language) toolsets this process can be somewhat unwieldy. While modeling should be the basis of component design, the process should not be the analysis and design equivalent of eating lima beans -- good for you, but a little difficult to swallow. Component modeling tools must be usable, as well as useful.

Then there are the cases where functionality in component modelers is lacking altogether. For example, reengineering existing code, generating or interoperating with components in RPG and Cobol, as well as Java and C , or bringing component development to the mainframe. Also, what about generating business objects (as components) from business process models or offering collections of prebuilt, large-grained business objects and their accompanying specifications?

One would be hard-pressed to find a single toolset that supports all of the functionality described above. However, one vendor, Sterling Software, has spent a great deal of intellectual and financial capital, to say nothing of years of work, developing a suite of products that supports the functionality described above. But before we delve into the particulars of the product line, it is important to understand the real reason why large-scale component development efforts must begin with modeling. Without some type of modeling or specifications capture, most component development approaches do not support reuse!

Modeling Fosters Reuse

According to vendors, analysts, and developers alike, "reuse" is the primary advantage to a component development approach. But does component development really facilitate reuse? For the bulk of component development implementations, where components are limited to small, encapsulated software objects such as proprietary 4GL "objects," ActiveX controls, or Java Beans tied together with a scripting language or a 3GL, reuse is limited.

The majority of the component development solutions available today really focus on use first, with reuse an afterthought. Frankly, most software components on the market today were designed to be used as is, not reused. I refer to this as "runtime" reuse. For example, you drop an encapsulated software object such as a Java Bean or ActiveX control from a palette of other components onto the screen painter of a development tool. The tool allows some component properties to be set, but gross functionality can be changed but little.

Generalized, highly adaptable specifications or models offer more in the way of "reuse" (and therefore are more beneficial in the long run) than encapsulated software objects. Moreover, the concept of construction-time reuse is not limited to ActiveX controls, Java Beans, Enterprise JavaBeans, or other object-oriented languages, but can be utilized with any development environment and languages (including Cobol). I refer to the reuse of system specifications as "design time reuse."

The duality between runtime and design-time reuse must be understood if the industry is to move beyond the limited support for reuse provided by encapsulated software objects, and into an era where software assemblies of increasing complexity are built with collections of reusable and well-documented subcomponents. When modeling is used as the basis for component development efforts, software is constructed more like manufactured objects, yet still takes advantage of the flexibility and plasticity that is a hallmark of software.

Thinking Deeply About CBD

Sterling Software is one of a handful of vendors who understand the difference between runtime and design-time reuse, and is bringing this message to the wider IT marketplace through its thought and product leadership. Sterling began its support for CBD in earnest in April 1997 with its purchase of Texas Instruments (TI) Software and its flagship Composer product (now renamed COOL:Gen), a full lifecycle generative modeler supporting component development and targeting a wide variety of platforms and execution architectures including client/server, Web, and the mainframe.