When a large program is to be developed using object orientation, we say that we carry out object-oriented program
development. Object-oriented program development is normally divided into the three different phases of
object-oriented programming.
Basic concepts
Historically, a program has been viewed as a logical procedure that takes input data, processes it, and produces output
data. The programming challenge was seen as how to write the logic, not how to define the data. This way of
understanding is usually called the function-oriented view. The object-oriented view is rather different.
It takes the view that what we really care about are the objects we want to manipulate rather than the logic required to
manipulate them. In this, a computer program is understood to be a kind of a model of the reality alongside which the
program has to work. The different variables in a program, the objects, are then models of real or devised things
in the program's environment.
Every object has a set of properties, determined by its attributes and its operations. The attributes are
used to monitor the object's state, or status. Every object has its own unique set of attributes. The second category of
properties for an object is the operations we can perform from the object. In C++ we use term data member
for attributes and member functions (or methods) for for operations.
| liftA : Lift |
direction = 1
floor = 2 |
|
|
| liftB : Lift |
direction = 0
floor = 5 |
|
Object diagram.
An object is thus a model of a real or devised thing. To describe an object in a program, we need to use the concept of
class. A class is a description of a group of objects with the same properties. The example UML (Unified
Modeling Language) diagram presents a definition of the class Lift. This class has two data members
direction and floor and three methods goTo(), stop(), and
whichFloor(). An object that belongs to a certain class is said to be an instance of the class. Several
objects can belong to the same class. The object diagram above shows two instances of the class Lift -
liftA and liftB. Please note that each instance of a class has its own set of data members.
| Lift |
direction : int
floor : int |
goTo(f : int)
stop()
whichFloor() : int |
A class diagram.
Object-oriented analysis
Object-oriented program development can be said to be kind of model construction. The first question we can ask is:
"What should we construct the model from?" In order to be able to answer this question we must try to think through
and establish what the new program should accomplish. This step of the program development is called object-oriented
analysis. The purpose of the analysis is to familiarize yourself with the problem in order to understand the
requirements and make s first, relatively rough, model of the program to be constructed. Concretely, it means:
- finding the objects that should be included in the model;
- describing the attributes;
- establishing the relations between the different objects;
- grouping them.
The result of object-oriented analysis is documented in different diagram forms that show what the model looks like.
The object-oriented analysis will establish relations between the different objects. We will shortly discuss three
different kind of relations in particular:
is.
The concept of association is used in UML to generally describe the fact that two classes are related. There is,
for instance, an association between the classes c1 and c2
- if c1 has attribute(s) of the type c2,
- if c1 calls operations in c2,
- or if some of the operations of c1 get a parameter of the type c2.
The figure below shows an association between the classes Person and Flight.
Association.
An association is illustrated by a path between the class diagrams. The name of the association comes in the
middle of the path. The small black triangle (voluntary) indicates the direction in which you should read. At one end
of the association you can, if you choose, write a role name that indicates the role that the class plays in the
association. At one end of an association path you can also indicate a multiplicity. This can be given either as
a simple number or as an interval. m..n indicates that the number of objects of the actual type will be
in the interval m to n. The character * means 'unlimited' (0..*
alternatively may be written as only *). Thus, the figure above should always be interpreted as meaning that
a person has booked for 0 or several flights, and that a flight can have between 0 and 300 passengers.
This figure describes a knows relation. A passenger must know which flights he or she will take, and a certain
flight must have passengers list. We thus have a reciprocal bidirectional association. But associations are not always
bidirectional. For instance, a customer database must of course contain information on the people in the database, but
the customers themselves do not need to know that they are included in the database.
One-way association.
You can use arrows at the end of an association path to indicate the direction of an association - its
navigability. The 'diamond' that you can find at the class CustomerList indicates that the class
CustomerList is an aggregation. That is, it is composed of a number of people. When the diamond is
empty, this means that the aggregation 'knows' which parts are included in it.
There may also be associations between objects that belong to the same class. For instance, a person can be married.
The following picture demonstrate this.
Association to the same class.
All the examples above illustrated the knows relation. The next relation we discuss is the has relation,
which describes the fact that an object is constructed with support of another object that it has as a part. This is
also called composition. For instance, a car has an engine, wheels, body, etc, and the engine has a number of
cylinders.
Composition with different classes.
Note that the diamond should be filled in. In UML, composition is regarded as a stronger form of aggregation - a form
in which the objects as parts are really enclosed in the aggregation. That is, the sub-object can only belong
to one whole and it usually expected to live or die with the object.
The third important relation in object-oriented program development is the is relation. This is used to describe
the fact that a class has certain general characteristics that may be shared with other classes. The following figure
illustrates the different kinds of vehicle. In UML the term generalization is used to represent relations of this
kind. The superclass is a generalization of the subclass. In the diagram this is marked with an empty arrow pointing to
the superior class.
Generalization.
In order to describe is relation in object orientation we use a concept called inheritance. When we are
going to describe a class we can start from an existing class and add new attributes or change certain attributes. We
say that the new class inherits the properties of the old class. The new class becomes a subclass of the
old class. The old class is said to be a superclass to the new class.
Object-oriented design
After the first phase (object-oriented analysis) comes the object-oriented design phase. The boundary between
the analysis and design phases is a little vague. It could be said that in the analysis phase an idealized model is made,
whereas in the design phase this model is made more concrete. Another way to express this is to say that during the
analysis phase we think about what is to be done, while in the design phase we consider how these
things are to be done.
The design phase can be divided into two parts: