• Software Development - An Introduction
• What is Object-orientation
• Abstraction and Modeling
• Objects and Classes
• Relationships between Objects
• Vital Features of Object Oriented Programming Language
• Advantages of OO in Software Development

Software Development - An Introduction

Software design is difficult. It is a delicate balancing act between, on the one hand, producing a highly-efficient solution to the current problem and, on the other hand, producing a more general but possibly less efficient solution to a range of problems. Moreover, software design is of central importance in software development, having a major influence on whether the software system meets its requirements, is reliable and is maintainable. Many software systems currently available fail to fulfill all of their relevant requirements, contain bugs in both their design and implementation and are difficult to maintain.

Object-oriented design and object-oriented programming aim to solve some of the problems when large and complex software systems are being developed. Note that object-oriented design does not necessarily mandate object-oriented programming. An object-oriented design can be implemented successfully by traditional programming languages such as Pascal or C. But it is more convenient and easier to implement an object-oriented design directly in an object-oriented language such as Java or C++, and the resulting code is more likely to be maintainable.

When designing a software system, we should always aim to decompose the system into components or modules that are cohesive and loosely-coupled to one another. A component C is cohesive if C has a single, clearly-defined purpose and it all parts of C make an essential contribution to that purpose. Conversely, C is uncohesive if it has more than one purpose or if parts of C are not essential to that purpose. A system composed of cohesive components tends to be easier to implement and to maintain: if every component has its own distinct purpose, it is easier to locate any necessary changes, such as correcting faults or meeting changing requirements.

Coupling is a measure of the sensitivity of components to changes in one another. Given a component C, another component is loosely-coupled to C if a change in C is not make any significant changes in the other component. Conversely, the other component is tightly-coupled to C if a change in C is likely to entail significant changes in the other component. A system composed of loosely-coupled components tends to be easier to implement and to maintain. Object-oriented design is important because it greatly helps us to design cohesive loosely-coupled components. These components are typically classes.

In this article, we are to see what is all about object-orientation, abstraction and modeling, why object-orientation is advantageous to software and its development etc.

What is Object-orientation

Earlier programming languages like C laid a lot of stress on structure but were still far from representing objects as they exist in the real world. Object-oriented languages, such as C++ and Java, try to model the world more precisely. The term object-oriented has been the source of a good deal of confusion in the computer software industry. Almost every software development environment on the market today claims to be object-oriented. Object orientation means using objects as the base construction block in a system. An object is typically considered to encapsulate data and behavior through methods. A struct in C programming language can contain variables. However this is not sufficient to represent a real-world object like a cricket ball, which has not only state but also behavior. The variables can hold the state the ball is in and other important parameters. But its functionality can not be represented by a struct alone. Though the functions may be put outside the struct, it would make a lot of sense if both the variables and methods representing the functionalities are put together in a single representation, referred to as object. As object-orientation is based on the quality of both the abstraction and modeling tasks achieved, it is necessary to know something about them.

Abstraction and Modeling

Simplification through Abstraction - Every day we are being bombarded with a lot of information through different sources, such as e-mails, voice-mails, broadcasts, telecasts etc. Our five senses alone collect millions of bits of information per day just from our surroundings. Yet we are able to manage to make sense out of all this information. In every day life, we come across a number of things to observe in our living places, work places, and everywhere. In our work environment, we may think that there really are not many things to observe: some furniture, computers, subject books, and colleagues. Still, for each thing that we see, there are a myriad of details to observe: its size, its color, its intended purpose, number of books and computers, where from the computers got imported, etc. Still ahead, each one of these items in turn has details associated with it: the type of material used to make them, the authors of the books, the manufacturers of the computers, the research areas of the colleagues, etc. This clearly tells us that the amount of information to be processed by our brains is truly gigantic and fabulously monstrous. Our brains naturally simplify the details of all what we come across through a process known as abstraction, a process that involves recognizing and focusing on the important characteristics of a situation or object, and filtering out or ignoring all of the unessential details meticulously.

