Software Design

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.

Issues

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.

Code as Design: Three Essays by Jack W. Reeves

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

J.S. Gero, Design Prototypes: A knowledge Representation Scheme for Design, AI Magazine, vol. 11, no. 4, pp 26-36, 1990

Gero describes a framework for design that has sufficient power to capture the nature of the concepts that support design processes (Wikipedia). This framework that involves the relation between function, behaviour, and structure (FBS) of a design, can be applied to any engineering discipline.

We build upon this framework to incorporate the three principles mentioned above.

FBS Framework

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.

Conclusions

We introduced refinement and composition in the FBS framework in order to deal with complexity. One may argue that refinement and composition were already implicit in the FBS framework, as they are part of a normal design process. However, the explicit presence of refinement and composition not only makes it easier to deal with complexity in the design, but also with the complexity of the design process. The latter makes reasoning over the design process easier, as well as giving the design team a better understanding of the design process.

J.S. Gero and N. Kannengiesser, The situated Function-Behavior-Structure Framework, Design Studies, vol. 25, no. 4, pp 373-391, 2004

Gero and Kannengiesser describe the framework in relation with the environment in which the designing takes place, accounting for the dynamic character of the context. Of course, the object of design influences the environment, and the design process may lead to new or different requirements which also influences the environment. But this can be described more easily by considering the object to be designed as a component of a larger design in which the environment is redesigned. So, explicit composition in the FBS framework is sufficient for this.