Object-oriented (OO) software engineering has taken the software world by storm. Although the original concept harkens back to the early 1970s, OO tech- nologies, methods and languages have become cen- tral to modern software engineering thinking.
Unfortunately, OO has also been accompanied by a fair amount of hype ... not to mention a new jar- gon, new programming languages, and most impor- tantly, a new way of thinking about the way we ana- lyze, design, code, and test computer programs.
In this ESE module, we'll explore the basic con- cepts that underlie OO thinking. In later modules, we'll discuss the analysis and design methods that bring some discipline to the OO mind set and the issues that must be considered before you undertake the OO approach.
Object-oriented software engineering requires a dif- ferent mind set. At the core of object-oriented think- ing are a number of key concepts: classes, objects, attributes operations, messages, and a pivotal idea that we call inheritance.
The following excerpt has been adapted from
Software Engineering: A Practitioner's Approach and discusses the conceptual foundation for OO thinking.
As the 1980s came to a close, the object-oriented paradigm for software engineering began to mature into a practical and powerful approach for software development. We cre- ated designs for applications of all kinds and used an object-oriented mindset to get the job done. We implement- ed (coded) programs using object-oriented programming languages and techniques.
Today, object-oriented analysis (OOA) and objectoriented design (OOD) are making slow but steady progress as software engineering methods in their own right. Instead of examining a problem using the classic input-processing- output (information flow) model or a model derived exclu- sively from hierarchical information structures, OOA and
OOD introduce a number of new concepts. These new con- cepts seem unusual to many people, but they are really quite natural. Goad and Yourdon [1] consider this issue when they write:
OOA--object-oriented analysis--[and OOD] is based upon concepts that we first learned in kindergarten: objects and attributes, classes and members, wholes and parts. Why it has taken us so long to apply these concepts to the analysis and specification [and design] of information systems is anyone's guess--perhaps we've been too busy "following the flow" during the heyday of structured analysis to con- sider the alternatives.
It is important to note that there is no universal agree- ment on the concepts that serve as a foundation for OO thinking. But a limited number of key ideas appear repeat- edly, and it is these that we will consider here.
Object-Oriented Concepts
Any discussion of OOA and OOD must begin by address- ing the term object-oriented. What is an object-oriented viewpoint? Why is a method considered to be object-ori- ented? What is an object?
To understand the object-oriented point of view, con- sider an example of a real world object--the thing you are sitting in right now--a chair. Chair is a member (the term instance is also used) of a much larger class of objects that we call furniture . A set of generic attributes can be associat- ed with every object in the class furniture . For example, all furniture has a cost , dimensions , weight , location, and color, among many possible attributes. These apply whether we are talking about a table or a chair, a sofa or an armoire. Because chair is a member of the class furniture , chair inherits all attributes defined for the class. This con- cept is illustrated schematically in Figure 1.
Once the class has been defined, the attributes can be reused when new instances of the class are created. For example, assume that we were to define a new object called chable (a cross between a chair and a table) that is a mem- ber of the class furniture. Chable inherits all of the attribut- es of furniture.
We have attempted an anecdotal definition of a class by describing its attributes, but something is missing.