Generalization through Abstraction - If we eliminate enough detail from an abstraction, it becomes generic enough to apply for a wide range of specific situations. Such generic abstractions are quite useful. Thus the simpler an abstraction, that is, the abstraction contains fewer features, the more general it is and it is more versatile and smart to describe a variety of real-world situations and objects. Suppose if an abstraction is more complex, that is, it has accommodated a number of details and features, it can be useful in a fewer situations.

Classification of Abstractions - Though our brains are intelligent enough to abstract concepts and objects quickly and adeptly, there still exist a number of separate abstractions to deal with over our lifetimes. To cope with this aspect of complexity, human beings systematically arrange information into categories according to established criteria. This process is called classification. For example, Yahoo, the famous Web directory, categorizes all the detailed information of objects and things in the Web using some standard formulations and rules. Given clear-cut rules, placing an object into the appropriate category or class is rather straightforward. Thus Yahoo has built up a hierarchy of increasingly more complex abstractions from top to bottom. This process of classification brings out a number of advantages such as searching for a particular object becomes easier and hence the information explosion seems to be highly manageable.

Abstraction in Software Development - When we consider a an information system development project, we typically start by gleaning all the details about the real world situation on which the system is to be based. Mainly we talk to the intended users of the resulting product and this task will supply a summary of those details related with the system's ultimate purpose. This process is more essential since this information acquisition job can not be automated. To include too much detail is to overly complicate the final product, making it that much more difficult to design, program, test, debug, document, maintain and extend in the future.

As with all abstractions, all of our decisions of inclusion versus elimination when building a software system must be made within the context of the overall purpose and domain or the subject matter of focus of the future system. The abstraction must contain the relevant features depending upon the system to be built and its purpose. Once if we have extracted the essential aspects of a situation, we can go for the preparation of a model for that situation. Modeling is the process by which we develop a pattern for something to be made. A blueprint for a custom home, and a cookee cutter are all examples of such patterns. An object model of a software system is such a pattern. Modeling and abstraction are inseparable as a model is a physical or graphical depiction o f an abstraction. That is, we must first determine and bring out an apt abstraction for an object or situation to be modeled.

Abstraction Reusability - Reusability is a very critical phenomena in abstractions also. We have a collection of developed and maintained abstractions from different sources for different domains. Suppose if we need an abstraction for an object, it will be prudent to search for other abstractions by comparing the necessary features and to reuse them towards developing a new abstraction for our intended purpose. This automatically reduces the scale of work and quality will be good. This technique is referred to as pattern matching and reuse. Pattern reuse is a very important technique for object-oriented software development.

Thus abstraction is a fundamental technique that people to perceive the world and plays a very critical and foundational role in software development. Abstraction involves producing a model of the real world.

Objects and Classes

Read-world objects can be further divided into physical objects and conceptual objects. A physical object can be seen, touched and occupy physical space. Some examples of physical objects is computers, books, phones and colleagues that make sense in the general context of a research lab.

A conceptual object is one that can be perceived and represented mentally. In a research lab setting, conceptual objects are such as research discussions and lectures in a research lab environment.

A software object is a software construct that bundles together data (state) and functions (behavior) which represent an abstraction of a real-world (physical or conceptual) object. The data elements used to describe an object are referred to as the object's attributes. An object's attribute values, when taken collectively, are said to define the state, or condition, of the object. An object's behaviors, also known as its operations, represent both the things that an object does to access its data (attributes) and the things that an object does to modify/maintain its data. Thus an object's operations can change its state. In a way, an object's operations are services that can be requested of the object. A method signature consists of a method's name, an optional list of comma-separated arguments (names and types of variables) to be passed to the method enclosed in parentheses and a method's return type. A method can only return one result - a simple data type or a single object reference. If we want to return a list of results through a single method, we can use a special type of object called a collection.

A class is an abstraction describing the common and salient features of all members in a group of similar objects. For example, a class called "Researcher" could be used to describe all researcher objects in a research lab. A class defines the data structure (names and types of attributes) needed to define an object belonging to that class and accommodates the operations (methods) to be performed by such objects including what these operations are, how an object belonging to this class is formally called upon to perform them and what other things an object has to do actually carry them out. Thus a class may be thought of as a template for creating software objects. Whenever we have a class in which one or more of the attributes are themselves references to other objects, that class is called as a composite class.

