Home > Articles > Programming

  • Print
  • + Share This
This chapter is from the book

Object Orientation

Much has been written about the object paradigm in the past decade. It has in fact become clear that object orientation has emerged as the dominant paradigm of software engineering. With its roots in the world of program construction, it has more recently become pervasive throughout the software process. We now have object-oriented analysis techniques; design methods; techniques for specification, formal or otherwise; verification and validation; metrics; and much more. There are now even full software process definitions and frameworks such as OPEN (Graham et al., 1997) and RUP (Jacobson et al., 1999) that take an object-oriented perspective. But what is object orientation and why is it important?

Understanding the Object Paradigm

When asked to describe the essence of object orientation, many would present concepts such as classification, inheritance, polymorphic behavior, and reuse. Interesting and important as these concepts might be, they are secondary by-products of object orientation. The essence of object orientation lies elsewhere and relates to how we perceive and model systems, whether they are of a problem, a solution, or an implementation of a solution.

Creating models is therefore central to the construction of object-oriented systems. Most simply stated, a model is a mapping from one domain into another (Ross & Wright, 1992). This means that we cognitively translate what we see as relevant from one environment into another, given a particular purpose and abstraction level. For example, if our purpose is to identify how many chairs there are in a room, then a chair observed in the room may be mapped into the domain of positive integer numbers. If our purpose is to know the colors of furniture in this room then the mapping may be into a constructed set of colors (Allen & Yen, 1979).

Speaking from a cognitive psychology standpoint, a model is what is captured and communicated from our understanding of the situation presented in one domain (often the real world) into another, using a particular language of communication, or a modeling language (Eysenck & Keane, 1990). On this basis, most models (those that attempt to map what is externally perceived through our energy-activated sensory organs) are described as at least a double mapping. The first mapping is from the environment (the real world) into our cognition; that is, forming a mental model (this is also called perception). The second mapping involves using our cognition as a means of creating another model of what it has perceived, this time for the purpose of communicating our perception to others (e.g., a blueprint or an object diagram when used as a medium between the designer and the implementer) or to ourselves at a later time (e.g., a note in our scratch book, or a diagram to remind us of what transpired at the client interview; Eysenck & Keane, 1990; Martin & Odell, 1995). Sometimes, however, the first of these mappings might be absent (e.g., when we attempt to create a model of a Gorgon).

Modeling is therefore closely related to the activities of perception and communication. Consistent with this, and a large number of other definitions (Bruner, 1957; Checkland, 1981; Gibson, 1966; Gregory, 1980; Neisser, 1976; Preece et al., 1995), modeling may be defined as the acquisition, retention, and communication of those views of the situation that are, at the time, relevant to the observer.

In relation to the issue of the various views of "reality" previously discussed, it has also been observed throughout the centuries (Aristotle, 1924; Descartes, 1911; Plato, 1974, 1989) that knowledge of structures, processes, and sequences in which events occur are all necessary for comprehending the real world, which is in turn a prerequisite for modeling some aspect of it. This is of particular relevance when there is an absence of a priori knowledge in terms of the future utility of the model to be constructed. An example may clarify the intention here.

Assume that a model of a system is being created in such a way that we would use it, in the future, to answer questions of this type: Of what is X composed? Given this a priori knowledge of the future use of the model, it is probably sufficient to provide a model that concentrates principally on things that exist in the system (objects) and their interrelationship. These are usually called structural models or object models. If we are interested in how Y is accomplished in this system, then a model that concentrates on inputs, processes, and outputs might be the one of choice. These models are known as process models or more correctly as transformational models. An a priori interest in knowing when or in what sequence we do things would likely lead to a model of states, events, and sequences, which is usually called a dynamic or sequential model.

However in the absence of any a priori knowledge of the intended utility of a model, the modeler has no choice but to provide all three models and clear evidence of their mutual interrelation. This is what we do when we become observers of some situation. Our cognition registers not only objects, but also changes and sequences.

Traditional modeling languages and paradigms of software engineering usually concentrated on one such aspect and were, as such, limited in their ability to yield general models. For example, a data model principally captures the structure of the situation and lacks transformational or causal detail. A flowchart captures the transformational details but lacks important structural and causal detail, and a state diagram or state machine captures sequential information but lacks structure and transformation details.

Object technology combines these three perspectives. In fact, this ability to provide such a rich model that does not depend on any specific modeling view is one of the greatest strengths of object orientation. By capturing and putting together the relevant details of the situation from all three perspectives, object orientation "encapsulates" reality into modules, as we perceive it. In other words the object-oriented paradigm allows us to view the system in terms of elements that our perception is most comfortable with as it (our perception) has also absorbed, encapsulated, and modeled the situation using the same abstractions. This in turn means that the proximity of an object-oriented model and how we actually perceive the world (the system) is maximized. This is the concept of encapsulation, which allows us to perceive objects in the world from the perspective of a given relevance and thus identify all those objects that have these same characteristics. This in turn leads us to the concept of types. Those encapsulations that have from a particular point of relevance the same or similar characteristics can be perceived to belong to the same type. Each member of a type is called an object.

