Vision

There often is some confusion around the term object orientation (OO). This is due to the fact that this term in fact refers to two concepts: the object paradigm and object technology.

The object paradigm
Primarily, object orientation is a school of thought, or a paradigm, with respect to designing and building IT applications. The object paradigm uses objects as building blocks for applications. The paradigm has great consequences, both for the architecture of the applications and for the way developers work.

Object technology
Secondly, the term object orientation is used for various forms of information technology based on the object paradigm. Object technology enables us to realise applications according to the object paradigm. Object technology started with object-oriented programming languages, that were mainly used in support of simulation software and GUIs. Meanwhile, object technology has expanded to include multimedia applications and object-oriented databases. There are also object-oriented methods for the analysis and design of custom applications.

4.4.1 The Object Paradigm

The object paradigm focuses on objects. The term 'object' has three different meanings in application development according to the object paradigm. The paradigm is based on real objects. These real objects are represented in IT applications in the form of data objects. The data objects are realised technically by defining objects in an object-oriented programming language. The definition of an object is called a class.

Objects in reality
The principle of the object paradigm is that we can regard the world around us as a collection of objects that interact and relate to each other. People are used to think in objects with respect to the world around them. Objects are for example the people themselves, the products and the services they supply and the documents they use. All these 'objects' are involved in processes. Employees of an insurance company, for example, settle a damage claim concerning a car of an insurance client. As people have difficulty 'seeing' a process, in practice they use an object, such as a damage dossier, to support the process and keep it together as a whole. People 'objectivate' the process by means of a damage dossier.

Objects in applications
Real-life objects and processes can be represented in applications in the form of data objects. When we want to describe the working of a company when designing an information system, we do so by determining which business objects and business processes from the real world are relevant. We then make a representation in the form of a data object of each of these real world business objects and business processes. For each data object, we specify the data, the functions and the interface.

The data
We specify the data we want to store about the real world object or process. In OO terms, the value the data have at a certain moment represents the state of the object.

The functions
We specify the functions with which we store, modify and retrieve the data of the data object. Each function can be regarded as a procedure or a programme. In OO terms, a function is called the method of the data object.

The interface
Each data object function includes a message in the form of a request to start the function and a message in the form of an answer with which the object returns the result of the function. The requests and the answers together form the object interface. Both users and other objects can give requests to an object. The user puts his requests to an object via the screen and the object will also display its answers on the screen. In such cases the function is a programme in the form of a tool the user uses to modify the object. An object can also request something of another object. In that case the function is a programme in the form of a subroutine that executes the function and returns an answer to the requesting object. In such cases there is a kind of 'subroutine call' between the objects, in which the requesting object performs the role of client and the answering object that of server.

Figure 4.4 The object 'Savings Account'.

A data object in a computer system is an abstraction of a real object in reality. The example given in Figure 4.4 it that of a 'savings account'. The object consists of data we want to record about a savings account. Functions are for example 'open account', 'calculate interest' and 'credit 25 guilders to the account'.
We base the design of a data object of 'savings account', on the life cycle of a savings account as a bank product agreement. The life cycle of a savings account roughly consists of advising, proposing, closing, managing for the period of duration, and terminating.
The data object now consists of:

• the data necessary to record all the states a savings account can go through during its life cycle;
• the functions we require to change the state of the data object during its life cycle and the functions we need to request the state;
• the interface of the data object in the form of all the requests and answers of the functions.

Objects in technical realisation
The data objects are in fact the applications we are building. The best way of realising them is by using object-oriented programming languages such as Smalltalk and C++. We realise a certain object type in an object-oriented programming language by defining a class that specifies the data, methods and messages of that object type. In object-oriented languages, numbers, codes, texts and even parts of interfaces, such as buttons and scroll bars are all defined as classes. This means that developers can specify data objects that correspond with real-world objects or processes in classes that in turn use smaller objects via messages. A data object is thus realised as a cluster of collaborative objects of different classes.

