Abstract
The concept of objects and instances in computing had its first major breakthrough with the PDP-1 system at MIT which was probably the earliest example of capability based architecture. Objects as programming entities were introduced in the 1960s in Simula 67, a programming language designed for making simulations, created by Ole-Johan Dahl and Kristen Nygaard of the Norwegian Computing Center in Oslo. George T. Heinemann and William T. (2001).
The idea occurred to group the different types of ships into different classes of objects, each class of objects being responsible for defining its own data and behavior.) Such an approach was a simple extrapolation of concepts earlier used in analog programming. On analog computers, such direct mapping from real-world phenomena objects to analog phenomena objects (and conversely), was (and is) called ‘simulation’. Simula not only introduced the notion of classes, but also of instances of classes, which is probably the first explicit use of those notions. George T. Heinemann and William T. (2001).
The Smalltalk language, which was developed at Xerox PARC in the 1970s, introduced the term Object-oriented programming to represent the pervasive use of objects and messages as the basis for computation. Smalltalk creators were influenced by the ideas introduced in Simula 67, but Smalltalk was designed to be a fully dynamic system in which classes could be created and modified dynamically rather than simply using static ones as in Simula. The ideas in Simula 67 were also used in many other languages, from derivatives of Lisp to Pascal. Object-oriented programming developed as the dominant programming methodology during the mid-1990s, largely due to the influence of C++. George T. Heinemann and William T. (2001).
Its dominance was further cemented by the rising popularity of graphical user interfaces, for which object-oriented programming is well-suited. An example of a closely related dynamic GUI library and OOP language can be found in the Cocoa frameworks on Mac OS X, written in Objective C, an object-oriented, dynamic messaging extension to C based on Smalltalk. OOP toolkits also enhanced the popularity of event-driven programming (although this concept is not limited to OOP).
Some feel that association with GUIs (real or perceived) was what propelled OOP into the programming mainstream. At ETH Z, Niklaus Wirth and his colleagues had also been investigating such topics as data abstraction and modular programming. Modula-2 included both, and their succeeding design, Oberon, included a distinctive approach to object orientation, classes, and such Object-oriented features have been added to many existing languages during that time, including Ada, BASIC, Lisp, FORTRAN, Pascal, and others. Adding these features to languages that were not initially designed for them often led to problems with compatibility and maintainability of code. Mira Mezini and Klaus Ostermann (2002).
In the past decade Java has emerged in wide use partially because of its similarity to C and to C++, but perhaps more importantly because of its implementation using a virtual machine that is intended to run code unchanged on many different platforms. This last feature has made it very attractive to larger development shops with heterogeneous environments. Microsoft’s.NET initiative has a similar objective and includes supports several new languages, or variants of older ones. More recently, a number of languages have emerged that are primarily object-oriented yet compatible with procedural methodology, such as Python and Ruby.
Besides Java, probably the most commercially important recent object-oriented languages are Visual Basic.NET and C# designed for Microsoft’s.NET platform. Just as procedural programming led to refinements of techniques such as structured programming , modern object-oriented software design methods include refinements such as the use of design patterns , design by contract , and modeling languages (such as UML ). Mira Mezini and Klaus Ostermann (2002).
Introduction
Object-oriented programming roots reach all the way back to the 1960s. As hardware and software became increasingly complex, researchers studied how software quality could be maintained. Object-oriented programming was deployed in part as an attempt to address this problem by strongly emphasizing discrete units of programming logic and re-usability in software. The Similar programming language was the first to introduce the concepts underlying object-oriented programming (objects, classes, subclasses, virtual methods, coroutines, garbage collection, and discrete event simulation) as a superset of Algol.
Simula was used for physical modeling, such as models to study and improve the movement of ships and their content through cargo ports. Smalltalk was the first programming language to be called “object-oriented”. Object-oriented programming may be seen as a collection of cooperating objects, as opposed to a traditional view in which a program may be seen as a group of tasks to the computer (“subroutines “).
In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent little machine with a distinct role or responsibility. The actions or “operators ” on the objects are closely associated with the object. For example, in OOP, the data structures tend to carry their own operators around with them (or at least “inherit” them from a similar object or “class”). The traditional approach tends to view and consider data and behavior separately. White Paper, Microsoft Corporation, 2001.
Encapsulation
Constructing applications
Application development in the component world involves three categories of development: designing and developing component implementation and constructing applications. We focus on the latter constructing application components and applications using a component framework and a suite of existing components. Mira Mezini and Klaus Ostermann (2002).
Designing a good component involves considering several factors, including appropriate encapsulation, clean interfaces appropriate granularity of functionality, appropriate balance of specificity and reusability, and completeness of functional coverage. The developers responsible for creating the component must understand the component framework as well as the required component behavior. The test design of the individual components is the most straightforward of these activities. If the component is designed properly, the interfaces should be simple and completely specified and the behavior should be properly encapsulated.
Although components have potentially altered the desired balance of skills for developers, they have neither radically simplified the task nor radically altered the basic skills and training needed. The skills for component designers and developers parallel those needed for large-scale object oriented design and development. Good objects and components share many design characteristics, such as clean interfaces, functional cohesion, adaptability, and completeness. Similarly, developing these systems requires skills in performance, readability, and extensibility. Mira Mezini and Klaus Ostermann (2002).
Designing and developing good components requires even more insight and vision into the application domain’s needs. It might seem that global systems understanding become less necessary in the component world. However, the issues with emergent behavior demonstrate the need for both a global understanding of the component interactions and a local understanding of individual components’ behavior. White Paper, Microsoft Corporation, 2001.
Functional requirement
A system or software requirement that specifies a function that a system software system or system software component must be capable of performing. These are software requirements that define system behavior that is, the fundamental process or transformation that the system’s software and hardware components perform on inputs to produce out-puts. Contrast with nonfunctional requirement performance requirement: System or software requirements specifying a performance characteristic that a system software system or system software component must possess for example, speed, accuracy, and frequency, external interface requirement: White Paper, Microsoft Corporation, 2001.
A system or software requirement that specifies a hardware, software, or database element with which a system software system or system software component must interface, or that sets forth constraints on formats, timing, or other factors caused by such an interface design constraint (requirements): A software requirement that impacts or constrains the design of a software system or software system component.
Examples of design constraints are physical requirements, performance requirements, software development standards, and software quality assurance (SQA) standards quality attribute (requirement): A requirement that specifies the degree of an attribute that affects the quality that the system or software must possess for example, reliability, maintainability, or usability. White Paper, Microsoft Corporation, 2001.
Requirements specification
In system software engineering, a document that states the functions that software must perform, the required level of performance (speed, accuracy, and so on), the nature of the required interfaces between the software product and its environment, the type and severity of constraints on design, and the quality of the final product, nonfunctional requirement; A software requirement that describes not what the software will do but how the software will do it for example, software performance requirements, software external interface requirements, software design constraints, and software quality attributes. Mira Mezini and Klaus Ostermann (2002).
Object Coupling and Object Cohesion
Engineers have known for centuries that the less any one part of a system knows about any other part of that same system, the better the overall system. Systems whose components are highly independent of each other are easier to fix and enhance than systems where there are strong interdependencies among some or all of the components. Highly independent system components are possible when there is minimal coupling among the components, and each component is highly cohesive. Coupling is a measure of the strength of the connection between any two system components. White Paper, Microsoft Corporation, 2001.
The more any one component knows about another component, the tighter (worse) the coupling is between those two components. Cohesion is a measure of how logically related the parts of an individual component are to each other, and to the overall component. The more logically related the parts of a component are to each other the higher (better) the cohesion of that component. The objects that make up an object-oriented system exhibit object coupling and object cohesion.
Object coupling describes the degree of interrelationships among the objects that make up a system. The more any one object knows about any other object in the system, the tighter (worse) the coupling is between those two objects. To construct systems from objects, we must couple (to some degree) the objects that comprise the system. Mira Mezini and Klaus Ostermann (2002).
Approaching Object-Oriented Technology
Object-oriented technology is both immense and far-reaching. End users of computer systems and computer-based systems notice the effects of object-oriented technology in the form of increasingly easy-to-use software applications and operating systems and in more flexible services being provided by such industries as banking, telecommunications, and cable television. For the software engineer, object-oriented technology encompasses object-oriented programming languages, object-oriented development methodologies, management of object-oriented projects, object-oriented computer hardware, and object-oriented computer aided software engineering, among others. It is not surprising, therefore, that there is some confusion regarding object-oriented terms and concepts. Khaled Khan and Jun Han (2002).
Many of the terms commonly used in object-oriented technology were originally used to describe object-oriented programming (coding) concepts. Specifically, although the terms were borrowed from a non-computer-software perspective, they were first used extensively to describe concepts embodied in object-oriented programming languages, such as Smalltalk, C++, and Eiffel. However, these terms are quite useful even if one never intends to write any software at all.
For example, an industrial modeler could create an object-oriented model of a plastics manufacturing facility. Molding machines, plastic parts, and even the “recipes” (proportional combinations) of the chemicals used to create the various plastics could all be described in object-oriented terms. Further, dynamic and static relationships among these items could also be described in object-oriented terms. Finally, keep in mind that there is no one ultimate set of definitions for object-oriented terms and concepts. Depending on who you are talking to, terms and definitions will vary slightly. Khaled Khan and Jun Han (2002).
References:
George T. Heinemann and William T. (2001); Councill, editors, Component-based Software Engineering. Addison-Wesley.
Khaled Khan and Jun Han (2002). Composing Security-Aware Software. IEEE Software, 19(1):34–41.
Mira Mezini and Klaus Ostermann (2002). Integrating Independent Components with On-Demand Remodularization. In Proceedings OOPSLA 2002, volume 37 of /ACM SIGPLAN.
An Introduction to Microsoft.NET. White Paper, Microsoft Corporation, 2001.