Software Engineering: A Methodical Approach (2014)

PART G. Appendices

Appendix 2. Basic Concepts of Object-Oriented Methodologies

This chapter provides clarification on the fundamental concepts in OOM. Since they form the basis of OO software, it is imperative that the student has a clear understanding of them. The chapter includes the following sections:

· Objects and Object Types

· Operations

· Methods

· Encapsulation and Classes

· Inheritance and Amalgamation

· Requests

· Polymorphism and Reusability

· Interfaces

· Late Binding

· Multithreading

· Perception versus Reality

· Overview of the Object-Oriented Software Engineering Process

· Summary and Concluding Remarks

A2.1 Objects and Object Types

An object is a concept or thing about which data can be stored, and upon which a set of operations is applicable. The concept of an object is similar to that of an entity in the relational model. Here, however, the definition includes possible actions (operations) which may be performed on the object. In the relational model, this is not the case.

Object may be tangible or intangible (conceptual). Examples of tangible objects are:

· A book

· A building

· A chair

· A motor vehicle engine

· A student

· An employee

Examples of abstract (conceptual) objects are:

· A shape in a program for drawing

· A screen with which the user interacts

· An engineering drawing

· An airline reservation

· An employee’s work history

An object may be composed of other objects, which in turn may be composed of other objects and so on.

Example 1:

An object type refers to a group or category of (related) objects. The instances of an object type are the actual objects. An object type differs from an entity (in relational model) in three ways:

· The object type involves encapsulation of data structure and operation.

· This means the use of potentially more complex data structures.

· For an object type, there is an emphasis on inheritance.

Example 2:

It is often the case that the term “object” is used loosely to mean either an instance of an object type, or the object type itself. In such cases, the context should be used to determine what the applicable definition is.

A2.2 Operations

Operations are the means of accessing and manipulating the data (instances) of an object (type). Since the operations are defined on the object type, they necessarily apply to each instance of that object type. If for instance, we define the operations Hire, Modify, Remove, Retire, Fire, Resign, Inquire, Print on an object type, Employee, then for each employee object, these operations are applicable.

Operations of an object type (should) reference only the data structure of that object type. Strict OO design forbids an operation to directly access the data structure any object type other than its own object type. To use the data structure of another object type, the operation must send arequest (message) to that object.

In a truly OO software (CASE or programming language) environment, operations and data of an object type are encapsulated in a class (more on this later). Several quasi OO software development environments exist however, that typically facilitate the creation of a relational database, with an OO GUI sitting on top (we will revisit this concept in appendix 7).

In the absence of an OO software development tool, operations may be implemented as programs (with singular functions), some of which may manipulate a database. Obviously, this is a less desirable situation.

In the spirit of the course (review chapter 12), we may expand the meaning of an operation as described above, to mean a set of related activities. If this is done, then an operation may be implemented as a class consisting of related sub-operations.

A2.3 Methods

Methods specify the way in which operations are encoded in the OO software. Typically, they are implemented as functions and/or procedures, depending on the development software. The ability to create and maintain methods related to classes is one significant advantage of OO-CASE tools (more on this later).

In OO software, methods are stored within classes, each method having its parent class. The methods are accessible to object instances of that class. Static methods are accessible to instances of the host class as well as other classes. In non-OO software, methods translate to procedures and/or functions of application programs.

In environments such as Java, an interface is defined as a collection of service declarations with no implementation. Services that are generic (i.e. applicable to objects of various object types) may be implemented as interfaces. Implementation details are left for the specific objects which utilize such interfaces. We will revisit interfaces later on.

Note Some OOPLs and hybrid languages use other terms for methods. For instance, C++ uses functions and Pascal uses procedures. For the duration of this course, we will continue to use the term method.

Example 3:

A2.4 Encapsulation and Classes

What do we mean by encapsulation, and what is a class? These two concepts are closely related to each other, so that it is difficult to discuss one without reference to the other.

A2.4.1 Encapsulation

Encapsulation is the packaging together of data and operations. It is the result (act) of hiding implementation details of an object from its user. The object type (class) hides its data from other object types and allows data to be accessed only via its defined operations — this feature is referred to as information hiding.

Encapsulation separates object behavior from object implementation. Object implementations may be modified without any effect on the applications using them.

A2.4.2 Class

A class is the software implementation of an object type. It has data structure and methods that specify the operations applicable to that data structure.