For a system (the world) to operate, its objects have to establish relationships with each other and communicate. This is also the case in an object-oriented model of any reality. This means that as part of the causal model of a situation we identify and decide on those interactions of relevance that give the system of our intent a particular meaning. That is, we extract from the infinite number of interactions possible between objects only those that we perceive as relevant and model those, as we did with the objects themselves. This means that a given object would react to a request by another object that calls on its service. This is the message-passing model, and along with encapsulation, it is the very essence of object orientation.

In fact, we can perceive object orientation as the implementation of the client–server model at the micro (individual object) level. This means that Object A, which has as part of it a service x, might be called by Object B, which needs the service x of Object A. Object B is the client and Object A is the server.

A powerful paradigm, object orientation would bring forth both opportunities and challenges for the software engineering practitioner. The following is a discussion of some of these opportunities.

Comprehensive Model Generation

A well-developed object-oriented model is multidimensional. It depicts the encapsulated and combined structural, transformational, and causal–sequential aspects of the situation being modeled. Given this multidimensionality, it can be argued that an object-oriented model of a particular situation would contain more information than one that is developed along only one of the three dimensions previously mentioned. It stands to reason, therefore, that given the same level of granularity of view and accuracy, the object-oriented model would be capable of answering more questions about the situation modeled than say each of an Entity-Relationship (ER) diagram or a Data Flow Diagram (DFD), a flowchart, or a state machine representation individually. In general, and particularly in terms of the objectives of this book, this quality represents a great advantage because if system functionality should be maximally modeled, then omission of any one of the three dimensions would be an absolute omission that would detract from the information content of the model. We will see later that such an omission can be classified as a defect and is thus of interest to defect management.

This, however, does not mean that object-oriented products are necessarily and invariably of higher quality than their traditionally developed counter-parts just because we can be more comprehensive through the object-oriented process. It does mean that taking an object-oriented approach provides the potential for more information to be available up front and greater ease in communication of information. This in turn would tend to work toward clarity and observability in the project, which can contribute positively to the product quality. Seamlessness

Another great advantage of object orientation is seamlessness. In developing software systems, as mentioned earlier, it is necessary to go through three interrelated activities. The observer or analyst must develop an understanding of the problem situation that is in need of improvement; such an understanding, when acquired, must then be recorded and communicated. A model of the problem situation therefore must be constructed. Once the relevant professionals in the software development process are made familiar with at least a sufficiently large portion of the problem situation (often using the model obtained), it is possible to propose solutions to the problem. The mental images arrived at as a workable solution must then be modeled so they can be communicated with those who have to build the product. This is called a design model. Ultimately, this design has to be constructed in program code. This is a third model, a model of the solution that is executable. Applying the object-oriented paradigm to the development of software systems, we can use the same modeling elements to develop all three of these models. In other words, we use the same abstractions, the same vocabulary, and the same grammar to tell each of the three stories. This is the language of objects, classes, inheritance, aggregation, states, transitions, message passing, and the like. Given the comprehensive nature and multidimensionality of the paradigm, as already discussed, the same language can model all three situations. After all, a model is a model.

Permitting More Complex Systems to Be Constructed

The power of abstraction and the multidimensionality inherent in object orientation has allowed us to tackle more complex and convoluted problem situations than had been possible before. In the absence of object technology, many software applications utilized today, graphical user interfaces, the World Wide Web, and many other products would be out of reach in terms of our ability to provide adequate design models to realize them.

Promoting Distribution

In the object paradigm we model the world in terms of communicating objects. This, as mentioned before, implies the implementation of the client–server model at the very low level of the individual object. This capability, in conjunction with the concept of encapsulation, allows for construction of modules at multiple levels of abstraction (object and class, packages, packages of packages, subsystems, etc.) yet still maintains the message-passing paradigm between these encapsulated abstractions. It is easy to see how such organization would naturally support distribution. In fact, given such an architecture, putting various of these elements in different memory spaces (e.g., different machines) would be a matter of providing the mechanism for locating server objects in remote memory spaces by client objects. In a nonencapsulated system, providing for distribution is far more difficult.

Promoting Reuse

Much has been written about the potential afforded by object orientation in terms of reuse. Understanding the potential for reuse at the code level is easy. Component objects are one form of such reuse. Components are specific, often already compiled individual objects (instances of classes) that are designed and implemented to deliver a very specific service as described by its contract. They are the software equivalent of the integrated circuit (IC) chip. They may be put together, possibly with some additional new objects, to compose an application.

