Objectives
This section discusses the impact of object orientation
on the software lifecycle.
It first presents a classical view of the software
lifecycle and then discusses why,
when taking user needs into account,
our conception of the software lifecycle may need
to change.
A number of alternative software development models
are then mentioned.
This section intends to show that object orientation
allows for a more or less seamless transition between
the various phases of the software development cycle, including
analysis, design and implementation.
Moreover, it intends to introduce the problems addressed
in each of these phases, respectively the elicitation of
requirements, the quality of software and
robustness.
Also, a first introduction is given to possible vehicles
for the implementation of object-oriented software.
Points to emphasize
- software development models -- in particular the role of prototyping
- software quality -- in relation to reuse and maintenance
- programming languages -- the choice of a vehicle
Hints
The notion of prototyping appears to be quite appealing to
students.
In principle, the entire software lifecycle may be turned upside
down (Meyer, 1988), without essentially sacrificing the goals
of adaptability, quality and robustness.
Also worth stressing are the potential benefits of object
orientation in dealing with future users, especially since business
is likely to require more experts in this field than in the
area of system development.
Choosing a good vehicle for implementation might be essential
for successfully completing a software development project.
Don't hesitate to express and discuss your personal taste.
Questions
- What influence is an object-oriented approach said to
have on the software lifecycle?
What is your own opinion?
- How would you characterize software quality?
Discuss the problem of maintenance.
- Mention a number of object-oriented programming languages,
and give a brief characterization.
Comments
It is worth elaborating on the figures, taken from
[Meyer88],
concerning the relative contribution of implementation
and design and the proportion of time taken up by maintenance.
These figures will probably have to be updated, but the trend
they indicate is clear.