1.0 Introduction

The development of computer technology in recent years has been so fast that computer users have to keep replacing their machines with new generations of computers every few years. This rapid development has been possible mainly because of the advances in computer hardware development. In contrast, the computer software development has been slow and costly. In order to keep the momentum of the development in computing technology, revolutionary approaches towards software development are necessary. Computer developers and researchers have been working hard to find them. Though no breakthrough so far has yet been reported, there have appeared new conceptual progresses towards software development. Many experts see the future and solution to software development in Object Orientation.

This paper tries to explain why the future of software development lies within the domain of Object Orientation and to discuss how the systems will be built using pre-tested and are error free re-usable objects and what new skills the software developers should require. Also, it tries to discuss the use of an intelligent tool to build the entire software system.

Let’s take a brief look at the history of software development so that we may gain some insights of its development into the future.

As is known programming languages can be classified into generations. The first generation is what machine can quickly understand but people can not. It is a machine code (1GL). The mnemonic of that code, which makes some sense to people, forms the second generation (2GL). High level languages which we are familiar with such as FORTRAN, COBOL, Pascal and C are usually thought of as the third generation (3GL). They are conventional programming languages. These languages are independent of the machine and are regarded as function-orientated. The fourth generation language (4GL) is a nonprocedural programming language wherein users indicate IPOS (input, processing, output and storage, a four-step computer-related process) specifications with simple commands. The fifth generation languages (5GL) are not mature yet at present. They belong to AI domain such as Lisp, Prolog.

Figure 1 - The language generation evolution

However, classifying programming languages into generations does not seem to be as accurate as classifying computers into generations. (The generation of computer has a clear concept. But for the software, it is not very suitable to classify them by the above general criteria.). The primary purpose of any high level programming language is to support the software development process by abstracting away from the underlying machine and providing the user with a logical means of expression that wouldn’t otherwise be possible. Using assembly language (2GL), the programmer need not decode machine codes (1GL) and instead he thinks about words. Procedural languages (3GL) hide the complexity of the operations upon data. Object-oriented (OO) languages hide the data and the complexity of the program. Object-oriented techniques are a practical step on the way away from the machine but closer to the user.

The object oriented paradigm is regarded as the direct result of the failure of the conventional language in dealing with large problems.

The computing world faces a serious problem today, which is termed as "software crisis", the term first appeared in 1968 at an international conference. By "software crisis" people mean that there is a most urgent need to produce quality software. The demands for quality software both now and in the future far exceed the capacity of industry to provide.

A quick look at the software engineering record presented in a study by the Comptroller General of the United States in 1979 will show how serious the crisis has been. Among all the government-contracted software projects studied, the study says, only 2% delivered products that worked on delivery. Among the rest 98%, 3% worked after some minor corrections, 45% never used successfully after delivery, 20% were used only after extensive reworking and had to be abandoned eventually, and 30% were paid for but were never good enough to be delivered. Although it is probably impossible to make a fair comparison with systems developed with modern tools in the 1990s, there is no evidence that the situation has improved markedly since 1979 [1]. Even now, you don’t have to go far to find examples for the crisis. IRS project failures may be the most expensive systems development fiasco in history [2].

Figure 2 Cost trends in the 1970s & 1980s

In the 1980s we saw aggravation of the software crisis. While computer hardware became faster and cheaper, software became bigger and much more expensive, as is shown in Figure 2 [3]. Unless we do something about software, these trends will continue into the year 2000.

What will be the solution? Some developers believe "the road to object-orientedness" is the answer. Although no "silver bullet" has been found yet, object-oriented paradigm does represent a fundamental advance in addressing the software crisis.

2.3 What is an object-oriented software

If you attend a software meeting, you are likely to hear such words as "object", "OOA", "OOD", "encapsulation", "polymorphism", etc. Though object-oriented technology started Simula as early as in 1967, it has begun to have a significant industrial impact only since the mid 1980s. There is no universal definition for it yet.

Object -oriented technology is not only a programming language. It is a style. Unlike the traditional functional decomposition which treats a program as a series of tasks, the object-oriented program is looked at as a collection of independent objects co-operating with one another.