Real World Modelling
With object-oriented languages, data objects can be realised as documents that present themselves to the user via GUIs. In multimedia applications the objects can present themselves as texts, pictures, forms, moving images and sound. The data objects in automated systems can therefore have the same appearance as the files, documents and forms in existing manual computer systems.
The object paradigm allows for 'Real World Modelling'. At his work station, the user works with data objects that look and behave just like objects from the real world. An object like a form or a file on screen has the same appearance as its paper counterpart. A data object of for example an aeroplane or a car contains the complete design of the object, including facilities to simulate of the object's behaviour.
For developers Real World Modelling has great advantages. They can first translate real world business processes and objects into data objects, and then realise them as classes in an object-oriented language.

4.4.2 Object Technology

The development of object-oriented application requires information technology that supports the object paradigm. This involves object-oriented programming languages, methods and development platforms for object-oriented application analysis, design and programming, object-oriented operating systems and object-oriented database management systems. The development of all this technology is still in progress. Only in recent years we have seen a clear increase in the use of object technology. The reason for this growing interest is the fact that many new IT developments, such as GUIs, multimedia and simulation software are best realised by means of object-based technology.
Developers of business applications, too, are becoming more interested in object orientation. They expect advantages such as:

• better connection between business management and applications because of Real World Modelling;
• re-use of existing components in new applications;
• more flexible applications, allowing for quicker adaptation to changes in business management.

The current developments with respect to object-technology are outlined below.

Object-oriented programming
Object orientation started out with the development of object-oriented programming languages, in the early sixties. Many regard Simula, a language developed by the Norwegians Kristen Nygaard and Ole-Johan Dahl, as the first object-oriented language. Simula is meant for the development of simulation software. Others consider Smalltalk as the first truly object-oriented language. In the late sixties, researchers of the Xerox Palo Alto Research Centre developed Smalltalk as the programming language that enabled them to realise the first GUI with a mouse. This GUI by Xerox has served as the basis for all later GUIs such as Apple Macintosh and Microsoft Windows, while Smalltalk is the basis for later developments in the field of object orientation. The object-oriented languages that are now available can be divided into two categories. This first category is that of purely object-oriented languages, fully based on the object paradigm. The most important of these is Smalltalk.
The second category consists of extensions to existing languages. The most important of these is C++, an extension of the programming language C, developed by Bjarne Stroustrup. C++ is clearly built as a shell around C. This allows the programmer to still include C code in his C++ programmes. In a language such as Smalltalk it is not possible to switch between object-oriented programming and conventional programming. C++ is therefore not considered to be a purely object-oriented language. At the present time, C++ is most used for object-oriented programming.

One of the best things about object-oriented languages is the fact that they allow for a great deal of re-use of existing object definitions (classes) in new applications. The basic component for the construction of an application is no longer a line of code in a programming language, but a class that defines an object. The classes are contained in a so-called class library. The main task of the programmer is to search the class library and construct his applications from existing classes. Only when he requires an object with a functionality that does not yet exist, will he have to specify a new class.
An object-oriented language gives developers the possibility to create applications with a higher level of building blocks. This can be compared to building a house from building blocks. Creating an application in a conventional language works like building a house from separate components such as bricks and tiles. In an object-oriented language, the classes can be defined in such a way that application building works like building a house from pre-fabricated (pre-fab) building blocks. In a manner of speaking, the class library contains the pre-fab walls, floor parts and roofs, from which the developer can construct the application like a pre-fab house.

Class definition in object-oriented languages is facilitated by the possibility of inheritance. The classes are defined hierarchically. Classes that are lower in the hierarchy inherit the properties of the classes higher up in the hierarchy. This means that a class basically contains the same methods as the class immediately above it in the hierarchy. The developer can change this by giving the lower class its own definition for a certain method or by not letting the class use the method. He can also add new methods to classes.
For example, all classes must contain a method for printing. The class highest in the hierarchy contains the method 'print'. The lower classes all inherit this method, but they will often have their own way of handling it.
An important application of inheritance is that of generalisation and specialisation. This means that a hierarchy of related objects is defined, for example 'floor parts' for a CAD application for houses. First, a class is defined containing the generic properties of floor parts. Underneath, classes of special floor parts are defined. The lower classes inherit the generic properties and the developer adds extra methods and data for the specific properties of the special floor parts. The result is a hierarchy of floor parts. For each object-oriented language you can buy special class libraries for specific application domains. These are called frameworks. There are frameworks for GUIs, for example.