The term instantiation is used to refer to the process by which an object is created/constructed based upon a class definition. From a single class, we can create as many objects, also referred to as instances, as we like. Classes are different from objects in the following ways: A class defines the attributes (names and data types) that all objects belonging to the class must possess, and the methods that all objects belonging to that class must be able to perform and can be thought of as an empty template. But an object is a filled-in template to which attribute values have been provided.

Encapsulation is a formal term referring to the mechanism that bundles together the state information (attributes) and behavior (methods) of an object into a single logical unit. Thus an object can be thought of as an fortress that guards data, namely the values of all its attributes. We can not directly access the values of an object's privately-declared attributes without an object's permission and knowledge, that is, without using one of an object's publicly accessible to get or set the attribute's value.

Object Interactions - Objects are the building blocks of an object oriented software system. In such a system, objects collaborate with one another to accomplish common system goals. External triggering events may force some objects to react, perform services themselves and/or request services of other objects in chain-reaction fashion, till some overall system goal has been accomplished. Once the ultimate goal of an event chain has been achieved, an application's objects may become effectively idle, waiting for signals from external forces.

If a request is made of an object A and, in fulfilling the request, A in turn requests assistance from another object B, this is known as delegation by A to B. Whenever there is a message passing between an object A and an object B, we can consider the object A to be a client of the object B, because A is requesting or initiating a message that B performs one of its methods as a service to A. Here object B is called as a server or agent. Objects often restrict access to some of their features (attributes). Such restriction is known as information hiding. In a well defined object-oriented application, an object publishes what it can do, that is, the services it is capable of providing, or its method signatures, but hides the internal details both of how it performs these services and of the data (attributes) that it maintains in order to support these services. The term visibility is being used to refer to whether or not a particular feature of an object can be accessed from client code. There are three types of visibilities. They are public visibility, private visibility and protected visibility. Public visibility implies the feature in question may indeed be accessed from client code using dot notation. Private visibility implies that the feature in question may not be accessed via dot notation from client code.

Relationships between Objects

When two objects exchange messages, we call such relationship between objects behavioral relationships, because they arise out of the behaviors, or actions, taken by one object A relative to another object B. With behavioral relationships, object A is either temporarily handed a reference to object B as an argument in a method call or temporarily requests a handle on B from another object C. However the point to be noted here is its temporariness. When A is finished communicating with B, object A often discards the reference to B.

There is also the notion of a more permanent relationship between objects, referred to as structural relationships because, in order to keep track of such a lasting and significant relationships, an object actually has to maintain lasting handles or references on its related objects in the form attributes. The formal name for a structural relationship that exists between classes is an association. An association normally refers to a relationship between classes and the term link is used to refer to a structural relationship that exists between two specific objects (instances). Binary association denotes associations between two different classes. A unary or reflexive association is between two instances of the same class. A ternary association involves three classes.

