You are on page 1of 1

specification (usually called a spec by those in the field) is to give the progr

ammers
a manual from which they can code. If it s a good spec, the
programmers shouldn t need to come back to you time after time to get
additional information.
Object-Oriented Methodologies
OO systems development follows the same pattern as structured systems
development. First you must analyze your system OOA. Next you
design the system using OOD. Finally, you code the system using OOP
techniques and languages (e.g., C++, Java).
OO techniques may have some similarity to traditional techniques,
but the concept of OO is radically different from what most development
people are used to. This methodology revolves around the concept of
an object. An object is a representation of any information that must be
understood by the software. Objects can be:
External entities: printer, user, sensor
Things: reports, displays
Occurrences or events: alarm, interrupt
Roles: manager, engineer, salesperson
Organizational unit: team, division
Places: manufacturing floor
Structures: employee record
The easiest way to think of an object is just to say it is any person, place,
or thing.
One of the important features of OO is the reusability of its objects. A
well-coded object is often thought of as a black box. What this means is
that the programmer should be able to glue together several objects to create
a working system. The programmer shouldn t have to know too much
about any of these objects. Does anyone remember playing with Lego
blocks as a child? It was easy to create incredible things such as bridges
and buildings. That was because each of the blocks was easily connected to
all other blocks. It s the same with objects (see the definition of encapsulation
in the following list).

You might also like