The developer must have sufficient knowledge of the domain for which he is building applications. Only then will he be able to define a framework in advance, containing the right classes from which he can construct the application. Classes in frameworks usually define complex objects that in turn use more elementary objects from the class library of the object-oriented language. The relationship between the complex object and the elementary object is similar to the relationship between a wall and the stones it is made up of.

With a good framework of classes for a specific area, the developer not only has the advantage of re-use of classes, but also of flexibility of the applications. After all, the applications consist of objects from various classes, that communicate with each other and with the user. Each application is therefore in fact a network organisation of objects. Modifying an application therefore means modifying, adding or removing classes of the objects that are used in the application. This means both a change in the objects used in the application and a change in the way the interaction between the objects is organised.

Because of the features described above, object-oriented programming is highly suitable for certain areas of application. Current applications mainly focus on operating systems, graphical user interfaces, simulation software, drawing tools, Computer Aided Design (CAD), both for product design and product simulation, Computer Aided Software Engineering (CASE), geographical information systems and multimedia applications. Currently, object-oriented programming is mainly applied for personal computers, workstations and small servers and hardly for business applications on mainframes.

Object orientation and system development
Object orientation has a great impact on all of system development. Developers have to change their methods and way of working. Facilities such as development platforms, databases, programming languages and operating systems have to be equipped to support object orientation.

Moreover, the change-over to object orientation involves a clean break with the conventional approach to system development, due to the fact that with object orientation, an application is an object consisting of data and functions. Objects are particularly suitable for imitating, designing and simulating business objects and business processes. With objects we are better able to record 'life-like' data on the behaviour of these objects and processes. Objects are also highly suitable for the automated control and execution of business processes.

In the conventional approach, an application is a programme. Programmes can be roughly divided in batch programmes with input files and output files for interfaces, and on-line programmes that have an interface with the user via the monitor. Typical of the conventional approach is the separation between programmes and data. The data the programmes retrieve and edit are stored separately in a common database. This means that programmes are mainly suitable for storing and editing data in databases and for automated data processing, such as keeping the salary records and printing overviews. Conventional applications therefore mainly support the automation of data processing and data storage and only rarely support the imitation, simulation and control of business objects and business processes.

The nature of the applications they design is decisive for the methods of analysis and design system developers use. Looking at the history of conventional applications we see a shift towards data-oriented design.

At first, the business processes were focused on in the design of batch systems. Starting point in this process-oriented design were the data processing business processes that were to be automated. First, the automated process is designed, in the form of programmes, and then the data are designed in the form of files.

Later, when databases and on-line applications start to grow, developers are switching to data-oriented design. Now, the starting point is formed by the business data people want to store in the information system. The aim of such systems is to improve the data management of the company. First, the business data are modelled in a data model. The data model consists of entities relating to business objects and business processes about which we want to record data. On the basis of the data model, the database is designed, in which the data are stored. Then the applications are designed, on-line programmes with which the user can modify and retrieve the data. Existing and new batch programmes also start to use data in the database.

Object orientation means that developers have to use different starting points. In this new approach, the starting points for the analysis are business objects and business processes, which are modelled as data objects for the information system. The data object contains the data people wish to store, the functions they want to perform and the interfaces with other data objects and with the user. If the object has an interface with the user, this also involves designing the presentation to the user and designing the functions, the tools with which the user can modify the object. The design then focuses on realising the data objects as classes in an object-oriented language.

An object-oriented system can be used for more than just data management. It is suitable for the management and the use of objects that together form the applications the user works with. The way in which objects collaborate in an application matches the concept of network organisations of people and companies. In such network organisations, people and companies have a certain degree of autonomy and work together in different forms of co-operation.
In an information system, objects also have a certain degree of autonomy, since they all are independent units of data, functions and interfaces with other objects and users. Their autonomy depends on the extent to which they control their own functions. Each application can be considered a collaboration of several objects.