The basic elements of an object-oriented software comprise data abstraction, encapsulation, and inheritance with polymorphism. It is something less than an object oriented software, if any of these elements is missing. Abstraction is the essential characteristics of an object that distinguishes it from all other kinds of objects and thus provides defined conceptual boundaries relative to the perspective of the viewer. Encapsulation is the process of compartmentalizing the elements of abstraction that constitute its structure and behaviour; encapsulation keeps the inner workings of an object private while allowing other objects to interact with it. Inheritance defines an is-a hierarchy among classes in which a subclass inherits from one or more generalized superclasses. Polymorphism allows developers to give the same name to services that may work differently in different objects performing the same basic function [4].

There is a popular accepted point of view for distinguishing among languages purported to be object-oriented [5]:

Object-based = encapsulation + object identity

Class- based = Object-based + set-abstraction

Object-oriented = Class- based + inheritance + self-recursion

If you want to do an object-based design, encapsulation should be used and objects with package of functions should have an unique identity. To do a class-based design, set-abstraction will be added. This means to share specifications of collections of like-objects. To do an object-oriented design, it should also have the power inheritance including polymorphism and support self-recursion or self-reference (This means that objects can send messages to themselves).

2.4 Benefits

Object-oriented programming is considered as a significant software revolution by most software developers. Its effect is like that of the assembly line in mechanical production invented in the industrial revolution. As pre-built component parts are used on the assembly line, so object-oriented technology lets the software developer use pre-tested software components to build complex applications [6].

Tremendous massive productivity gains from object-oriented programming have been predicted. The productivity will come from reusability. Also a reduction of overheads through narrowing the gap between the "real world" and the program will be achieved. The benefits derived from the reduced semantic gaps will take place in the whole process of development including analysis, design and programming.

The benefits of object-oriented programming may be summarized in the following formula [5]:

encapsulation + inheritance + Identity => reusability + extensibility + semantic richness

Semantic richness is provided by inheritance and other natural structures, together with constraints and rules concerning the meaning of objects in context.

2.5 Unfavorable opinions of object-oriented programming

Have we found a panacea to the software crisis? Even G. Booch doesn’t think so. Definitely, no. Object-oriented programming is not a magic solution to all programming problems. Object-oriented programming technologies do not even require an object-oriented programming language. They are presented or misinterpreted as panaceas because non-technical managers read about them in business magazines and became convinced that a new wonderful software development technology was born [7].

When in device drivers, embedded systems, or other application areas where memory and processing power are at a premium, the OO model incurs unacceptable overheads. Because of this unacceptable overheads, people may refuse to use OOA or OOD.

There appeared yet another negative opinion about object-oriented programming, which predicts that OOP technology will fail as a programming method for building enterprisewide information system applications. According to this opinion OOP language cannot keep pace with the new technologies for IS application programming [8].

When a project aims to increase an existing non-OO system, or when you truly can’t find "things" in the problem domain to model, if the object methodology isn’t working for a particular project, and you must find another approach which may be object- oriented and may be not, but it does work, then it may be better to use traditional functional decomposition and structured analysis [9].

A lot of people have been examining the merits and demerits of cared object-oriented approaches to information systems modelling. They do not think OO techniques provide the best basis for information modelling despite its advantages over traditional programming [10].

2.6 Software development in the future

Despite the above mentioned negative comments on OO, most people believe that the most promising way of overcoming the software crisis is object-oriented technology. One most important ‘recent’ advance in software technology is object-oriented programming. As a whole, more successes have been achieved than failures encountered in the application of object-oriented technology. This fact supports David E. Brumbaugh conviction that "the successful software developers of this decade will be the ones that learn the secrets of productivity. One of those is object-oriented development, not just programming, but analysis and design as well." [11]. G. Booch has no doubt that the future of software development lies within the domain of object orientation [4].

3.0 Re-usable Objects and Skills

Admittedly after years of research and experiment, object-oriented technology is becoming popular. As G. Booch put it, "OO is far beyond the point of early adopters. I have seen it used in every kind of application." [4]. Nonetheless, it is still not easy to introduce object-oriented techniques where they were not applied before. Future systems will be built with re-usable objects and developers need different relevant skills from those of the conventional language development.

