baumgard@uhunix1.uhcc.Hawaii.Edu (Jon Baumgardner) (02/01/91)
The following is a review of over 20 articles on OOPS from Byte, Computer Language, Dr. Dobbs Journal, ACM, and Programmer's Journal magazines. It is seven pages long and was originally written in Word Perfect. I editted the document in Windows 3.0's Write to get a text file. You might want to download it to read it. Please reply to me directly if you see any glaring errors. I will attemp to answer all inquiries after February 20th and post a summary of the conclusions. Please press n now to avoid a long document or s to save it to a file for downloading. Thank you for your Kokuo (coop- eration in Hawaiian). PS Does anybody know when COBOL++ will be available? 1-14-91 08:22a OOPS REVIEW Object Oriented Programming Jon Baumgardner baumgard@uhunix.mso.hawaii.edu Overview Object oriented programming (OOP) is an emerging technology extending or replacing structured programming techniques. OOP promises to simplify programming in ever more complex systems and reduce maintenance time for constantly changing systems. Once OOP becomes common, programmers will no longer start from scratch on aproject or work like 16th century skilled tradesmen. The theory behind systems development will be to find and order the rightparts (objects), change the objects a little bit for your own needs, test each object, then put the system together with aminimum of integrating code. Even file structures can be made into objects. In this paper I will: - review the basic concepts of the object oriented approach - review seven of the major OOP languages - compare relational databases with Object Oriented Data Bases (OODB) - describe the new object oriented systems analysis and design methods - attempt to fore see how OOP can be used in MSO Basic Concepts All object oriented programming languages (OOPLs) include three concepts: objects, classes, class inheritance, and message passing. Some OOPLs add several other concepts: polymorphism, dynamic binding, encapsulation, concurrency, persistent objects, strong typing, and object libraries with search and choice facilities. The following is an easy to read description of these concepts one-at-a-time. Objects are data/code hybrids. An object is a reusable component including code and data that can be used by several different programs over and over again without changing the object in anyway. A particular object is an 'instance' of the object. An instance can be viewed as the time an object was used with aparticular program. Objects have to be very general in nature sothey can be used in many ways. Object Classes are groups of objects. Objects are grouped by their behavior. Read/write, move, push, to color, to have are all behaviors. Class Inheritance is the ability of an object to derive its data and functionality automatically from another object. There is always a root object within a class. The root object has the most basic components for this class of objects. So, in the Read/writeclass, the root might have a write command and a read command. The next layer of objects might include an object to print to the screen (including the number of lines, characters per line, etc.), an object to print to a printer, an object to read a disk drive, an object to read from the VAX... At the third level some languages allow many to many relationships but most only allow a one to many relationship (similar to the DOS directory hierarchy). Message Passing - instead of calling a method (or procedure in COBOL) directly, you call an object's message by sending that object a message indicating which method you wish to call. The object then uses the message to select which method code isactually invoked. Polymorphism is the ability to have different kinds of objects respond to the same message in different ways. Within a program anobject may have a different output depending on the state it was left in when it was used last _or_ the output may be different depending on what message was sent to it. Dynamic binding when an object is bound to a procedure at run-time as opposed to compile-time. The code associated with a given procedure call is not known until the moment of the call at run-time. The program can invoke a method (procedure in COBOL jargon),and each of the receiving objects will execute its own version ofthe method to achieve appropriately customized actions. Late binding involves setting up a run.time table search to match methodnames to local method code which could increase the time it takesto run the program. Dynamic (or run-time) binding can make a program very flexible. Encapsulation is the protection of an object's private data from outside access. No other object can access the internal data of another object. This is very important in making an object reusable. Concurrency has to do with parallel execution of parts of a computation. The execution of components of a program can either use interleave features on a single processor or be distributed to several processors. Strong Typing is a concern of software engineering. OOP supports an abstract type. This way the type of data to be manipulated is separated from _how_ the data is to be manipulated. The type of data has to be in the run-time table so the data can be bound at run-time (see dynamic binding above). Persistent objects are objects that can be used by many applications without revision or rewrite. If a revision is needed, the proper response is not to revise a debugged object but to create a descendant object that embodies the new elements required. Persistent objects can be kept in their compiled form with documentation. Class Libraries are collections of persistent objects or reusable software stored in class or type libraries with no need for source code. There are commercially available class libraries already. Some languages have navigation facilities to search the library and read the documentation associated with objects. Some people envision national public domain libraries of debugged, virus free,compiled objects that can work on any platform. OBJECT ORIENTED PROGRAMMING LANGUAGES There are seven major OOPLs. Smalltalk, Actor, Eiffel, Trellis are true OOPLs with most of the concepts outlined above. C++, Turbo Pascal, and Quick Pascal have some OO extensions. COBOL++ is just around the corner but it too will just have some OO extensions. The following is a quick review of the strengths and weaknesses of each language. Real OOPL Smalltalk was one of the first languages with a graphical interface and true objects. Most graphical user interfaces (GUIs) were derived from Smalltalk. You can use this language on the MAC, under X, in unix environments, and soon in Windows 3.0. You have to use the Smalltalk GUI though. Everything must be an object and these objects are translated through a "virtual machine" to the platform. No recompiling is necessary to change platforms. All of Smalltalk is written in objects. All objects are ava ilable for modification. A "generation scavenger" eliminates dead objects after a program is run (reinitializing them) and an incremental garbage collector also can be used to clean up used objects. Programming in Smalltalk is incremental as each object needs to be debugged and compiled as it is created. After the program is debugged a "stripper" can be used to remove compilation, debugging, and browsing support from an program to create a stand alone application. The best part about this system is the library toolset. Browsers and inspectors help you explore the systems's class hierarchy, methods, and data. Multiple desktops are supported so you can write your code several different ways and test each one at once without messing up other desktops. Smalltalk is a great prototyping tool but is a memory hog and runs slow at times. Current implementations include Smalltalk-80 and Smalltalk/V286 ($499.95). Actor ($495.00) has the feature of not having to define a classinstance variable, the compiler will automatically associate the ancestor's (the higher level object's) methods and instance variables with a new class and define the instance variable when the object is created. No types are assigned to instance variables because Actor all variables hold objects and every object 'knows'its own type. Actor also has a fine library toolset and a garbage collector that destroys objects that can no longer be refer enced from a program. Eiffel is a little different. In Eiffel classes can use eachother's facilities. A class which relies on another class is called a client, the other class is the supplier. Some features of a supplier are purely internal and the export clause lists the features which are available to clients. Inheritance is multiple and features may be excluded from the heir. Repeated inheritance is also supported. Abstract classes (see Smalltalk above) are called deferred classes in Eiffel. A flattened class in Eiffe l has no inheritance (no root class, in essence it supports multiple root classes as no other language presented above does). Eiffel supports the generation of final code in C for portability. The language specifications of Eiffel are in the public domain and anyone is welcome to write Eiffel compilers, interpreters, etc. The International Eiffel Consortium was created in August 1990. Eiffel is the most experimental and leading edge of the languages reviewed here. Trellis (from Digital) has some unique type features. A"parameterized" type is a generic form of a type often associated with collections of objects. A "type union" specifies that several types of objects might occur as the value of some expression. A"type case" can perform different actions depending on the type ofan object. Trellis also support abstract type. Trellis has a Call-out Library to convert Trellis code to C and a Call-in Library to convert code in other languages to Trellis code. "Foreig n operations" can be used to call external routines. Summary All of these languages support libraries of objects and tools for browsing. The only way to find the right mix of features in a real OOPL for a group of programmers is probably to try the OOPL first. All have a separation of Type and Class except Trellis. Languages with OOPL extensions C++ is the most widely used of all OOPLs. C++, like all the languages with OOPL extensions, gives the developer a chance to learn OOP without losing anything from the standard C. Strong type checking is the most obvious benefit but automatic pointer maintenance is not supported. The class construct allows programmers to define new types. Objects are the instances ofthese classes (types are now classes in C++). Constructors initialize classes and destructors clean up deleted objects and close them afte r a program is run. A static object automatically calls its own constructor and destructor. Automatic objects reside on a stack an are the local variables within a function and also automatically calls its own constructor and destructor. Dynamic objects have to be explicitly opened and closed. C++ supports multiple inheritance and all classes don't have to come from a single root. A single root is defined as virtual. Virtual functions are called depending on the class of the object being invoked. The data or functions (methods) within an object can be public or private (see Eiffel) or protected. A class can also specify a friend function that can access private and protected data or methods within an object. c++ source code is translated into C then compiled. Quick Pascal has only one thing that is better than Turbo Pascal. It runs in Windows. The main drawback is that it does not have a stand-alone debugger. Turbo Pascal has one advantage and that is the availability of commercial libraries of objects. Run-time binding is supported. Methods can be executed from within the Turbo Debugger (TD) environment. TD provides an Object Instance Inspector that allows you to look at the data of object instances. There are also Object Type and Method Inspectors. Object Professional ($150.00) is a library of OO classes for Turbo Pascal. It has 50 units, 130 objects, 2100 documented procedures, functions, and methods, 1200 additional internal routines, and 1600 pages of text and examples in three manuals. Object Professional includes a unit to make Terminate and Stay Resident (TSR) programs. It also has an Object called Command Processor that translates key sequences into command codes making key assignments easy to reconfigure. There are also browsers and choosers for ease of navigation through the library. Many of the library's objects are routines that were built for TP4.0 then translated into objects for TP5.5. Tools for GUIs are included. Summary There are no debugging tools for any of the OO extension languages' code except for TP 5.5. Debugging is done at the original language level. There is no virtual machine as in Smalltalk to interface with different platforms. They do not support persistence explicitly but it can be done. Concurrency is also not supported. Parameterized types, exception handling and garbage collection are not supported. Polymorphism is an option in these languages. You have to use message passing to support polymorphism
baumgard@uhunix1.uhcc.Hawaii.Edu (Jon Baumgardner) (02/01/91)
Overview Object oriented programming (OOP) is an emerging technology extending or replacing structured programming techniques. OOP promises to simplify programming in ever more complex systems and reduce maintenance time for constantly changing systems. Once OOP becomes common, programmers will no longer start from scratch on aproject or work like 16th century skilled tradesmen. The theory behind systems development will be to find and order the rightparts (objects), change the objects a little bit for your own needs, test each object, then put the system together with aminimum of integrating code. Even file structures can be made into objects. In this paper I will: - review the basic concepts of the object oriented approach - review seven of the major OOP languages - compare relational databases with Object Oriented Data Bases (OODB) - describe the new object oriented systems analysis and design methods - attempt to fore see how OOP can be used in MSO Basic Concepts All object oriented programming languages (OOPLs) include three concepts: objects, classes, class inheritance, and message passing. Some OOPLs add several other concepts: polymorphism, dynamic binding, encapsulation, concurrency, persistent objects, strong typing, and object libraries with search and choice facilities. The following is an easy to read description of these concepts one-at-a-time. Objects are data/code hybrids. An object is a reusable component including code and data that can be used by several different programs over and over again without changing the object in anyway. A particular object is an 'instance' of the object. An instance can be viewed as the time an object was used with aparticular program. Objects have to be very general in nature sothey can be used in many ways. Object Classes are groups of objects. Objects are grouped by their behavior. Read/write, move, push, to color, to have are all behaviors. Class Inheritance is the ability of an object to derive its data and functionality automatically from another object. There is always a root object within a class. The root object has the most basic components for this class of objects. So, in the Read/writeclass, the root might have a write command and a read command. The next layer of objects might include an object to print to the screen (including the number of lines, characters per line, etc.), an object to print to a printer, an object to read a disk drive, an object to read from the VAX... At the third level some languages allow many to many relationships but most only allow a one to many relationship (similar to the DOS directory hierarchy). Message Passing - instead of calling a method (or procedure in COBOL) directly, you call an object's message by sending that object a message indicating which method you wish to call. The object then uses the message to select which method code isactually invoked. Polymorphism is the ability to have different kinds of objects respond to the same message in different ways. Within a program anobject may have a different output depending on the state it was left in when it was used last _or_ the output may be different depending on what message was sent to it. Dynamic binding when an object is bound to a procedure at run-time as opposed to compile-time. The code associated with a given procedure call is not known until the moment of the call at run-time. The program can invoke a method (procedure in COBOL jargon),and each of the receiving objects will execute its own version ofthe method to achieve appropriately customized actions. Late binding involves setting up a run.time table search to match methodnames to local method code which could increase the time it takes to run the program. Dynamic (or run-time) binding can make a program very flexible. Encapsulation is the protection of an object's private data from outside access. No other object can access the internal data of another object. This is very important in making an object reusable. Concurrency has to do with parallel execution of parts of a computation. The execution of components of a program can either use interleave features on a single processor or be distributed to several processors. Strong Typing is a concern of software engineering. OOP supports an abstract type. This way the type of data to be manipulated is separated from _how_ the data is to be manipulated. The type of data has to be in the run-time table so the data can be bound at run-time (see dynamic binding above). Persistent objects are objects that can be used by many applications without revision or rewrite. If a revision is needed, the proper response is not to revise a debugged object but to create a descendant object that embodies the new elements required. Persistent objects can be kept in their compiled form with documentation. Class Libraries are collections of persistent objects or reusable software stored in class or type libraries with no need for source code. There are commercially available class libraries already. Some languages have navigation facilities to search the library and read the documentation associated with objects. Some people envision national public domain libraries of debugged, virus free,compiled objects that can work on any platform. OBJECT ORIENTED PROGRAMMING LANGUAGES There are seven major OOPLs. Smalltalk, Actor, Eiffel, Trellis are true OOPLs with most of the concepts outlined above. C++, Turbo Pascal, and Quick Pascal have some OO extensions. COBOL++ is just around the corner but it too will just have some OO extensions. The following is a quick review of the strengths and weaknesses of each language. Real OOPL Smalltalk was one of the first languages with a graphical interface and true objects. Most graphical user interfaces (GUIs) were derived from Smalltalk. You can use this language on the MAC, under X, in unix environments, and soon in Windows 3.0. You have to use the Smalltalk GUI though. Everything must be an object and these objects are translated through a "virtual machine" to the platform. No recompiling is necessary to change platforms. All of Smalltalk is written in objects. All objects are available for modification. A "generation scavenger" eliminates dead objects after a program is run (reinitializing them) and an incremental garbage collector also can be used to clean up used objects. Programming in Smalltalk is incremental as each object needs to be debugged and compiled as it is created. After the program is debugged a "stripper" can be used to remove compilation, debugging, and browsing support from an program to create a stand alone application. The best part about this system is the library toolset. Browsers and inspectors help you explore the systems's class hierarchy, methods, and data. Multiple desktops are supported so you can write your code several different ways and test each one at once without messing up other desktops. Smalltalk is a great prototyping tool but is a memory hog and runs slow at times. Current implementations include Smalltalk-80 and Smalltalk/V286 ($499.95). Actor ($495.00) has the feature of not having to define a classinstance variable, the compiler will automatically associate the ancestor's (the higher level object's) methods and instance variables with a new class and define the instance variable when the object is created. No types are assigned to instance variables because Actor all variables hold objects and every object 'knows'its own type. Actor also has a fine library toolset and a garbage collector that destroys objects that can no longer be referenced from a program. Eiffel is a little different. In Eiffel classes can use each other's facilities. A class which relies on another class is called a client, the other class is the supplier. Some features of a supplier are purely internal and the export clause lists the features which are available to clients. Inheritance is multiple and features may be excluded from the heir. Repeated inheritance is also supported. Abstract classes (see Smalltalk above) are called deferred classes in Eiffel. A flattened class in Eiffel has no inheritance (no root class, in essence it supports multiple root classes as no other language presented above does). Eiffel supports the generation of final code in C for portability. The language specifications of Eiffel are in the public domain and anyone is welcome to write Eiffel compilers, interpreters, etc. The International Eiffel Consortium was created in August 1990. Eiffel is the most experimental and leading edge of the languages reviewed here. Trellis (from Digital) has some unique type features. A"parameterized" type is a generic form of a type often associated with collections of objects. A "type union" specifies that several types of objects might occur as the value of some expression. A"type case" can perform different actions depending on the type ofan object. Trellis also support abstract type. Trellis has a Call-out Library to convert Trellis code to C and a Call-in Library to convert code in other languages to Trellis code. "Foreign operations" can be used to call external routines. Summary All of these languages support libraries of objects and tools for browsing. The only way to find the right mix of features in a real OOPL for a group of programmers is probably to try the OOPL first. All have a separation of Type and Class except Trellis. Languages with OOPL extensions C++ is the most widely used of all OOPLs. C++, like all the languages with OOPL extensions, gives the developer a chance to learn OOP without losing anything from the standard C. Strong type checking is the most obvious benefit but automatic pointer maintenance is not supported. The class construct allows programmers to define new types. Objects are the instances ofthese classes (types are now classes in C++). Constructors initialize classes and destructors clean up deleted objects and close them after a program is run. A static object automatically calls its own constructor and destructor. Automatic objects reside on a stack an are the local variables within a function and also automatically calls its own constructor and destructor. Dynamic objects have to be explicitly opened and closed. C++ supports multiple inheritance and all classes don't have to come from a single root. A single root is defined as virtual. Virtual functions are called depending on the class of the object being invoked. The data or functions (methods) within an object can be public or private (see Eiffel) or protected. A class can also specify a friend function that can access private and protected data or methods within an object. c++ source code is translated into C then compiled. Quick Pascal has only one thing that is better than Turbo Pascal. It runs in Windows. The main drawback is that it does not have a stand-alone debugger. Turbo Pascal has one advantage and that is the availability of commercial libraries of objects. Run-time binding is supported. Methods can be executed from within the Turbo Debugger (TD) environment. TD provides an Object Instance Inspector that allows you to look at the data of object instances. There are also Object Type and Method Inspectors. Object Professional ($150.00) is a library of OO classes for Turbo Pascal. It has 50 units, 130 objects, 2100 documented procedures, functions, and methods, 1200 additional internal routines, and 1600 pages of text and examples in three manuals. Object Professional includes a unit to make Terminate and Stay Resident (TSR) programs. It also has an Object called Command Processor that translates key sequences into command codes making key assignments easy to reconfigure. There are also browsers and choosers for ease of navigation through the library. Many of the library's objects are routines that were built for TP4.0 then translated into objects for TP5.5. Tools for GUIs are included. Summary There are no debugging tools for any of the OO extension languages' code except for TP 5.5. Debugging is done at the original language level. There is no virtual machine as in Smalltalk to interface with different platforms. They do not support persistence explicitly but it can be done. Concurrency is also not supported. Parameterized types, exception handling and garbage collection are not supported. Polymorphism is an option in these languages. You have to use message passing to support polymorphism. OBJECT ORIENTED DATABASES OODBs use the navigational model of computation. This model uses objects to model the real world rather than tables. OODBs include the code within the database itself. Two implementations are the 'document' database and the distributed database. On a LAN, a centralized object server managing the persistent database could beused by many client nodes. OODBs are used now in very complicated CAD systems where vectors, tables, linked lists constantly recur invery tangible form in the design data. Geographical Information Systems (GIS) also have implemented an object layer over the relational database. Ultimately OODBs are being used where the relational model is not strong enough to handle the complexity oftoday's problems. OBJECT ORIENTED ANALYSIS AND DESIGN OOA and OOD are characterized by repeated prototyping, bottom up design of the objects in conjunction with top down analysis of the system. What follows are two suggested life cycles. This field is brand new and few of the IS shops in the world are using it. There are actually two areas here. The design of generic reusableobjects and the building of heirs to the generic objects and integration of those objects into a viable program. One OOA suggests eight steps for specification. 1) Undertake systems requirements specifications. These would include timing details, hardware usage, cost estimates, and feasibility studies. 2) Identify the key objects that would solve the problem. Distinguish between active and passive objects. 3) Establish the data flows between the objects. Entity relationship diagrams (ERDs) and entity data flow diagrams (EDFDs) would be drawn here. 4) Decomposition the objects into "sub-objects". Make lower level EDFDs. Identify reusable components. 5) Check for new objects. Construct objects from libraries. Start coding and testing of objects. 6) Group functions under new objects. Reevaluate the total set of classes using inheritance diagrams. 7) Assign new objects to appropriate domains. Go back to step 4 and reevaluate lower level DFDs and ERDs. Prototype the system. Another OOA method has five steps: 1) Identify the behaviors. Define the system's responsibilities in view of the behaviors the people or processes exhibit. This means find the verb that describes what is done in each situation. 2) Derive objects using the behavioral perspective. Look at who or what is performs the behaviors giving name, responsibilities, and collaborators. 3) Classify the objects. Group the objects according to some similarity of behavior (function) and state (form). 4) Identify relationships Draw a preliminary sketch of the objects in relation to one another. 5) Model the process Determine which objects initiate activities and identify the sequence of activities. THE IMPACT ON MSO As more people start using Windows and other GUIs, our internalapplications are going to become more complex. The days of writing programs by yourself from scratch are coming to an end as more users want to access alternative platforms, get their data from anywhere without knowing where it is, and as expectations rise. The answer is probably not to hire more people but to use the people we have and give them the best tools available. In late 1989, CODASYL created a new subcommittee to recommend changes to the COBOL language to make it object oriented. Even though the next version of COBOL is not scheduled until 1999, vendors will be releasing object oriented COBOL within one or two years. "For people building new systems for which the conventional technologies are demonstrably inadequate, it may be appropriate tobegin using object oriented techniques" according to Edward Yourdan (structured analysis and design CASE tool designer and structured A/D guru). MSO is certain to face these challenges. It seems to make sense to use the User Status report as a pilot project to gradually learn OOP techniques through Turbo Pascal before we 'have to' learn OOP to use COBOL++.