Abstract, often generic, extendible classes arranged in libraries are tools or building blocks to construct an application. They are usually not application oriented (i.e., interrelated to compose an application), but instead are utility oriented (i.e., interrelated, usually hierarchically, to be used across a number of application domains to address a specific type of need). Class libraries are usually passive; they are just a set of classes interrelated through inheritance without any control flow or message passing between them. They do not do anything, but they can be used to build things that do things. Java foundation libraries, graphical user interface (GUI) libraries, and so on, are good examples.

It is possible in object orientation to extend the potential of reuse to beyond just that of code. Analysis and design patterns and application and design frameworks can all arguably be examples of none-code reuse opportunities afforded by the adoption of this paradigm.

It is important to note that reuse, particularly code reuse, has an implication for defect management. Components and class libraries are written by others, often in software process situations that are vastly different from the one used in your organization. Defect management standards other than yours may have been applied in their construction. In short, they may not be at the same level of quality as your product. If they exceed yours, in general, you are winning. If they lag yours, then you must be careful. Additionally, how you interface such products with your home-written software becomes important. For software to be reliably interfaced with the host system it has to have certain characteristics (e.g., it has to have a clearly and correctly defined contract). Such characteristics must be extant if our testing of the adequacy, robustness, and correctness of the interface is to be effective.

Finally, reusable software obtained from a third party might often be used by many organizations other than yours. This affords the opportunity for you to become aware of some of the product's problems and defects without having to discover them yourself. This would have a positive impact on your defect management effort.

On the other hand, some of the challenges that come with the adoption of this paradigm are covered in the following sections.

A Change in Process Is Required

Although the activities to be completed to produce a software system are largely the same irrespective of the paradigm used, how we conduct them is remarkably different. This means that the tasks and techniques utilized are often not those used when producing software in the traditional (nonobject-oriented) fashion. The realization that different tasks and techniques are required is important, but the issue goes deeper than this. There is also a corresponding shift in the proportion of time and effort expended on the different activities. There will be changes on all three dimensions of methodology, technology, and context, and the process will be remarkably different.

A Change in Attitude Is Necessary

With any change in paradigm comes a corresponding necessity to change certain attitudes. The contextual changes necessary in the process are particularly remarkable. There must be an understanding, for instance, that there is likely to be proportionally more time spent on analysis and design and less on coding than in a traditional development environment, particularly initially. There must be a change in attitude in terms of how software engineering staff productivity is evaluated and how they are rewarded. It is important to realize that Rome was not built in a day; it will be some time before the new paradigm is well established and yields positive results of the magnitude expected. New roles are needed (e.g., reuse manager) and some roles might be eliminated.Resource Issues

An important challenge in migrating to the new object paradigm is that of human and technological resources. Obtaining skilled personnel, appropriate tools and technologies, and even training and consulting in the area can be a major challenge.

Defect Management

Abstraction, modularity, and message passing, which are the basic tenets of object orientation, create both opportunities and challenges in defect management of object-oriented systems. We have already alluded to some of the opportunities in preceding sections. In this section I deal with some of the more significant challenges.

The implication of many studies, books, and other works on object technology has been that the use of the paradigm during analysis and design assists with comprehensiveness and completeness and thus drastically reduces the potential for the inclusion of defects of omission from the specification and design. Defects of omission are also usually positively impacted, or so it seems. Thus, it appears that as far as defect management is concerned, the object paradigm has a positive impact on the defect situation during the analysis and design phases and the defect content of analysis and design models. However, research based on data collected by Jones (1997) from several hundred projects states that object-oriented analysis and design have higher defect potential and it is harder to identify and remove defects from object-oriented analysis and design models than it is from traditionally composed design artifacts and models! This finding is counterintuitive and may be related to the differences in how we identify a defect in an object-oriented model as opposed to a non-object-oriented one. Also, it may have to do with the differences in overall maturity of the extant techniques of design defect identification between the two paradigms and possibly even the level of experience of the people completing or evaluating these artifacts who participated in the study. Nevertheless, if independently confirmed using robust empirical research techniques, this finding could somewhat alter the way we look at object technology.

Specifically, abstraction and modularity might assist in clarity and visibility. Encapsulation, the way we arrive at abstraction and modularity in object-oriented systems, thus helps avoid global declarations, amorphous programming, and so on. At the same time, however, it can introduce some challenges. For example, as a consequence of encapsulation, it becomes difficult to examine the current state of an object, a task that must be done easily during testing. Additionally, as control is distributed in an object-oriented system, even if the state of an individual object is obtained and examined, overall system state, being distributed, is hard to examine. Inheritance, a useful by-product of encapsulation, and particularly multiple inheritance, also creates opportunities for defects to escape detection or introduction of defects that are hard to test out. Polymorphic behavior, dynamic binding, and proliferation of interfaces all can contribute to problems in testing object-oriented code.

The first three of these challenges are management issues, the last is both technically and management oriented. It is this aspect that is the focus of our attention in this book.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020