3.1 Re-usable objects

Code reuse had existed before most users ever heard of object-oriented programming. In fact, you can, and should, try to reuse code, even if you don’t use OO techniques. If the software could use standard and correct reusable components to build the applications as a hardware company produces the chips, the software development would not be lagging far behind the hardware in development as it is now.

The object-oriented technique provides two main concepts addressed at increasing the level of software reuse: object encapsulation and class inheritance.

Object encapsulation provides black-box reuse. Every object, when instantiated, provides a well-defined interface by which its clients may access it. A client does not need to know the internal details of an object. New functionality is obtained by composing objects to get more complex functionality. Encapsulation delivers reuse.

Class inheritance provides white-box reuse. With inheritance, the internals of parent classes are often visible to subclasses. Subclasses inherit attributes and methods from their superclasses and may add their own special features. The feature makes building program quickly and easily. Inheritance delivers extensibility but may breaks encapsulation, any change in the parent’s implementation will force the subclass to change.

With enough available reusable components libraries, we would be able to get the software we need by assembling the re-usable components through object composition. But it is no easy job to create such rich libraries, and sometimes inheritance as a reuse technique is more efficient. So inheritance and object composition work together [12].

Object-oriented paradigm emphasizes code reuse because it incorporates the concepts of class libraries and inheritance. Classes from the library can be used to instantiate objects, or to inherit from while constructing new classes. Object-oriented programming provides the possibility of building the system by using re-usable objects from the library. Before that idea is realized, we need consider the following:

Object standard

It always seems that the industry struggles to distinguish between dreams and reality We have a dream of OSI seven layer frame, but TCP/IP is the mainstream. Object standards are also a problem. The Object Management Group’s Common Object Request Broker Architecture (CORBA) has emerged as the standard for object interoperability. However, other standards, such as IBM’s System Object Model (SOM) and Distributed SOM (DSOM), Microsoft’s OLE and upcoming network OLE, and Digital Equipment’s Common Object Model (COM) continue to confuse the issue. A variety of interfaces and bridges are now available that provide an effective, if somewhat clumsy, solution [13].

Libraries

Once universal object standards are established, enough rich and high quality libraries must be set up. This is a precondition for building systems based on re-usable objects. To be re-usable, the object itself must have the following qualities:

• Anticipation of other contexts of use.
• Component being ‘findable’.
• Being understandable.
• Adequate provision of the services required [14].

Meyer’s five principles for modularity should also be included as standard requirements in the design of the objects [15]:

• Linguistic modular units
• Few interfaces
• Small interfaces
• Explicit interfaces
• Information hiding

OO’s encapsulation ensures that the changes inside the object don’t affect the rest of the application. The re-usable objects from the libraries must be pre-tested and error free before they are reused in any application. So you don’t need to worry about bugs input from the re-usable objects.

Object classification techniques are needed to help programmers understand the libraries they are dealing with. A significant problem is how to manage the large component libraries for object-oriented programming. It seems that neither to use browser for the hierarchical library nor to retrieval a keyword from a conventional information system is ideal. Ian Graham believes that a combined approach is best. But it is not available now [5]. It needs more research and time to decide what is the best approach to manage the re-usable objects library.

Performance

Applications can be built more quickly and more cost-effectively when the plug-compatible components are used. But they are not always easy to use. So many people believe reusable components are always too slow and they would like to build custom software. However, even if custom-built software saves time, this view fails to consider other things, such as debug time, document time, and maintain time [16]. Just like Patti Dock, IBM’s director of object technology engagements, says: "But every time you write a piece of code, you add more to the cost down the line,", That means more lines of code that need to be individually tested and maintained. "With OO, managers must reward the reuse of existing code, in effect, paying programmers more to write less" [13].

3.2 Different skills from 3GL-style development

If software developers have enough re-usable objects, software development will be a process of putting the pre-tested and error free objects together as the work of an assembly line. The developers will have to acquire skills for this type of software development which are different from those used in the conventional languages (3GL) development.

