Software Design Introduction

Why should software need to be designed at all?

artifacts such as bridges, cars or television sets to be built without someone first designing them and producing plans for their construction Software is no different: throwing a few dozen programmers at a problem without having detailed plans is hardly likely to result in well-engineered software that actually works.

So, where does the design process fit in?

It occurs somewhere between the optimistic phase where we decide what we would like our system to do (often termed Requirements Capture) and the increasingly pessimistic phase where we build it (Implementation), although it may appear in many different guises. Design is the highly creative stage in software development where someone (the designer) plans how the system or program should meet the customers needs, be easy to implement, efficient and easily extended to meet new needs.

Why software design is important

As software plays a central role in the operation of many systems, as varied as banking transactions, spreadsheet calculations, or aircraft control systems (fly by wire), it becomes increasingly important that such systems should be designed as well as possible. Faulty design can lead to disaster and can even be life-threatening.

It is the key for a successful software system. It allows easy maintenance of a system. It is a processes of a software project. It allows to achieve requirements [non-functional] such as performance,reusability,protability

The benefits are it allows software developer to maintain the software and it allows the developer to analyse the issues which may arise while building up the software therefore improving the efficiency.Software design would help a firm in creating a prototyping which can be used for testing out the software.
Python is another popular software design tool

UNIT - I

The Role of Software Design The Nature of the Design Process

1.1 What is design? 1.2 The role of the design activity process 1.3 Design as a problem-solving 1.4 Design as a wicked problem

1.1 What is design?

the ideas that it presents are rooted in one of the most distinctive of human characteristics. This characteristic is the making of, and the use of, tools. A second distinguishing characteristic of human beings that provides an underpinning for any form of design activity is that of communication. Translating a design into a product almost always involves communicating the designers ideas to the development team In the domain of computing science and software engineering, designing software is a major problem-solving technique, to be ranked alongside the concepts of theory and of abstraction . Figure 1.1, the interaction between mankind and the surrounding world has historically taken two paths.

Figures 1.2 and 1.3, which summarize and contrast the forms of the scientific and engineering processes.

A rather more detailed and formal description of the general design process is provided by the FBS framework (FunctionBehaviourStructure) described in Gero (1990). The terms black box and white box used in Figure 1.3 merit a brief description here, and will be discussed more fully in Chapter 5. Briefly, a black box model is one that describes the external functionality and behaviour of a system as a whole, without any reference to how this is to be achieved. In contrast, a white box model isone in which t he workings of the system are described. (The terms opaque and transparent would in many ways be better ones, but black box and white box are the ones most widely employed.)

This set of actions can be summarized as: postulate a solution; build a model of the solution; evaluate the model against the original requirement; elaborate the model to produce a detailed specification of the solution

an example of a design process, and to use this to demonstrate how the practices of design may differ from those of scientific analysis.

CASE STUDY 1 Moving house . One practice widely recommended to the new owner is to begin by measuring the dimensions of the various rooms in the house, to obtain some squared paper and to use this for drawing up a scale plan showing all the rooms, doors, windows and so on. The next step is to measure the dimensions of various items of furniture and to cut out cardboard shapes to represent these on the chosen scale. Together these form a representation of the new house and its future contents that can be considered as forming the The design process itself then involves trying to identify the best positions for the pieces of card on the plan of the new house. There is really no analytical form that can be used to do this, since it is usually necessary to trade off different factors in making the choices. However, there are various strategies that can be adopted: for example, determine which rooms will take greatest priority, and then seek to find ways of producing a well-matched set of furniture for those rooms. This strategy may lead to greater mismatches in the remaining rooms than would occur if the owner tried for an overall best match. Some of the constraints that apply to the various possible solutions will be more significant than others. Most people would not wish to place kitchen equipment in the living-room, for example, but might be prepared to position surplus fireside chairs in a bedroom. Other factors that might constrain the choice could be colour matches, style and so on. Equally, it is undesirable to obstruct power outlets a point that leads on to our next issue Modularity is an important tool in construction, and it is as important for constructing software.

1.2 The role of the design activity

longer-term implications for software design. 1. The first of these was the knowledge gained from scientific research. 2. The second was the concept of reuse.

Typically, such plans will be concerned with describing: n the static structure of the system, including any subprograms to be used and their hierarchy; n any data objects to be used in the system; n the algorithms to be used; n the packaging of the system, in terms of how components are grouped in compilation units (assuming that implementation will use a conventional imperative programming language); n interactions between components, including the form these should take, and the nature of any causal links. For software systems, however, a further degree of complexity has to be considered. For designing software consists of designing a process; and so it becomes necessary to model and describe its behaviour as well as its structure, and also the functions that it will perform To meet these needs, the designer will usually make use of a number of different forms of design representation to help with constructing the model, each representation providing a different viewpoint on the form of a design, as shown in Figure 1.8.

1.3 Design as a problem-solving process

The purpose of design is simply to produce a solution to a problem The designer has a number of tools to help with the task of problem-solving. Design methods and patterns can provide strategies that will help to determine which

choice may be most appropriate in a given situation. Representations can also help with the process of building models of the intended system and with evaluating its behaviour. In combination with these, abstraction plays a very important part, since to build manageable models of large and complex systems we need ways of abstracting their critical features for use in forming our models. Abstraction enables the designer to concentrate effort on building a logical model of a system, which is translated into a physical model at a relatively late stage in the design process. The concept of abstraction is enormously important for all branches of engineering. Essentially, abstraction is concerned with the removal of detail from a description of a problem, while still retaining the essential properties of its structure

1.4 Design as a wicked problem

It can be characterized as a problem whose form is such that a solution for one of its aspects simply changes the problem. Rittel and Webber identified ten distinguishing properties of wicked problems, most of which can be seen as applying equally well to software design (Peters and Tripp, 1976). The following properties, taken from their list, are particularly relevant.

There is no definitive formulation of a wicked problem Wicked problems have no stopping rule Solutions to wicked problems are not true or false, but good or bad There is no immediate and no ultimate test of a solution to a wicked problem Every solution to a wicked problem is a one-shot operation, because there is no opportunity to learn by trial-and-error, every attempt counts significantly Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions Every wicked problem is essentially unique Every wicked problem can be considered to be a symptom of another problem