The software design process differs not much or should not differ much
from design processes in other fields.
History shows that in all fields there are many failures.
To avoid failures it is important to learn from failures.
Especially when these failures are due to bad designs.
In these cases the design process should be evaluated to discover what
lead to the bad designs.
In the field of software development there are many failures, but seldom these failures are traced back to their origin in the design process. We give some issues with the current practice of software development.
Software
To understand the software design process it is important the know what software and the software design itself really are.- Software
- It is a sequence of ones and zeros that is stored on some magnetic media, or to put it in an abstract form, something that can be interpreted directly by a machine model (the 'hardware'). It is not a program listing in some programming language.
- Software Design
- The final document of the design phase in software engineering is the source code listing, but the design is not limited to that. The complete design is the source code plus all other documentation from the design phase.
- Building Software
- After the design phase the software can be build. This step is completely automated (compilers, etc), so the software can be generated from the source code.
This view on software and software design was put forward by Jack W. Reeves
in his articles What is Software Design? (1992) and
What is Software Design: 13 Years Later.
Dealing with Complexity
As software systems become larger and larger, the complexity of these systems increases. A software design process should deal with complexity in order to produce well designed systems. In our opinion, complexity should be dealt with in design by obeying the following three principles.- abstraction
- Local details do not matter in the overall design.
In other words, separate the what from the how.
- stepwise refinement
- Refinements themselves must not be made complex by trying to make too
large steps ('jumpfoolish').
- separation of concerns
- Overlap in functionality should be as little as possible between interacting parts of a system to achieve high cohesion and low coupling.
A methodology should make clear how these three principles are modelled explicitly in order to follow the nature and process of design.
The Design Process
In- J.S. Gero, Design Prototypes: A knowledge Representation Scheme for Design, AI Magazine, vol. 11, no. 4, pp 26-36, 1990
We build upon this framework to incorporate the three principles mentioned above.
The result is a framework for refinement (R-FBS) with which levels of abstraction can be introduced in the design process, and a framework for composition (C-FBS) with which sub-processes of design can be introduced in the design process. Both these frameworks consist of two or more FBS frameworks.The frameworks can be used to design a design process customized to the project(s) at hand.
Implementation of the Design Principles
A particulary software development methodology should be a refinement of the FBS framework (using the tools R-FBS and C-FBS). We briefly describe how the three principles mentioned above can be implemented in such a methodology.- Abstraction
- The principle of abstraction can be incorporated in the design
process by the application of one or more R-FBS frameworks.
This leads to several levels of abstraction which are related to each other
by refinement processes.
- Stepwise Refinement
- Getting from an higher level of abstraction to an lower one takes
place through refinement processes.
In these refinement processes the development of the necessary refinements
takes place. These refinements can be very complex.
To deal with this complexity the refinement process has to take place
in a stepwise manner.
So, the refinement from one level of abstraction to another is
actually the result of refinements of refinements until a certain
level of abstraction is met.
- Separation of Concerns
- To establish an overlap in functionality as little as possible between different parts of the system, several applications of the C-FBS framework in the design process can be incorporated. This may lead to sub-processes in the design process for the different parts of the system.