Object-oriented programming may be a better kind of structured programming. But it is not just structured programming wearing a new hat. Object-oriented development technology was designed to leap-frog traditional program development. Conventional (3GL) and object-oriented developments are shown in Figure 3 and Figure 4 [17]:

In a conventional development environment, the idea of solving the problem is working from the top (problem) towards the solution with little emphasis on reuse. The solution "boxes" at the bottom are the black boxes. Every piece of a program is boxed off so the complexity of that piece is hidden. They are functions in C or procedures in Pascal. The finished program is a collection of function calls, a single top-level function. Some libraries of useful routines may replace the "boxes", if the developer is lucky. This top-down decomposition always made the solution "boxes" highly application specific and therefore leads to non-reusable modules.

 

Figure 3 Conventional development

 

Figure 4 Object-oriented development

 

The designers of procedural languages made an unconscious assumption when using the model of the black box which goes something like this: Maintenance shouldn’t happen. Needs don’t change. Once the code is working, debugged, and corrected, it should be capsulated into its black box. This assumption works fine as long as the project size is limited, but it can cause surprising disasters as complexity creeps into the "large" category [18]. When the system grows more complex and larger, software slowly becomes harder to change, harder to get the bugs out, and harder to find programmers who want to do the maintenance work.

Unlike the conventional development, the object-oriented development (Figure 4) can be a bottom-up approach. It works in a more practical way that both downwards from the problem and upwards from the computational resources until, by meeting half-way, a solution is completed [17]. The designer is sub-dividing the problem while he is looking for the re-usable objects in the existing library. Once the units of the problem can be implemented using the integrated re-usable objects specific to the problem, the solution will be found.

An interesting contribution to software reuse brought by the object-oriented approach is that we can consider multiple clients and multiple implementations, not just one implementation as with subroutine libraries. If an object agrees to support certain functionality, it can be used polymorphically with other implementations of the same functionality [18].

The difference between conventional and OO developments lies in the re-usable of components. The conventional development less emphasizes the re-usable components to solve a problem. It uses the from top (the problem) to bottom (the solution) approach. The object-oriented development emphasizes the re-usable components. It solves the problem mainly from bottom to top. The designer should know the re-usable objects and how to use them to solve a problem. In other words, the developer should have the skill to use those existing components.

4.0 Intelligent Tool for OO

If the developer determines to use object-oriented programming, he will find that a completely different way of thinking about application development is needed, from talking about requirements and design, to coding and maintenance [13].

When the developer first begin OO development, it should be easy finding existing classes because of the small number of them. As the development goes on, and the number of projects and classes grow, finding classes for possible reuse will become increasingly difficult. The volume of classes will make it hard to remember exactly what’s available. When systems are built by using re-usable objects in the future, it will be impossible for a designer to know each of so large a number of re-usable objects. A major difficulty with class libraries will be the sheer difficulty of knowing what the library contains and what its classes do. If designers can’t find an existing component quickly, they’re likely to design an entirely new component. This is true even if they would save more time in the long run by spending a little more time looking for the right component. A component isn’t reusable unless it’s reused. Reuse is vital to quality and productivity. Without it, OO will be meaningless. Therefore, special tools should be provided to help the developer to use re-usable components easily, conveniently and intelligently. The following describe the software producing process with the help of such tools:

The intelligent tool will find the wanted objects in the library according to the software requirements. With all the needed re-usable objects found, the tool will integrate the objects into larger components or functioning programs and finally build the software in the design process box.

Figure 5 Software producing process

 

Building the tool needs research in artificial intelligence and expert systems. From the American ATP (Advanced Technology Program) list in 1995 research program for the next five years, we find that some similar technology is studying. "Xerox, Palo Alto Research, Centre, Palo Alto, California; $1,785 million. Develop a software technology that separates a component’s semantic details from implementation details, to support the use of software components and automated software composition for high-performance applications.", "SciComg, Austin, Texas; $1,947 million. Develop component software and automated software composition technologies for scientific computing." [19]. We expect that the intelligent tool for OO will soon be built.

5.0 Conclusion