In an OO software environment, object types are implemented as classes. In a procedural programming environment, object types are implemented as modules.

Example 4:

Note that even in the absence of an OO software environment, OOSE affects the user interface topology of the system. More significantly, it affects the fundamental design of the software being constructed.

A2.5 Inheritance and Amalgamation

Inheritance and amalgamation are two critical principles of OO methodologies. They both affect code reusability, and by extension, the productivity of the software design and construction experiences. This section briefly examines each principle.

A2.5.1 Inheritance

A class may inherit properties (attributes and operations) of a parent class. This is called inheritance. The parent class is called the super-class or base class; the inheriting class is called the sub-class or child class.

A class may qualify as both a sub-class and a super-class at the same time. Additionally, a class may inherit properties from more than one super-class. This is called multiple inheritances.

Example 5:

As you will later see, multiple inheritances pose potential problems to software implementation. For this reason, it is not supported in some software development environments. It may therefore be prudent to avoid multiple inheritances, depending on the software limitations.

A2.5.2 Amalgamation

An object may be composed of other objects. In OOM, we refer to such an object as an aggregate or composite object. The act of incorporating other component objects into an object is called aggregation or composition. Since this is done through the object’s class, the class is also called an aggregation (or composition) class. Throughout this course, we shall use the term amalgamation to mean an aggregation and/or composition.

Example 6:

A2.6 Requests

To make an object do something, we send a request to that object. The request is conveyed via a message. The message contains the following:

· Object name (of target object)

· Operation

· Optional parameters

· The type of the value the request (service call) returns

In an OO environment, objects communicate with each other by making requests and sending them via messages. The software is designed to respond to messages. Objects respond to requests by returning values and evoking certain operations intrinsic to such objects.

A2.7 Polymorphism and Reusability

An operation or object may appear in different forms; this is referred to as polymorphism. Operational polymorphism may occur in any of the following ways:

· Overriding an inherited operation

· Extending an inherited operation

· Restricting an inherited operation

· Overloading an operation

Overriding: A sub-class may override the features of an inherited operation to make it unique for that sub-class.

Extending: A sub-class may extend an inherited operation by adding additional features.

Restricting: A sub-class may restrict an inherited operation by inhibiting some of the features of the inherited operation.

Overloading: A class may contain several versions of a given operation. Each version (implemented as a method) will have the same name but different parameters and code. Depending on the argument(s) supplied when the operation is invoked, the appropriate version will run.

Example 7:

Polymorphism presumes inheritance; polymorphic objects and/or methods can be defined only within the context of an inheritance hierarchy. However, note that the converse does not necessarily hold: inheritance does not necessarily mean that polymorphism is in play.

The most powerful spinoff from inheritance and polymorphism is reusability of code. Reusability may occur in any of the following ways:

· A method (or data structure) is inherited and used by a subclass

· A method is inherited and extended in a sub class

· A method is inherited and restricted in a sub class

· A method is copied and modified in another method

Note Reusability and polymorphism are not miracles; they must be planned. Reusability of classes may span several systems, not just one. To this end, class libraries are of paramount importance. The OO-CASE tool should therefore support class libraries.

A2.8 Interfaces

An interface is a class-like structure with the following exceptions:

· The data items of an interface are constants only.

· The interface contains method signatures only.

The idea of an interface is to promote polymorphism and facilitate a safe alternative to multiple inheritances. Polymorphism is achieved when different classes implement (a term used for interfaces instead of inherit) the interface and override its methods (rather, method signatures). Multiple inheritances occur when a particular class implements several interfaces, or inherits a super-class and implements one or more interfaces.

A2.9 Late Binding

Late binding is the ability to determine the specific receiver (requester) and the corresponding method to service the request at run time. In traditional programming, a procedure or function call is essentially translated to a branch to a particular location in memory where that section of instructions executes. As part of the compilation process, the necessary pieces of the program are put (bound) together before program execution. This process is referred to as (early) binding.

In the object oriented paradigm, no concern is given to which object will request any given service of another object. Further, objects (more precisely classes) are not designed to anticipate what instances of other classes will require their services. There therefore needs to be late binding between a message (request) and the method that will be used to respond to that request.

A2.10 Multithreading

The principle of multithreading has been immortalized by the Java programming language. However, software industry leaders have latched on to the concept, so much so that we now talk about multithreading operating systems, as well as multithreading software applications.

