No approach to software development is likely to survive unless it solves
some of the real problems encountered in software engineering practice.
In this section we will examine how the object-oriented approach is
related to the conceptions of the life-cycle of software
and what factors may motivate
the adoption of an object-oriented approach to
software development.
Despite some variations in terminology,
there is a generally agreed-on
conception of the various phases in the development of a software product.
Roughly, a distinction can be made between a phase of analysis,
which aims at specifying the requirements a product must meet,
a phase of design, which must result in a conceptual view of the
architecture of the intended system, and a phase of implementation,
covering coding, testing and, to some extent, also maintenance
activities.
See slide [1-lifecycle].
No such consensus exists with respect to the exact relation between
these phases.
More specifically, there is a considerable variation in methods and guidelines
describing how to make the transition from one phase to another.
Another important issue is to determine what the products are exactly,
in terms of software and documentation, that must result from each phase.
The software life-cycle
- Analysis -- Conceptual Model, System Requirements
- Design -- System Design, Detailed Design
- Implementation -- Coding, Testing
With an increase in the number of software products
not satisfying user needs, prototyping
has become quite popular!
slide: The software life-cycle
The traditional conception of the software life-cycle is
known as the waterfall model, which prescribes a strictly sequential transition between
the successive phases, possibly in an iterative manner.
Strict regulations with respect to validation of the products
resulting from each phase may be imposed to avoid the risk of backtracking.
Such a rigid approach, however, may cause severe problems,
since it does not easily allow for modifying decisions taken earlier.
One important problem in this respect is that the needs of the users of a system
may change over time, invalidating the requirements laid down in an earlier
phase.
To some extent this problem may be avoided by better techniques
of evoking the user requirements in the analysis phase,
for instance by developing a prototype.
Unfortunately, the problem of accommodating changing user needs
and adapting to changing circumstances (such as hardware)
seems to be of a more persistent nature,
which provides good reason to look at alternative software development models.
Software development models
The software engineering literature abounds
with descriptions of failing software projects and remedies proposed
to solve the problem of software not meeting user expectations.
User expectations may be succinctly characterized by the RAMP
requirements listed in
slide [1-requirements].
Reliability, adaptability, maintainability
and performance are not unreasonable demands in themselves.
However, opinions on how to satisfy these criteria
clearly diverge.
Requirements -- user needs are constantly evolving
- Reliability -- incremental development, reuse, synthesis
- Adaptability -- evolutionary prototyping
- Maintainability -- incremental development, synthesis
- Performance -- incremental development, reuse
slide: Requirements -- RAMP
[Bersoff91] and [Davis88] explain
how the choice of a particular
software development model may influence the
chances of successfully completing a software project.
As already mentioned, rapid throwaway prototyping
may help to evoke user needs at an early stage,
but does not help much in adapting to
evolving user requirements.
A better solution in this respect is to adopt a
method of evolutionary prototyping.
Dependent on the technology used, however,
this may cause severe problems in
maintaining the integrity and robustness
of the system.
Less flexible, but more reliable is an approach of
incremental development,
which proceeds by realizing those
parts of a system for which the user requirements
can be clearly specified.
Another means of adapting to changing user
requirements is to use a technique of
automated software synthesis.
However, such an approach works only if
the user requirements can be formalized easily.
This is not always very likely, unless the
application domain is sufficiently restricted.
A similar constraint adheres to the reuse of software.
Only in familiar application domains is it
possible to anticipate how user requirements
may change and how to adapt the system appropriately.
Nevertheless, the reuse of software seems
a very promising technique with which to reduce the cost and time
involved in software products
without (in principle) sacrificing reliability
and performance.
See slide [1-development].
Software Development Models
- rapid throwaway prototyping -- quick and dirty
- incremental development -- slowly evolving
- evolutionary prototyping -- evolving requirements
- reusable software -- reduces cost and time
- automated software synthesis -- one level of abstraction higher
slide: Software development models
Two of the principal advocates of
object-oriented technology, Cox and Meyer,
regard the reuse of software as the ultimate
solution to the software crisis.
However, the true solution is in my
opinion not so straightforward.
One problem is that tools and technologies
are needed to store and retrieve reusable
components.
That simple solutions do not suffice is illustrated
by an anecdote reported by Alan Kay
telling how difficult it was to find his way
in the Smalltalk class structure after
a significant change, despite the browsing
facilities offered by the Smalltalk system.
Another problem lies in the area of human factors.
The incentives for programmer productivity have too long
been directed at the number of lines of code
to make software reuse attractive.
This attitude is also encouraged in universities.
Moreover, the reuse of other student's work is
usually (not unjustifiably) punished instead of encouraged.
However, having a sufficiently
large store of reusable software at our disposal
will allow us to build software
meeting the RAMP requirements stated above,
only if we have arrived at sufficiently
stable abstractions of the application domain.
In the following, we will explore how object-oriented
technology is motivated by problems
occurring in the respective phases of the
software life-cycle and how it contributes
to solving these problems.