The architecture of object-oriented systems
The process of software development has often
been compared to the process of constructing buildings,
usually in the context of defending a traditional software
development method.
The argument comes down to
the statement that it takes a solid plan
and sufficient time to lay the foundations
and erect the building.
The conclusion, generally, is a plea for
a science of software engineering/programming,
or an engineering discipline of software design. See for
example [Gries] or [Potter91] for a similar
argument in defense of formal specification methods.
The line of reasoning exemplified by the building
metaphor is defective in two respects.
Firstly, the presupposition of a rigid ordering in
time is clearly contradicted by the many attractive
old city centers, which have often evolved over time
without a plan.
Secondly, the presupposition of a fixed method
of development is clearly demonstrated to be false
by modern building techniques, employing prefabricated components.
Hence, neither temporal order nor procedures
of construction are as fixed as they at first seem.
The view expressed in the building metaphor
also fails for the software life-cycle.
Both throwaway and incremental prototyping
have come to be accepted as viable methods
for developing software.
Nevertheless, when we speak of design,
we think of some architectural blueprint of the system,
the layout of its structure.
What, we may ask, is the role of the design in
the software life-cycle?
And what is the function of its product,
the design document?
Software Development Process -- transition
- analysis --> design --> implementation
Aspects
- architecture -- {\em components\ifsli{,}{ and} relations}
- method -- guidelines
- process -- management
- design -- software support
Alternative styles
- rapid and evolutionary prototyping
slide: Software development process
In [Jacobs92], a detailed account is given of a method
of object-oriented software engineering
based on elementary architectural notions,
such as (object) components and (use) relations,
and strong convictions with respect to design guidelines
and process management issues.
See slide [3-process].
An explicit distinction is made between the {\em architectural
concepts}, which provide the means with which to construct
various models, the method, which is a bag of guidelines
telling us how to employ the architectural notions, the
process, which details what steps to take to complete
the software life-cycle,
and the tools, which provide the software support
either for the construction of models
or for managing the actual process of software development,
or both.
In [Jacobs92], both the method and issues of process
development are spelled out in great detail,
illustrated by a number of examples.
These issues are clearly important
in actual production environments (business or industrial),
but seem to be dependent
to a large extent on non-technological
factors.
From the perspective of software technology,
we are primarily interested in the architectural
notions underlying the various methods and, to
a lesser extent, in the tool support for
these methods.
Also, apart from the architectural structure per se,
we are interested in what properties a design model must have
in order that
we may verify that a model satisfies its initial requirements.