Component-Based Software Development Technology
| Software components are not new. In fact, they date from the earliest days of programming the first electromechanical computer, the Harvard-IBM Sequence-Controlled Calculator, built for the U. S. Navy in 1938. The first programming forms were wide-lined yellow legal pads. Later, when it was noticed that new programs could often be prepared by modifying old ones, programmers at the Harvard Computation Laboratory started writing programs in the same leather-bound ledger books that undergraduates used to take classroom notes. One of the authors once asked Betty Holberton how she came up with the idea of the first application generator, her sort-merge generator. She replied that she noticed that every time she was asked to write a new sort-merge program for the later Harvard Mark IV computer, she changed only a few parameters in one of her previously checked-out and recorded programs. After a number of times rewriting and reentering a program to change just a few numbers, she realized she could write a program that would use parameter data as input and actually output the new sort-merge program, which could then be loaded into the computer's program storage, the data tapes mounted, and the application run.[10] To our knowledge, this is the first use of a computer program to write another computer program. It wasn't long after that Mrs. Holberton's colleague Dr. Grace Hopper came up with the idea of a compiler, which of course is a computer program that creates a machine-language computer program from a high-level language statement of the intended program's function. Dr. Hopper's compiler research was not popular at the Harvard Computation Laboratory, so she joined the Eckert and Mauchly Company when it did a spin-off from the University of Pennsylvania. The company created Math-Matic, the first compiler to generate mathematical programs from formulas, and Flow-Matic, the first compiler to generate business data processing programs from process or business procedural flow statements.[11] As soon as fully tested computer programs could be stored on magnetic media or 80-column punched cards rather than being reentered from handwritten ledger books, the idea of components really took off. Some of the first commercial compilers, like the original FORTRAN for example, did not allow components or subroutines but with FORTRAN II the technology became a standard programming practice, and shared subroutine libraries became available for mathematical functions, linear algebra, differential equations, and so on. The ability to share such libraries was limited by the variety of computer architectures in the 1950s; there were three address, two address, and single address machines having either 1's compliment or 2's compliment binary arithmetic, with or without floating point hardware, or decimal or character oriented machines having a variety of word lengths of either 24, 27, 30, 32, 36, 40, and 48 bits. It was years before even the programming languages themselves were sufficiently standardized that users of different machines could share component libraries written in high-level languages. But what have software components become today? The idea of software components has been around so long that they have become part of the wallpaper. Software designers talk about components and their properties with a dazzling diversity of semantics. Components, like objects, are seen as the key to software reusability. Moreover, reusing proven programs is an important way to reduce time to implement and cost to develop, while at the same time improving quality. But proponents rarely agree even on the scale or granularity of components. To use a chemical/biological metaphor, some components are the size of atoms, some are the size of inorganic molecules, some are the size of organic molecules, some are as large as amino acids, and some are as large as proteins. Some are even body parts stitched together like Frankenstein's monster. The smallest or atomic components/objects have the greatest reusability, but with the least advantage. The largest (like body parts) have the least reusability and the most complex interfaces, but the greatest advantage or gain when they actually work together. Our own experience in developing activity-based accounting systems suggests that components should be sized, in our metaphor, larger than amino acids but smaller than proteins. A component's size or scope should relate to the modularity of the functional partitioning in the application domain. For example, our General Ledger had 169 components, Accounts Receivable had 219, and Accounts Payable had 209. The system supported nearly 2,000 forms, some of which had up to nine subforms, so clearly there was a high degree of reusability at this basic building-block level. Nonproprietary but domain-specific components like these are the most promising for technical quality, wide reusability, and market advantage.[12], [13] As reported in the preceding section, when we migrated or recast this application system into IBM SanFrancisco™ with its somewhat larger components, it went smoothly. Recasting into a more molecular component-sized framework such as JD Edwards OneWorld™ or Microsoft COM+ would have been much more difficult. The Defense Advanced Research Projects Agency (DARPA), for whom components are very important, has sponsored the development of a Component Software Glossary in an effort to bring component technology out of the background and onto the design table as a set of proto-standards. The URL for this 27-page glossary is http://www.objs.com/survey/ComponentwareGlossary.htm. The raision d'etre for this glossary was to move the field from a descriptive glossary of ambiguous terms to a more nearly prescriptive glossary of precise operational definitions that all software designers would be able to use in a standardized way. Some authors are beginning to emphasize standardized nomenclature for components and may devote an early chapter to the need for such standards.[14] The Object Management Group was founded in 1989 as a consortium of all the software manufacturers save one (guess which one). Its function is to achieve interoperability on all levels of an open market for software objects.[15] The effort to gain a high degree of object interoperability led to the Common Object Request Broker Architecture (CORBA). CORBA 3 is the latest version of the suite of CORBA standards for the CORBA Component Model (CCM). Actually, CCM is an ambitious logical extension of EJB. The original JavaBeans specification called for a flat file of beans or Java components allowing only peer-to-peer connectivity. By connecting one bean instance's listener to another bean instance's event source, events flow. EJB is a hierarchical framework and has no provision for connection-oriented programming. One of the main extensions of CCM to EJB is adding a connection-oriented programming capability.[16] The CCM was explained in a recent paper by Wang, Schmidt, and O'Ryan in a major handbook on component software engineering.[17] Since the demise of SanFrancisco™, the major marketplace component models are COM+, EJB, and CCMwhich, as just noted, is really an extension of EJB. Tier 1 enterprise application software vendors must choose between Microsoft's C# and COM+, or Sun Microsystems' Java and EJB. The smaller vendors and some of the tier 1 vendors are not in a position to dictate to their customers which clients they must use. Therefore, they have to make two business logic librariesone in COM+ to support Microsoft desktop clients, and one in EJB to support Java-based and UNIX desktop clients. A recent evaluation and comparison of the three models by Longshaw[18] gives a side-by-side assessment of the three models, including robustness and security factors (see Table 14.1). Each table entry represents the extent to which a component technology satisfies a criterion on a scale of 1 to 5, with 5 being the best. By Longshaw's analysis, all three rank 4 out of 5 for security, but COM+ has a slight edge in robustness. Note also that despite all these factors, the component models still have a long way to go in achieving robustness.
Adapted from Longshaw, "Choosing Between COM+, EJB, and CCM" |
EAN: 2147483647
Pages: 394