Moving software development from expensive, error-prone, hand-crafted, labour-intensive production of monolithic, multifunction point solutions, to automated composition of independently developed, fine-grained components that are competitively available. is the object pursued by most software developers.

So far OO appears to offer the best means to cope with complexity and variation in large systems. When families of similar systems must be built, or single systems must undergo frequent changes in requirements, object-oriented languages, tools and methods offer the means to view such systems as flexible compositions of software components. It may still require a great deal of skill to build flexible systems that can meet many different needs, but at least object-oriented technology simplifies the task. I am sure that OO can deliver faster, good quality code that is more reliable and reusable than ever before.

Although it is not easy to grasp OO techniques at the beginning, those who have worked with OO for more than a few months are reluctant to go back to any other way of developing systems [9]. OO promises to increase the speed and accuracy of application development and allows anyone to create new programs by simply selecting objects and changing parameters. This should be convincing evidence that OO has a great future.

OO is indeed a very promising technology but it has not yet solved the essential problems of the very nature of software-that it is complex, changeable, subject to arbitrary standards and unstable. It would be very wrong to think that it can solve all problems in software area.

However, it is clear that until standards, higher-level class libraries and training issues are resolved, objects will not become the mainstream technology.

Much research is needed in the areas of re-usable library and special tools to support the development of reusable components. Investment in the library research should be provided and people’s habit, such as writing their own program instead of re-usable components, should gradually be changed.

If the assembly line and the prefabricated blocks revolutionized industry and house building, I cannot see why OO will not revolutionize the software development.

 

References

[1] Allen B. Tucker, Andrew P. Bernat, Fundamentals of Computing II C++ Edition, [McGraw-Hill, 1995], pp. 49-50.

[2] Anthes, Gary H., "IRS project failures cost taxpayers $50B annually," Computerworld, Oct. 14, 1996 v30 n42 p1(3).

[3] Ted Lewis, Object Oriented Application Frameworks, [M manning Pub Co., 1995], pp. 6.

[4] Grady Booch, "Coming of Age in an Object-Oriented World," IEEE Software, November 1994, pp. 33-41.

[5] Ian Graham, Object Oriented Methods (Second Edition), [Addison-Wesley Publishing Company, 1993], pp. 28, 47, 51.

[6] Cox B. J. and Novobilski A., Object-Oriented Programming -An Evolutionary Approach (2nd Ed), [Addison-Wesley, 1991], pp. 1-5.

[7] Strehlo, Kevin, "Don’t tinker with new toys, improve the process," Infoworld, August 26, 1996 v18 n35 p77(1).

[8] Goetz, Martin A., "Absolutely not," Computerworld March 25, 1996 v30 n13 p101(2).

[9] Gora, Michael, "Object-oriented analysis and design," DBMS June 1996 v9 n7 p61(6).

[10] Halpin, Terry, "Business rules and object-role modelling," Database Programming & Design, Oct. 1996 v9 n10 p66(5).

[11] David E. Brumbaugh, Object-Oriented Development, [John Wiley & Sons, Inc., 1994], pp. 1.

[12] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software [Addison-Wesley Publishing Company, Inc., 1995], pp. 19-20.

[13] ?? "Are you ready for the object evolution?" Software Magazine May 1996 v16 n5 pS3(3).

[14] R. Hodgson, "The Impact of Software Reuse on Object-Oriented Methods," Software Reuse and Reverse Engineering in Practice [Chapman& Hall, 1992], pp. 163.

[15] Meyer B., Object-oriented Software Construction, [Prentice-Hall, 1988].

[16] Martin L. Griss, Marty Wosser, "Making Reuse Work at Hewlett-Packard," IEEE Software, Jan. 1995, pp.105-107.

[17] J. Daniels "Object-oriented programming and systems: the object-oriented life cycle," Object-oriented Programming Systems, J.J. Florentine, [Chapman& Hall, 1991], pp. 73-74.

[18] Bruce Eckel, C++ Inside & Out, [McGraw-Hill, 1993], pp. 7-8.

[19] Stephen Barlas, "New Congress Threatens Software Reuse Program," IEEE Software, Jan. 1995, pp. 108-109.