The previous three lessons presented an overview of the two major software development paradigms: the procedural paradigm and the object oriented paradigm. In this lesson, these two paradigms are compared and the relative strengths and weaknesses of each paradigm are addressed. In addition, both paradigms are assessed according to the six software quality characteristics presented earlier.

According to Korson and McGregor [1990], "a design paradigm is characterized by its view of the decomposition process." The decomposition process refers to the way that a given paradigm divides designs into logical units. The procedural paradigm "takes a task-oriented point of view, which begins its support for the design process when a solution to the target problem is proposed. The proposed solution is decomposed by breaking it into a sequence of tasks. These tasks form the basic building blocks for a procedural application." This means that the procedural paradigm really only begins after the designer has identified a possible solution. This solution is then decomposed into various logical modules and submodules (functions and procedures) according to the action they accomplish. Once the design is implemented, the execution of the tasks can easily be traced from start to finish.

Earlier the example of sorting a list of numbers was given to illustrate task-based decomposition. The solution to the sorting problem was divided into the following tasks: inputting the numbers, using the selection sort, and outputting the sorted numbers. Then the second task, using the selection sort, was further divided into the tasks of finding the smallest number and swapping two numbers. The diagram to the right shows a representation of the order in which these tasks are performed to sort three numbers.

In contrast to the procedural paradigm, the object oriented paradigm supports the complete software development life cycle from analysis to design to programming. The procedural paradigm only supports the design and programming steps since a potential solution must be specified before task decomposition can begin. The object oriented paradigm circumvents this restriction by providing a comprehensive approach to software development. Rather than taking a task-based view of design, "the object oriented paradigm assumes a modeling point of view. The model is constructed by viewing the problem domain as a set of interacting entities and the relationships between them" [Korson and McGregor 1990]. Entities are modeled by designing classes to represent them and then using these classes to instantiate objects. This approach was demonstrated by the Figure classes in the previous lesson. Relationships between objects are modeled through inheritance and through the communication mechanism of message passing. While programs designed with the procedural paradigm are essentially a sequence of tasks, programs designed with the object oriented paradigm are essentially a set of objects interacting with each other through message passing.

The six software quality characteristics in the table below provide another way for software engineers to assess the pros and cons of the two software development paradigms. By using these characteristics for assessment, software engineers seek to answer the question, "Does this paradigm produce software which is more maintainable, more reliable, more portable, etc.?"


Maintainability 		The ease with which changes can be made to satisfy new requirements or to correct deficiencies.

Correctness 		The degree with which software adheres to its specified requirements.

Reusability 		The ease with which software can be reused in developing other software.

Reliability 		The frequency and criticality of software failure, where failure is an unacceptable effect or behavior occurring under permissible operating conditions.

Portability 		The ease with which software can be used on computer configurations other than its current one.

Efficiency 		The degree with which software fulfills its purpose without waste of resources.

Most software engineers would agree that good object oriented designs are inherently more maintainable. This advantage is due in part to the fact that the object oriented paradigm forces designers to create encapsulated objects. Encapsulation means that the interface of the object is separated from the implementation of the object. Such separation is highly desirable because many parts of the program may depend upon a certain interface. If changes must be made to the interface, then widespread changes will also have to be made to the program. A good object oriented design will minimize the interface changes that must be made. Hence, maintenance is localized to the implementation of a certain object.

Recall that correctness is tested through verification and validation. Verification answers the question "Are we building the software right?" while validation answers the question "Are we building the right software?" [Balci 1998]. Various techniques exist for performing software verification and validation, and these techniques are applicable to both paradigms. However, according to Schach [1998], "the claim that use of the object oriented paradigm reduces the need for testing is largely true." This is due to the fact that inheritance allows the reuse of software that has already been tested. Therefore, the object oriented paradigm can contribute to the development of correct software by reducing the amount of testing that is necessary.

Clearly the object oriented paradigm supports the reuse of software more than the procedural paradigm. While it is clearly possible to reuse modules or subprograms in the procedural paradigm, there is nothing about this approach which requires or even encourages software reuse. In contrast, the object oriented paradigm supports reuse through inheritance. Inheritance itself is reuse, the defining of new classes as extensions of previously defined classes.

Reliability is most likely the result of a good software design rather than a particular development paradigm. Thus, procedural software that is well designed will be just as reliable as object oriented software that is well designed. However, it is important to consider which paradigm lends itself to better designs. If the object oriented paradigm supports the entire development process (analysis, design, implementation), then it might be reasonable to assume that this paradigm will help produce better, more reliable designs. Note, however, that this link is indirect. Using the object oriented paradigm is no guarantee that one's design will be reliable. One final link to consider is that reliability is often measured by the average time it takes to repair a software failure. If object oriented software is truly more maintainable, then it is reasonable to expect this software will be easier to repair and thus more reliable.

Like reliability, portability is not really a function of the paradigm used to created the software. The portability of a software product is affected more by the programming language used to implement the software and the constraints of the hardware platform on which the software runs. Thus the portability of a software product is not greatly influenced by the choice of the software development paradigm.

While the object oriented paradigm provides better support for creating maintainable, reusable, and correct software, it is generally agreed that the procedural paradigm provides better support for software that is execution efficient. Recall that the logic of a procedural program matches the underlying hardware on which the program executes. The software consists of a sequence of logical tasks, and the hardware executes a sequence of logical instructions. In contrast, object oriented software requires more machine instructions to implement inheritance and message passing. Many software engineers feel, however, that the extra execution cost is more than offset by the benefits of more maintainable and more reusable code. And in light of the increasing speed of computer processors, this decrease in execution efficiency is usually negligible.

References