As yet, there are only few development tools that support the development of object-oriented applications. At the present time, suppliers of CASE tools are in the process of adding object-oriented extensions to their products. This mainly concerns the support of object-oriented analysis and design. For programming, specific development tools of certain object-oriented languages are used. There is a limited availability of integrated object-oriented development platforms supporting analysis, design and programming of object-oriented applications.

Databases and operating systems for objects
Only few object-oriented database management systems exist in which objects can be stored. There is a great need for systems to make it possible to manage objects in object bases the way data are now managed in databases.
The name object-oriented DBMS (OODBMS) is actually wrong. One should rather speak of an Object Base Management System (OBMS) or an Object Storage System. An OBMS can be regarded as a programme (an object, in terms of object orientation) that manages an object parking lot. The OBMS parks objects that are not currently active in the computer memory, in an external storage medium such as a magnetic disk. The OBMS stores the data of each object with a reference to the object's functions. The functions of the objects are stored separately as small programmes.
Users can consult the OBMS and 'open' objects. The OBMS loads the object's data and the functions for the presentation of the object in the computer memory and starts the function. The object appears on the screen and the user can give commands for the other functions of the object via his workstation. The OBMS will then also load and execute these functions. When the user 'closes' the object, the OBMS stores the data of the object in the external medium again.
An object a user is working with can also make requests of other objects. In such cases, the OBMS will also open those objects and execute the required functions.

As we can see, the OBMS performs the tasks of a DBMS - storing data in and retrieving them from a database - as well as those of an operating system - loading and starting programmes from a programme library. A good OBMS is therefore always an operating system as well. Such an integration of an operating system, a programme library and a DBMS into an OBMS in not available as yet. The OBMSs that are available now, such as Gemstone and ONTOS, are less suitable for business applications that have to meet stiff demands as to security and reliability. Important DBMS suppliers such as Oracle and IBM are in the process of supplying their DBMSs with object-oriented extensions. This type of object-oriented databases uses the management an security facilities of the underlying relational DBMS, which makes them better equipped for business applications.

4.4.3 Summary

There is a clear trend towards an increasing use of object orientation in system development. Suppliers of package software as well as developers of custom applications are using more and more object orientation. The reason for this is found in the clear advantages offered by object orientation compared to the conventional approach with its separation of programmes and data.
Application building according to the object paradigm still has some limitations. These are expected to be resolved within the next five years, by the further development and simplification of object technology. The use of object orientation and the developers' experience with it will therefore increase rapidly.
Finally, the main advantages and limitations of object orientation are briefly mentioned below.

Advantages
Simulation of the real world
With object orientation, we are able to simulate the looks and the behaviour of processes and objects in the real world. The user is thus presented at his workstation with a familiar reality and he is optimally supported in all his activities.

Flexibility
With object orientation, an application is in fact a collection of collaborating objects. This gives the user a great flexibility.

Adaptability
The relationships between data objects in the information system and objects and processes in the real world simplifies the modification of applications.

Re-use
Flexibility and adaptability are reinforced by the possibility to re-use existing classes (object definitions) in new applications.

Limitations
Insufficient availability of object technology
For the application of object orientation in a proper sense, object-oriented database management systems, operating systems and management tools must become available, preferably integrated into one object base management system.

Insufficient standards
There are insufficient standards with respect to object orientation. An important organisation in this field is the Object Management Group (OMG), who are currently in the process of defining the Common Object Request Broker Architecture. Most important in this CORBA standard is the Object Request Broker, a function that supports the communication between objects in distributed applications.

Connection to existing applications
Currently, there are vast numbers of conventional applications that do not adhere to the principles of object orientation. Moreover, object orientation is mainly applied on personal computers and workstations, and not on mainframes. This is the reason for the emerging of hybrid forms of object-oriented and conventional system development.

Lack of experience among developers
Developers as yet have insufficient experience with object orientation.

Advantages only in the long run
Companies have to invest to be able to apply object orientation. The advantages of object orientation, such as more flexible and better adaptable applications and lower costs of development because of re-use, will only be noticed in the long run. First, enough re-usable object definitions must be available for new applications and enough existing applications have to be converted into object-oriented applications.