51.2 ·Essential Software Engineering
Every object in the class furniture can be manipulated in a variety of ways. It can be bought and sold, physically mod- ified (e.g., you can saw off a leg or paint the object purple) or moved from one place to another. Each of these operations (other terms are services or methods) will modify one or more attributes of the object. For example, if the attribute location is actually a composite data item defined [using the data dictionary notation introduced in ESE Module 3-3, part III] as: location = building + floor + room then an operation named move would modify one or more of the data items ( building , floor or room ) that comprise the attribute location. To do this, move must have knowl- edge of these data items. The operation move could be used for a chair or a table, as long as both are instances of the class furniture . All valid operations (e.g., buy, sell, weigh) for the class furniture are connected to the object definition as shown in Figure 2 and are inherited by all instances of the class.
The object chair (and all objects in general) encapsulates data (the attribute values that define the chair), operations
(the actions that are applied to change the attributes of chair), other objects, constants (set values), and other relat- ed information. Encapsulation means that all of this infer- mation is packaged under one name and can be reused as one specification or program component.
Now that we have introduced a few basic concepts, a more formal definition of object-oriented will prove more meaningful. Goad and Yourdon [1] define the term this way: object-oriented = objects + classification + inheritance + communication.
Three of these concepts have already been introduced. We will postpone a discussion of communication until later.
[1] Goad, P. and E. Yourdon, Object-Oriented Analysis,
Prentice-Hall, 2nd edition, 1991.
Even though we haven't introduced a concrete analysis technique that would provide distinct steps for identifying objects, we'd like you to attempt to identify a set of classes that are relevant to your busi- ness area.
As part of this exercise, answer the following ques- tions and perform the tasks listed.
1.`What major "pieces" of information are processed by your business (or by your products)? What are their attributes?
2. Using these pieces of information as your basis, organize them into a set of classes.
3. Make a list of specific instances for each class that you've defined. (Later we'll learn to call these suclasses.) What distinguishes one instance from another?
4. What methods or operations can be applied to each class?
5. Using a notation like the one shown in Figures 1 and 2 in the reading, represent your classes.
A
OO thinking introduces many new terms for those soft- ware engineers who are used to thinking with an IPO
(input, process and output) mindset. Yet the con- cepts that form the basis for OO are very natural.
We live in a world of objects. We classify almost everything, from flowers to mammals, from automo- biles to computers. We describe things by enumerat- ing their attributes. For example, how would you describe a house? Attributes like architectural style, location by town and street, size in square feet, num- ber of floors, and number of rooms are a natural way to proceed. We communicate via messages (e.g.,

Object-Oriented Concepts 5-1.3
speech, e-mail, fax, letters, telephone). In short, human beings are very object-oriented!
The following excerpt has been adapted from
Software Engineering: A Practitioner's Approach and presents a discussion of the additional object-oriented concepts.
Attributes describe an object that has been selected for inclusion in the analysis model. In essence, it is the attribut- es that define the object--that clarify what is meant by the object in the context of the problem space. For example, if we were to build a system that tracks baseball statistics for professional baseball players, the attributes of the object player would be quite different than the attributes of the same object when it is used in the context of the profession- al baseball pension system. In the former, attributes such as name, position, batting average, fielding percentage, years played, games played might be relevant. For the latter, some of these attribute would be meaningful, but others would be replaced by attributes such as average salary, credit toward full vesting, projected monthly benefit, mail- ing address, etc.
To develop a meaningful set of attributes for an object, an analyst can study the processing narrative (or statement of scope) for the problem and select those things that rea- sonably "belong" to the object. In addition, the following question should be answered for each object: "What data items (composite and/or elementary) fully define this object in the context of the problem at hand?"
To illustrate,let's consider a home security system called SafeHome. The homeowner can configure the security system to reflect sensor information, alarm response infer- mation, activation/deactivation information, identification information, and so forth. Using the content description notation defined for the data dictionary [discussed in ESE
Module 3-3, part 3] we can represent these composite data items in the following manner: sensor information = sensor type + sensor number + alarm threshold alarm response information = delay time + telephone number + alarm type activation/deactivation information = master password + number of allowable tries + temp. password identification information = system ID + verification phone number + system status
Each of the data items on the right of the equal sign could be further defined to an elementary level, But for our pur- poses, they comprise a reasonable list of attributes for the system object.
Defining Operations
An operation (also called method or service ) changes an object in some way. More specifically, it changes one or more attribute values that are contained within the object.
Therefore, an operation must have knowledge of the nature of the object's attributes and must be implemented in a manner that enables it to manipulate the data structures that have been derived from the attributes.
Although many different types of operations exist, they can generally be divided into three broad categories:
(1) operations that manipulate data in some way (e.g., adding, deleting, reformatting, selecting); (2) operations that perform a computation; (3) operations that monitor an object for the occurrence of a controlling event.
As a first-cut at deriving a set of operations for the objects of the analysis model, the analyst can again study the processing narrative (or statement of scope) for the problem and select those operations that reasonably belong to the object. To accomplish this, the grammatical parse is again used and verbs are isolated. Some of these verbs will be legitimate operations and can be easily connected to a specific object. For example, from the SafeHome processing narrative might indicate that "sensor is assigned a number and type" or that "a master password is programmed for arming: and disarming· the system." These two phrases indi- cate a number of things:
 that an assign operation is relevant for the sensor object;
 that a program operation will be applied to the system object;
 that arm and disarm are operations that apply to sys- tem (also that system status may ultimately be defined
(using data dictionary notation) as system status = [armed | disarmed]
Upon further investigation, it is likely that the operation program will be refined into a number of more specific suboperations required to configure the system. For exam- ple, program implies: specifying phone numbers, configur- ing system characteristics (e.g., create the sensor table, input alarm characteristics), and inputing password(s). But for now, we specify program as a single operation.
In addition to the grammatical parse, we can gain additional insight into other operations by considering the communication that occurs between objects. Objects com- municate by passing messages to one another. Before con- tinuing with the specification of operations, we explore this matter in a bit more detail.
Inter-Object Communication
Defining objects within the context of an analysis model may be enough to lay a foundation for design. But some- thing else must be added (either during analysis or during design) so that the system can be built--a mechanism for communication must be established between objects. This mechanism is called a message.

5-1.4 Essential Software Engineering
Finalizing the Object Definition
The definition of operations is the last step in completing the specification of an object. Operations can be culled from a grammatical parse of the processing narrative for the sys- tem. In essence, a description of the problem domain is parsed and all nouns and verbs are isolated. Verbs repre- sent candidate operations and nouns are potential objects.
Additional operations may be determined by considering the "life history" [2] of an object and the messages that are passed among objects defined for the system.
The generic life history of an object can be defined by recognizing that the object must be created, modified, manipulated or read in other ways, and possibly deleted.
The use of messages is illustrated schematically in
Figure 1. Four objects, A , B , C , and D communicate with one another by passing messages. For example, if object B requires processing associated with operation op10 of object D , it would send D a message that would contain the message of the form:
For the system object, this can be can be expanded to reflect known activities that occur during its life (in this case, dur- ing the time that SafeHome is operational). Some of the operations can be ascertained from likely communication between objects. For example, sensor event will send a message to system to display the event location and num- ber; control panel will send a reset message to update sys- tem status (an attribute); the audible alarm will send a query message; the control panel will send a modify mes- sage to change one or more attributes without reconfigur- ing the entire system object; sensor event will also send a message to call the phone number(s) contained in the object.
Other messages can be considered and operations derived.
The resulting object definition is shown in Figure 2. message: (destination, operation, arguments) where destination defines the object (in this case, object D ) to receive the message, operation refers to the operation that is to receive the message ( op10 ) and arguments pro- vides information that is required for the operation to be successful. As part of the execution of op14 object D may send a message to object C of the form: message: ( C , op08 , <data>)
C finds op08 , performs it and then returns control to D .
Operation oplO completes and control is returned to B .
Cox [1] describes the interchange between objects in the following manner:
An object is requested to perform one of its operations by sending it a message telling the object what to do. The receiver [object] responds to the message by first choosing the operation that implements the message name, execut- ing this operation, and then returning control to the caller.
A similar approach would be used for each of the objects defined for SafeHome. After attributes and opera- tions are defined for each of the objects defined to this point, the beginnings of an OOA model has been created.
Messaging is important to the implementation of an object- oriented system, but it need not be considered in detail during requirements analysis. In fact, our only concern at this stage is to use the concept to help determine candidate operations for a specific object.
[1] Cox, B., Object-Oriented programming, Addison-
Wesley, 1986.

Object-Oriented Concepts ..
5-1.5
[2] Goad, P. and E. Yourdon, Object-Oriented Analysis,
Prentice-Hall, 2nd edition, 1991.
Given the information that you developed in Exercise
5-1.
1. List some of the messages that may be required to enable the objects you defined to communicate with one another.
2. Use the template for messages message: (destination, operation, arguments) to describe each of the messages that you listed in
Task 1.
3. (Optional) For each of the classes you defined, develop a life history. That is, how do the objects change as time passes? What behavior (events) cause the objects to change?
4. Review your results with a colleague.
This post-test has been designed to help you assess the degree to which you've absorbed the information presented in this ESE Module.
Object-Oriented Concepts
1. In the context of OO, a class is a: a. template b. pattern c. generalized description d. all of the above e. none of the above
2. A class encapsulates: a. data and operations b. data and attributes c. attributes and polymorphism d. data structures e. none of the above
3. A class accomplishes information hiding by: a. eliminating all data from the class definition b. allowing access to data to occur only through operations or methods c. allowing access to the class to occur only under constrained circumstances d. eliminating any access to the class by outside objects
4. An operation will most often change: a. an attribute b. a class c. an object d. a message
5. Instantiation results in: a. a metaclass b. values being assigned to attributes c. operations being invokes d. messages being passed e. none of the above
6. A major benefit that results as a consequence of inheritance is: a. the ability to reuse classes b. the ability to set up module libraries c. the ability to use an OO database d. the ability to manage projects more effectively

51.6 ·· Essential Software Engineering
7 An exception in a class hierarchy occurs when: a. three or more levels are exceeded b. an error occurs at one or more levels c. extra attributes or operations are added at one or more levels d. none of the above
8. A method is initiated when : a. a message is received by an object b. a user command is input c. an interrupt is sensed by the OS d. a specific data value is encountered
9. A message is transmitted from: a. attribute to attribute b. object to attribute c. object to object d. class to data
10. Polymorphism is: a. a technique used to process multiple messages b. the ability to use different method names to accomplish the same thing c. the ability to use the same message format to accomplish different things d. the ability to use the same method across different classes
11. Maintenance of OO systems is easier because: a. the decoupled nature of OO system results in much lower defect propagation b. reusable components have higher quality c. fewer lines of code need to be changed d. all of the above e. none of the above
12. A superclass sits: a. at the bottom of a class hierarchy b. outside the class hierarchy c. at the top of a class hierarchy d. none of the above
Copyright 1995 R.S. Pressman & Associates, Inc.
No part of this material may be electronically copied, transmitted, or posted without the express written permission of R.S. Pressman & Associates, Inc.
These materials have been posted on the Local Web
Server of the Department of Computer Science with permission of R.S. Pressman & Associates, Inc. and are for use only by students registered for DCS/235 at
Queen Mary and Westfield College.