Information Technology Reference
In-Depth Information
predominant design strategy for new software systems. In an object-oriented
design, the system state is decentralized and each object manages its own state
information. Objects have a set of attributes defining their own state and operations
which act on these attributes. Objects are usually members of an object class
whose definition defines attributes and operations of class members. These may be
inherited from one or more super-classes so that a class definition need only set out
the differences between that class and its super-classes. Conceptually, objects
communicate by exchanging messages; in practice, most object communication is
achieved by an object calling a procedure associated with another object.
The stages in object-oriented approach according to Sommerville (
2004
) are:
1. Understand and define the context and the modes of use of system
2. Design the system architecture
3. Identify the principal objects in the system
4. Develop design models
5. Specify object interface
All the activities here are interleaved and influence each other. Here, objects are
identified and the interfaces fully or partially specified as the architecture of the
system is defined. As the object models are produced, these individual object
definitions may be refined, which leads to changes to system architecture. The aim
of the object-orientation is to employ reusable components rather than writing the
modules from scratch. This approach would result in increased systems develop-
ment productivity and higher systems quality (Burch
1992
).
In the preceding section, it was remarked that in identifying the benefits that
could be obtained through using the principle of information hiding, (Parnas
2001
)
also recognized that it was difficult to produce such structures by following any
well-formed set of procedures. By the time the object-oriented philosophy began
to coalesce in the late 1970s, it was obvious that this difficulty with providing any
form of design process that incorporated encapsulation still remained a significant
problem, and, indeed, that the problems were increased further by the nature of the
object-oriented model being so very different from the forms previously experi-
enced. A further spur to finding a design process that could encompass object-
oriented principles came from the development of the Ada programming language,
which became an ANSI standard in 1983. While the 1983 form of Ada is not
strictly an object-oriented programming language, it can be considered to be
object-based in its form, since its structures support the use of:
• Abstraction, both in terms of data typing and through the generic mechanism
with the latter allowing for some abstraction in the description of the algorithmic
part;
• Encapsulation, since the scope of data instances can be controlled via the
private/public mechanism;
• Modularity, through the use of the package construct (and arguably by using
the 3 task and the procedure mechanisms).
