APPENDIX 1

Basic Characteristics of
Object-Oriented Systems

O bject-oriented systems focus on capturing the structure and behavior of information

systems in little modules that encompass both data and process. These little modules are
known as objects. In this appendix, we describe the basic characteristics of object-oriented
systems, which include classes, objects, methods, messages, encapsulation, information
hiding, inheritance, polymorphism, and dynamic binding.1

CLASSES AND OBJECTS

A class is the general template we use to define and create specific instances, or objects.
Every object is associated with a class. For example, all the objects that capture information
about patients could fall into a class called Patient, because there are attributes (e.g., name,
address, birth date, phone, and insurance carrier) and methods (e.g., make appointment,
calculate last visit, change status, and provide medical history) that all patients share (see
Figure A1-1).
An object is an instantiation of a class. In other words, an object is a person, place, event,
or thing about which we want to capture information. If we were building an appointment
system for a doctors office, classes might include Doctor, Patient, and Appointment. The
specific patients, such as Jim Maloney, Mary Wilson, and Theresa Marks, are considered
instances, or objects, of the patient class (see Figure A1-1).
Each object has attributes that describe information about the object, such as a
patients name, birth date, address, and phone number. Attributes are also used to repre-
sent relationships between objects; for example, there could be a department attribute in
an employee object with a value of a department object that captures in which department
the employee object works. The state of an object is defined by the value of its attributes
and its relationships with other objects at a particular point in time. For example, a patient
might have a state of new or current or former.
Each object also has behaviors. The behaviors specify what the object can do. For
example, an appointment object can probably schedule a new appointment, delete an
appointment, and locate the next available appointment. In object-oriented programming,
behaviors are implemented as methods (see the following section).
One of the more confusing aspects of object-oriented systems development is the fact
that in most object-oriented programming languages, both classes and instances of classes
can have attributes and methods. Class attributes and methods tend to be used to model

1 In Chapter 9, we review the basic characteristics of object-oriented systems in more detail.

1
2 Appendix 1 Basic Characteristics of Object-Oriented Systems

Patient
name
address
birthdate
phone
insurance carrier
+make appointment()
+calculate last visit()
+change status()
+provides medical history()
+create()

Jim Maloney: Patient Mary Wilson: Patient Theresa Marks: Patient

FIGURE A1-1
Classes and Objects

attributes (or methods) that deal with issues related to all instances of the class. For example,
to create a new patient object, a message is sent to the Patient class to create a new instance
of itself. However, from a systems analysis and design point of view, we will focus primarily
on attributes and methods of objects and not of classes.

METHODS AND MESSAGES

Methods implement an objects behavior. A method is nothing more than an action that an
object can perform. As such, they are analogous to a function or procedure in a traditional
programming language such as C, Cobol, or Pascal. Messages are information sent to
objects to trigger methods. A message is essentially a function or procedure call from one
object to another object. For example, if a patient is new to the doctors office, the recep-
tionist will send a create message to the application. The patient class will receive the cre-
ate message and will execute its create() method (See Figure A1-1), which then will create
a new object: aPatient (see Figure A1-2).

Patient
name
address
create
birthdate
phone
insurance carrier aPatient

Receptionist +make appointment()

+calculate last visit()
FIGURE A1-2 +change status()
Messages and +provides medical history()
+create()
Methods
 Inheritance 3

YOUR A1-1 Encapsulation and Information Hiding

TURN

Come up with a set of examples of using encapsulation this information? What about personal information that
and information hiding in everyday life. For example, is you would prefer to be private? How would you prevent
there any information about yourself that you would not someone from retrieving it?
mind if everyone knew? How would someone retrieve

ENCAPSULATION AND INFORMATION HIDING

The ideas of encapsulation and information hiding are interrelated in object-oriented systems.
However, neither of the terms is new. Encapsulation is simply the combination of process and
data into a single entity. Traditional approaches to information systems development tend to
be either process centric (e.g., structured systems) or data centric (e.g., information engineer-
ing). Object-oriented approaches combine process and data into holistic entities (objects).
Information hiding was first promoted in structured systems development. The prin-
ciple of information hiding suggests that only the information required to use a software
module be published to the user of the module. Typically, this implies the information
required to be passed to the module and the information returned from the module are
published. Exactly how the module implements the required functionality is not relevant.
We really do not care how the object performs its functions, as long as the functions occur.
In object-oriented systems, combining encapsulation with the information-hiding princi-
ple suggests that the information-hiding principle be applied to objects instead of merely
applying it to functions or processes. As such, objects are treated like black boxes.
The fact that we can use an object by calling methods is the key to reusability because
it shields the internal workings of the object from changes in the outside system, and it
keeps the system from being affected when changes are made to an object. In Figure A1-2,
notice how a message (insert new patient) is sent to an object, yet the internal algorithms
needed to respond to the message are hidden from other parts of the system. The only
information that an object needs to know is the set of operations, or methods, that other
objects can perform and what messages need to be sent to trigger them.

INHERITANCE
Inheritance, as an information systems development characteristic, was proposed in data
modeling in the late 1970s and the early 1980s. The data modeling literature suggests using
inheritance to identify higher-level, or more general, classes of objects. Common sets of
attributes and methods can be organized into superclasses. Typically, classes are arranged in
a hierarchy, whereby the superclasses, or general classes, are at the top, and the subclasses, or
specific classes, are at the bottom. In Figure A1-3, person is a superclass to the classes Doc-
tor and Patient. Doctor, in turn, is a superclass to General Practitioner and Specialist. Notice
how a class (e.g., Doctor) can serve as a superclass and subclass concurrently. The relation-
ship between the class and its superclass is known as the a-kind-of relationship. For example
in Figure A1-3, a General Practitioner is a-kind-of Doctor, which is a-kind-of Person.
Subclasses inherit the appropriate attributes and methods from the superclasses above
them. That is, each subclass contains attributes and methods from its parent superclass.
4 Appendix 1 Basic Characteristics of Object-Oriented Systems