Aggregation is a special form of association. The relationship here is `contains', 'is composed of ', 'is part of' or 'consists of'. Like an association, an aggregation is used to represent a relationship between two classes A and B. But, with an aggregation, an object belonging to a class A, known as an aggregate class, is composed of, or contains, component objects belonging to a class B.

Inheritance is an another form of relationships existing among the classes. Once we have developed a full-fledged class A, we can use a powerful mechanism for defining a new class by stating only the differences in terms of features between the new class and class A that we have already established. Normally the class A here is called the base class, parent class, superclass or supertype. The new class is a subclass, or a derived class or a subtype of class A. Because subclasses are special cases of their parent class, the term specialization is used to refer to the process of deriving one class from another via inheritance. Generalization is a term used to refer to the opposite process: namely, recognizing the common features of several existing classes and creating a new, common superclass for them all.

Inheritance brings out a number of benefits for object-oriented software development. Inheritance provides succinct derived classes and it supports reusability of code and quality of derived class is excellent as the base class was fully tested. If we have the compiled version of a class, we can derive new subclasses from it without its source code. Finally inheritance supports classification of classes that helps to maintain and extend them.

Inheritance differs from association and aggregation in the following way: Inheritance is a way of describing the properties of a single object. An object is simultaneously an instance of a sub class and all of its superclasses.

Multiple inheritance is a mechanism of designing a subclass by inheriting from two different base classes to get the various characteristics of the two base classes in one single class

Overriding is supplying a different implementation code for a method without making any changes to the signature of that method in the interface. Overloading is a software technique that allows two or more different methods belonging to the same class to have the same name as long as they have different argument signatures. Neither the return type of the method nor the argument names enter into the picture with overloading.

Vital Features of Object Oriented Programming Language

A programming language to be considered truly object-oriented, it has to provide support for three key mechanisms. They are, users-definable abstract data types, inheritance and polymorphism.

Abstract Data Types - Computer programs can be very complex, perhaps the most complicated artifacts ever created by humans. One way to manage and control this complexity is with abstraction. An abstraction of something is a simplified view of it - the abstraction hides the unnecessary details and allows us to focus only on the parts of interest to us. We have many abstractions in our day-to-day lives. We all have an abstract view of how a car works. We know how to interact with it to get it to do what we want it to do. We put in gas, turn a key, press some pedals, and so on. But we need not know what is going on inside the car to make it move. Thus abstraction helps many to go to office or university without knowing the inner details of a car, only the car maker has to know everything.

A computer program can be designed as a set of interacting abstractions. In object-oriented programming, these abstractions are captured. The designer of a class has to know all the details of the class. But once the class is designed, other programmers can use the class without knowing its internal details. They only have to know its interface, just as the driver of a car.

Abstract data types (ADTs) are an important form of program abstraction. An ADT consists of some hidden or protected data and a set of methods to perform actions on that data. When we hide the data in a class, we say that the data have been encapsulated. The implementation of the data, constructors, and methods is normally hidden from a programmer who uses the class. The class acts as a boundary surrounding the constructor, methods and data. By denying other programmers, or even other parts of our program, access to the implementation details, we can safely modify the implementation without worrying that we may inadvertently introduce errors into other code that uses the class. As long as the interface and functionality do not change, the rest of the system should not be affected by changes we make within the class.

Another reason for encapsulation is to preserve the integrity of the data in our class. Direct access to the class data can result in variables not being correctly updated. Access to the data must be through trusted methods of the class. In documenting the interface of an encapsulated class, there is no need to reveal the constants, variables, and methods that programmers can not access. The appearance of the interface becomes uncluttered and helps to improve the documentation of the class.

All programming languages come with a number of built-in, simple data types, such as integer, float, binary etc. An object-oriented programming language supports programmers to define their own complex data types, referred to as classes. These classes are normally called as ADTs. It is called abstract because a class is an abstraction of a real-world object that reflects only its relevant features.

Collections of Objects - A collection is a special type of object that is used to hold and organize other objects. When we have a number of objects, it is better to manage them as a group and operate on them collectively and at times they can be references individually. Collections are implemented as objects so it must be instantiated before they can be first used. Collections are defined by classes that in turn define methods for getting and setting their contents. By virtue of being objects, OO collections are encapsulated and hence take full advantage of information hiding. An array is an simple type of collection. There are a number of sophisticated collection types. An ordered list is similar to an array, in that items can be placed in the collection in a particular order and later retrieved in that same order. Specific objects can also be retrieved based on their position in the list. One distinct advantage of an ordered list over an array is th! at its size does not have to be specified at the time that the collection object is first created; an ordered list will automatically grow in size as new items are being added. The other sophisticated collection types are sorted ordered list, set, and dictionary.

Collections provide a way to overcome the limitation that methods can only return a single result. If we define a method as having a return type that is a collection type, we can hand back an arbitrary sized collection of object references to the client code that invokes the method. In general, collections contain items (either simple data types or objects) which are all of the same type: all integers or all references. However, the power of inheritance steps in to make collections more versatile. If we declare a collection to hold objects of a given supertype, for example, Person, then we can insert into the collection objects explicitly declared to be of type Person or of any of the subtypes of Person. This is due to the 'is a' nature of inheritance.

Polymorphism refers to the ability of two or more objects belonging to different classes to respond exactly to the same message, that is, method call, in different class-specific ways. The primary benefit is that polymorphism simplifies code maintenance.

Abstract Classes If all of the classes that are to be subclasses of a new superclass (through generalization) happen to have defined methods with the same signature, but with different logic, which version of the method, if any, should be propagated up to the parent?. To overcome this issue, the concept of abstract classes came into existence. An abstract class is used to enumerate the required behaviors of a class, without having to provide an explicit implementation of each and every such behavior. An abstract class may contain concrete methods (it contains both a signature and a body). But abstract classes can not be instantiated. An abstract class may be extended to create subclasses. A subclass has to override all of the abstract methods of its abstract super class with concrete methods, otherwise it is again an abstract class.

Interfaces - With an abstract class, we are able to avoid programming the bodies of abstract methods. A set of method signatures, which collectively define what it means to assume a certain role in the grand scheme of an application, is known as an interface. A class has to override all of the method signatures called for by the interface in question to provide them with method bodies. Implementing an interface is therefore virtually the same thing as having to flesh out abstract methods when subclassing an abstract class. The only difference is that with an interface, we typically specify abstract behaviors only, whereas an abstract class specifies a data structure as well as a mixture of abstract and concrete behaviors. So, in terms of the abstractness spectrum, an interface is even more abstract than an abstract class, which is in turn more abstract than a regular class. A static attribute is one whose value is shared by all instances of that class. That is, it belongs to the class as a whole instead of belonging to any one object of that class. Similarly static methods may be invoked on the class as a whole. Static methods may only access static attributes.

Advantages of OO in Software Development

Object-oriented technology holds much promise for software development industry as it has been blessed with a number of proven techniques and tools. Object-oriented technology is based on simulation and modeling. The use of models represents a breakthrough in the way business information systems are being developed. Instead of deploying the traditional application development life cycle, models of a business or business area are constructed. These models are being shared by individual computer applications. Thus a computer application becomes a unique use of the model. The quality of the model is a key determinant of reuse, robustness and adaptability. The model itself must be designed for change. Business processes change and their change is based on using the business model to simulate proposed processes. Modelers can play "what if", run simulations of various process alternatives, and learn from the simulations.

Nowadays the focus of information system shifts from applications development to the enhancement and maintenance of common and vital business models. Business models and software models becomes one and the same. Applications become derivatives, alternate views, and refinements of the business models. The modeling approach to business innovation is not possible without a software approach suited to the task. For these business reasons, object-oriented technology has become a central point to both commerce and industry. Business and technology has be fused if corporations are to maintain the competitive advantage. Object-oriented technology can be the viable foundation for this to happen. Object-oriented technology brings the important concept of change and the management of complexity. Object technology holds great promise as a means of designing and constructing the adaptive information systems needed for this century enterprises.

Objects and object-oriented software development represent a significant shift in systems design. The benefits of object-oriented technology are many. Objects actually tend to model artifacts that exist in the real world. An object may be a user, another computer system, or part of a process. Thus objects can model the real-world objects and can simulate the exact behavior of them. The simulation in turn brings out the invisible knowledge and functionality of these real-world things.

Another important benefit that comes out of object-oriented methodology is reusability of developed software. In the past, software engineers typically paid little or no heed to the work of their predecessors. Each new software system was designed and implemented from scratch. Demand for ever more varied and more complex software systems have made such attitudes untenable. This demand can be fulfilled only if new software projects reuse some of the components designed and implemented for various other projects. This is what we mean by software reusability. Reuse of previously designed and implemented components is commonplace in every branch of engineering. A computer engineer designs a new computer not by redesigning every single component of the computer, but instead by designing some new components and reusing others that are already known to be satisfactory. Here the components are processors, memories, disk drives, screens, keyboards and so on. In the context of software reuse, a component may be a class, or a group of classes or a class with special properties. A component of a software system is most likely to be reusable if it is cohesive and loosely-coupled to other components of that system. Since object-oriented design tends to lead to a system of cohesive, loosely-coupled classes, these classes are likely to be good candidates for reuse in other systems.

As a result of this practice, the time and cost of software development get reduced drastically. The quality and reliability of software thus produced will be higher. With a strong collection of business objects in place, creating a new application will be achieved by integrating them with minimal glue code. Object orientation supports modularity and encapsulation to code.