Page 12 - DCAP308_OBJECT_ORIENTED_ANALYSIS_AND_DESIGN

Object Oriented Analysis and Design

Notes 1.2 Object-oriented Development

Object Oriented Development is a new way of thinking about software based on abstractions
that exist in the real world as well as in the program. Object Oriented Development is a method
of design encompassing the process of object-oriented decomposition and a notation for depicting
logical and physical as well as static and dynamic models of the system under design.
In this context development refers to the software life cycle; analysis, design, and implementation.
The essence of OO development is the identification and organization of application concepts,
rather than their final representation in a programming language. It is observed that the hard
part of software development is the manipulation of its essence, owing to the inherent complexity
of the problem, rather than the accidents of its mapping into a particular language.
The traditional view of a computer program is that of a process that has been encoded in a form
that can be executed on a computer. This view originated from the fact that the first computers
were developed mainly to automate a well-defined process (i.e., an algorithm) for numerical
computation, and dates back to the first stored-program computers. Accordingly, the software
creation process was seen as a translation from a description in some ‘natural’ language to a
sequence of operations that could be executed on a computer. As many would argue, this paradigm
is still the best way to introduce the notion of programming to a beginner, but as systems
became more complex, its effectiveness in developing solutions became suspect. This change of
perspective on part of the software developers happened over a period of time and was fuelled
by several factors including the high cost of development and the constant efforts to find uses for
software in new domains. One could safely argue that the software applications developed in
later years had two differentiating characteristics:

Behaviour that was hard to characterize as a process
Requirements of reliability, performance, and cost that the original developers did not face
The ‘process-centred’ approach used to software development is called top-down functional
decomposition. The first step in such a design was to recognise what the process had to deliver
(in terms of input and output of the program), which was followed by decomposition of the
process into functional modules. Structures to store data were defined and the computation was
carried out by invoking the modules, which performed some computation on the stored data
elements. The life of a process-centred design was short because changes to the process
specification (something relatively uncommon with numerical algorithms when compared
with business applications) required a change in the entire program. This in turn resulted in an
inability to reuse existing code without considerable overhead. As a result, software designers
began to scrutinise their own approaches and also study design processes and principles that
were being employed by engineers in other disciplines. Cross-pollination of ideas from other
engineering disciplines started soon after, and the disciplines of ‘software design’ and ‘software
engineering’ came into existence.

In this connection, it is interesting to note the process used for designing simple electromechanical
systems. For several decades now, it has been fairly easy for people with limited knowledge of
engineering principles to design and put together simple systems in their backyards and garages.
So much so, it has become a hobby that even a ten-year old could pursue. The reasons for this
success are easy to see:
easily understandable designs
similar (standard) solutions for a host of problems
an easily accessible and well-defined ‘library’ of ‘building-blocks’

interchangeability of components across systems, etc.

6 LOVELY PROFESSIONAL UNIVERSITY