Multithreading is the ability of an object to have concurrent execution paths. The effect is to speed up processing and thereby enhance throughput and hence, productivity. Multithreading is one of the reasons object technology offers better machine performance.

A2.11 Perception versus Reality

Something is said to be transparent if it appears not to exist, when in fact it does. For example, calculations, cross-linking of data, procedures for methods, etc., should be transparent to the user.

Something is said to be virtual if it appears to exist, when in fact, it does not. A good example of this concept is the underlying code that facilitates the OO concept. We are making the computer (software) behave like humans do, as opposed to the traditional approach of thinking like the computer.

Methods are not actually stored in each object —this would be wasteful. Instead, the software examines each request that refers to an object, and selects the appropriate methods (code) to execute. The method is part of the class (or a higher class in the hierarchy), not part of the object. Yet the software gives the illusion that they are, thus creating a virtual environment for the user.

A2.12 Overview of the Object-Oriented Software Engineering Process

Software is constructed using one of two approaches:

· The function-oriented approach

· The object-oriented approach

The function-oriented approach is the traditional approach, based on a life cycle model. The software system passes through several distinct phases, as summarized by the software development life cycle (SDLC):

The object oriented approach is the contemporary approach to software construction. The software system passes through phases which are integrated by a standard set of techniques and representations, as summarized by the following revised SDLC:

There are two significant advantages of this revised SDLC over the traditional one:

· In the traditional approach, the symbols used in representing the system requirements vary with the different phases, thus presenting the possibility for confusion. In the OO approach, the symbols used are consistent throughout the entire engineering process. The risk for confusion is therefore minimized.

· In the OO approach, there is no need for a distinction between the design phase and development phase. This is particularly true if an OO-ICASE tool is employed. The combination of analysis and design activities in the OO paradigm constitutes system modeling, which often results in the automatic generation of code (typically in an OOPL) which can then be accessed and modified.

Software construction via the OO paradigm is an integrated, pragmatic approach, which is very exciting and rewarding. It is hoped that you will catch this excitement and be part of the software revolution.

A2.13 Summary and Concluding Remarks

Here is a summary of what we have covered in this chapter:

· An object type is the term used to describe a family of like objects. The object type defines the data items and operations that can be applied to objects of that family. An object is a concept of thing about which data can be stored and upon which certain operations can be applied. Each object is an instance of the object type that it belongs to.

· An operation is a set of related activities to be applied to an object. Operations are implemented as methods or classes with related methods. A method is a set of related instructions for carrying out an operation.

· A class is the implementation of an object type or an operation. It encapsulates the structure (i.e. data items) and methods for all instances of that class.

· In an OO environment, objects communicate with each other by making requests and sending them via messages.

· An object inherits all the properties (attributes and methods) of its class. A sub-class inherits properties from a super-class. A class may qualify as both a sub-class and a super-class at the same time. A class may also inherit from multiple super-classes.

· Polymorphism is the act of an operation or object behaving differently in different circumstances. It is implemented via method overriding, method extension, method restriction and method overloading.

· An interface is a class-like structure that consists of constants and/or method signatures only. It facilitates polymorphism and a safe alternative to multiple inheritances.

· Late binding is the ability to determine the specific receiver (requester) and the corresponding method to service the request at run time.

· Multithreading is the ability of an object to have concurrent execution paths. The effect is to speed up processing and thereby enhance throughput and hence, productivity.

· Something is transparent if it appears not to exist, when in fact it does. Something is virtual if it appears to exist when in fact, it does not.

· With the introduction of OOM, the SDLC has been simplified and more reliable software products can be constructed.

The next chapter starts the process of delving deeper into OOM. The approach employed in this course is top-down: We will start by looking at the organization as a large complex object type, then work downwards into the details.

A2.14 Recommended Readings

[Lee, 2002] Lee, Richard C. and William Tepfenhart. Practical Object-Oriented Development With UML and Java.Upper Saddle River, New Jersey: Prentice Hall, 2002. See chapters 1 and 2.

[Lethbridge, 2005] Lethbridge, Timothy C. and Robert Laganiere. Object-Oriented Software Engineering 2^nd ed. Berkshire, England: McGraw-Hill, 2005. See chapter 2.

[Martin, 1993] Martin, James and James Odell. Principles of Object Oriented Analysis and Design. Englewood Cliffs, New Jersey: Prentice Hall, 1993. See chapter 2.