Person
Abstract Classes

Doctor Patient

FIGURE A1-3
General Practitioner Specialist
Class Hierarchy
with Abstract and Concrete Classes
Concrete Classes

For example, Figure A1-3 shows that both Doctor and Patient are subclasses of Person and,
therefore, will inherit the attributes and methods of the Person class. Inheritance makes it
simpler to define classes. Instead of repeating the attributes and methods in the Doctor and
Patient classes separately, the attributes and methods that are common to both are placed
in the Person class and inherited by those classes below it. Notice how much more efficient
inheritance hierarchies of object classes are than the same objects without an inheritance
hierarchy (see Figure A1-4).
Most classes throughout a hierarchy will lead to instances; any class that has instances
is called a concrete class. For example, if Mary Wilson and Jim Maloney were instances of
the Patient class, Patient would be considered a concrete class. Some classes do not produce

Patient Person
name name
address address
birthdate birthdate
phone phone
insurance carrier
+updateBirthDate()
+updateBirthDate()
+updateInsuranceCarrier()

VS.

Doctor
name
address
birthdate Patient Doctor
phone insurance carrier MedicalSchoolSpecialty
MedicalSchoolSpecialty
+updateBirthDate() +updateBirthDate()
+updateBirthDate() +updateInsuranceCarrier()
+updateMedicalSchoolSpecialty() +updateMedicalSchoolSpecialty()

FIGURE A1-4 Inheritance Advantage?

 Polymorphism and Dynamic Binding 5

YOUR A1-2 Inheritance

TURN

See if you can come up with at least three different inheritance hierarchy using the class. Which of the classes
classes that you might find in a typical business situation. are abstract, if any, and which ones are concrete?
Select one of the classes and create at least a three-level

instances because they are used merely as templates for other more specific classes (espe-
cially those classes located high up in a hierarchy). The classes are referred to as abstract
classes. Person is an example of an abstract class. Instead of creating objects from Person,
we create instances representing the more specific classes of Doctor and Patient, both types
of Person (see Figure A1-3). What kind of class is the General Practitioner class? Why?

POLYMORPHISM AND DYNAMIC BINDING

Polymorphism means that the same message can be interpreted differently by different
classes of objects. For example, inserting a patient means something different than insert-
ing an appointment. As such, different pieces of information need to be collected and
stored. Luckily, we do not have to be concerned with how something is done when using
objects. We can simply send a message to an object, and that object will be responsible for
interpreting the message appropriately. For example, if an artist sent the message Draw
yourself to a square object, a circle object, and a triangle object, the results would be very
different, even though the message is the same. Notice in Figure A1-5 how each object
responds appropriately (and differently) even though the messages are identical.
Polymorphism is made possible through dynamic binding. Dynamic, or late, binding
is a technique that delays typing the object until run-time. As such, the specific method that
is actually called is not chosen by the object-oriented system until the system is running.
This is in contrast to static binding. In a statically bound system, the type of object is deter-
mined at compile time. Therefore, the developer has to choose which method should be
called instead of allowing the system to do it. This is why in most traditional programming

aSquare
lf
urse
Yo
w
ra
D

DrawYourself aCircle
D
ra
w
Yo

anArtist
ur
se
l
f

aTriangle
FIGURE A1-5
Polymorphism
6 Appendix 1 Basic Characteristics of Object-Oriented Systems

YOUR A1-3 Polymorphism and Dynamic Binding

TURN

Can you think of any way in which you use polymor- does? Do you always perform the task the same way or
phism and/or dynamic binding in your everyday life? For does the method of performance depend on where you
example, when you are told to do some task, do you are when you perform the task?
always perform the task like everyone else you know

languages we find complicated decision logic based on the different types of objects in a
system. For example, in a traditional programming language, instead of sending the mes-
sage Draw yourself to the different types of graphical objects in Figure A1-5, we would have
to write decision logic using a case statement or a set of if statements to determine what
kind of graphical object we wanted to draw, and we would have to name each draw function
differently (e.g., draw square, draw circle, or draw triangle). This obviously would make the
system much more complicated and more difficult to understand.

KEY TERMS
Abstract classes Encapsulation Object
A-kind-of Information hiding Polymorphism
Attribute Inherit State
Behavior Inheritance Static binding
Class Instance Subclass
Concrete classes Message Superclass
Dynamic binding Method

QUESTIONS
1. What is the difference between classes and objects? 4. What is meant by polymorphism when applied to
2. What are methods and messages? object-oriented systems?
3. Why are encapsulation and information hiding impor- 5. Compare and contrast dynamic and static binding.
tant characteristics of object-oriented systems?

EXERCISES
A. Using your favorite Web search engine, find alterna- port students in finding an appropriate apartment to
tive descriptions of the basic characteristics of object- live in next semester. What are the different types of
oriented systems. objects (i.e., classes) you would want to include in
B. Look up object-oriented programming in Wikipedia. your system? What attributes or methods would you
Write a short report based on its entry. want to include in their definition? Is it possible to
C. Choose an object-oriented programming language, arrange them into an inheritance hierarchy? If so, do
such as C, Java, Smalltalk, or VB.Net, and use the it. If not, why not?
Web to find out how the language supports the basic E. Create an inheritance hierarchy that could be used to
characteristics of object-oriented systems. represent the following classes: accountant, customer,
D. Assume that you have been assigned the task to create department, employee, manager, organization, and
an object-oriented system that could be used to sup- salesperson.