Design Processes and Design Strategies

Design Processes and Design Strategies

The role of strategy in Design by top-down methods decomposition, Describing the design Design by composition process – the D-Matrix , Organizational influences upon design Each design method embodies a design strategy within its process part, which gives a sense of direction to the procedures of the method and forms one of the elements that make up its basic philosophy about designing. Following a discussion about the roles of strategy in design, this chapter introduces some simple process modelling forms which can be used to help with describing the design processes themselves. It then goes on to examine some of the more widely adopted strategies, together with the principles that underpin these. Strategies are not necessarily wholly based upon technical factors, and so we also examine how they can be influenced by the needs of organizational users of software.

principal components:

·          representation part

·          process part

·        set of heuristics, or clichés

The properties of some widely used forms of representation have already been described here.it was further observed that the set of these used in a method are important in defining the Design Virtual Machine (DVM) that is embodied in a method, since they determine the type and form of design model(s) that a designer is encouraged to produce when using the method. The process part of a method is closely entwined with the representation part, since it provides ‗procedural‘ guidelines on how the models should be developed. We have General procedural model of the software design process.The role of strategy in methods

now look more closely at the nature and form of the process part, while in later chapters the three components are brought together when we look at examples of design methods and examine the specific forms of heuristic that are associated with them.It shows this procedural model of the software design process in a symbolic fashion, and we will be making use of this form throughout the rest of this book. The basic symbols it uses to describe a design method are:

·          an oblong to denote a representation form;

·          an oval to denote a procedural step;

·          an arc to denote the sequence of steps.

These can be seen more fully here which shows a slightly expanded form (Note that our notation possesses the important property of being hierarchical, as discussed later, in that the description of any transformation step can be expanded further using the same three components.)

The iterations that Expanded view of the procedural model of the software design process

.Design processes and design strategies occur between phases of the design process are not shown explicitly: the model is concerned with describing overall strategy rather than the detailed sequencing of actions, since these will be driven by the needs of a specific problem and the experience of the designer in a brief and introductory discussion about the form of the typical process part of design methods, we made the distinction between a ‗transformation‘ step and one concerned with ‗elaboration‘. Now that we need to consider design processes and strategies in rather more detail, it is useful to examine this categorization more closely. This is because each of the procedural steps of any design method, regardless of the strategy employed, can usually be classified as being one of those two forms. These two forms have quite distinctive roles and characteristics, which can be described as below.

A transformation step is one where the designer modifies the structuring for their model of the ‗system‘ in some way. Typically this consists of reinterpreting it using a different viewpoint

(ultimately, of course, the aim is to produce a constructional model). Such a step will require the designer to make some fairly major design decisions and is clearly a strongly creative one.

An elaboration step is one which does not usually involve any change of viewpoint, but is more concerned with restructuring or reorganizing the design model within the current viewpoint. (Examples might include expanding the bubbles in a DFD, or grouping states within a State chart.) The purpose of an elaboration step is usually either to add further information to the model, or to obtain greater insight into the current state of the design plan through restructuring, and as such it may be an preliminary to a successful transformation step. When we come to examine some examples of design methods, we will see that many of these have only one transformation step, usually preceded and followed by elaboration steps. Important factors from a methodological aspect are whether the transformation step appears early or late in the sequence of steps, and the number (and types) of viewpoint that may be involved. It is important to recognize that both types of step involve creative actions, although the forms that the creativity takes are somewhat different. The transformation process

typically requires the designer to be able to bridge their ideas across two or more different sets of properties, while the elaboration process is more concerned with recognizing patterns and structures (or the potential for forming these), while also possibly anticipating the needs of subsequent transformation.

We discuss later in this section are more likely to be embodied in the procedures employed in the elaboration steps of a method. This general model, in which a sequence of procedural steps make up the process part, is one that we will use extensively in analysing design methods, and the notations shown in Figures 9.1 will be used for this. In the next section we will introduce

a slightly more ‗formal‘ notation that complements this, and which places more emphasis upon the use of the viewpoints model, so making a more explicit distinction between transformation and elaboration steps.

·        Steps modify artifacts. In ‗derivation‘, a new artifact is created. In ‗revision‘, a new version of an existing artifact is created.

·        Steps raise issues. This may occur automatically, but the issue may not have to be addressed immediately.

·          Issues review artifacts. An issue may be raised to review the property of an artifact.

·          Positions respond to issues.

·        Arguments support positions.

·        Arguments object to positions. Arguments are often paired, with one supporting a position and the other opposed to it.

·        Arguments cite artifacts. The artifact provides evidence for the argument.

·          Positions contribute to steps. A step is performed because a set of commitments has

been made.

The form of module employed in a design model is clearly related to the ideas about architectural style and the evolution of the two has largely gone in parallel. Changes in the form of module employed have reflected the evolution of ideas about how systems should be structured, and how those structures might be achieved. Early thinking about design was concerned with making effective use of the subprogram‘s strengths, and so was focused on partitioning system functionality into sub-tasks, we will use the following broad groupings in order to discuss how strategy is incorporated into a design method:

·        decomposition methods, which generally take a ‗top-down‘ view of the design process, developing the design model through a process of sub-division;

·        compositional methods, whereby the basic design model is built up from the identification of

‗entities‘ of some form;

·        organizational methods, for which the structure of the design process is strongly influenced by the requirement that it should conform to non-technical requirements that are based on the form of the organization;

·        template-based methods, where a specific problem domain provides a class of problems that can be tackled using a fairly standard strategy. The rest of this chapter examines the characteristics of each of these strategies (with the exception of the last, which is addressed in the next chapter), and makes an initial classification of methods in terms of them.

Design processes and design strategies Before proceeding, however, one other point should be mentioned here: the relationship between strategy and such ancillary aspects as the design of the user interface and the design of error-handling strategies. Design strategies (and associated methods) tend to encourage the designer to focus on structuring core activities of the eventual system in building up a model of a problem. As a result, such issues as the organization of human–computer interactions (HCI) and the handling of error (exception) conditions are generally deferred until a later stage in the design process, when the design model is being refined and elaborated. This is generally a reasonable practice to adopt, particularly for such issues as exception-handling, since any attempt to include these in the initial model may lead to it becoming excessively complex. The designer is then faced with the following alternatives when determining how to incorporate these issues:

To incorporate them into the later stages of design refinement, by which time architectural decisions may have been made that are inconsistent with their needs;

To repeat the design process from a much earlier stage, using the experience gained from producing a design for the basic problem to help with the greater complexity of the fuller problem. As always with design, there is no hard and fast rule about which of these strategies may be the most appropriate. Constraints such as project deadlines may push the designer towards the former choice but, where significant HCI elements are involved, or where error-handling is an important element, this may lead to considerable distortion of the design structure.

 On the whole, existing design practices do not help greatly with either of these issues. HCI design is now a rather specialized field in its own right, and designing for exceptions is a relatively unexplored field in design theory. Before reviewing the major design strategies, we now examine a ‗viewpoints centred‘ notation .

·        Design by template and

·        Designing with patterns

·        design reuse

·        Patterns in the wider design

The design pattern context Codifying design experience for reuse by others is not solely embodied in procedural forms such as design methods, and the concept of a design pattern offers an important alternative (and complementary) approach to recording design experience. In this chapter we begin by examining the wider issues of reuse in software design and establish some criteria for a 'template-based‘ approach to be practicable. We then examine the nature and form of design patterns as used for Object-Oriented design, identify some of the implications of their use in terms of design practice, and finally consider how easily the concept can be expanded to use with other architectural styles, and what factors might aid or limit this.

Design by template and design reuse we examined the principal ways in which a software designer could reuse the experiences of other designers. While design methods have been a widely-adopted and rather dominant mechanism for this, their general-purpose nature makes them unsuitable for giving detailed guidance about the particular form of solution that might be adopted by a designer when faced with a problem having specific characteristics. While the component of a method that we have termed a heuristic (sometimes also referred to as a ‗cliché‘) does provide some scope to address the question of how to approach certain well-defined classes of problem, the heuristics for most methods are neither well codified nor even recorded and, even when they do exist, they are still An alternative way to reuse experience of what has worked for others when faced with similar problems is through the concept of some form of ‗design template‘.

Software design, were largely informal in nature. They were also relatively few in number, since the basic requirements for developing and using a template are that the problem domain should:

·          be very well-identified, well-defined, and tightly constrained; and

·          contain a significant number of problems that each need a design solution; and further that there should be some accepted form of constructional description that could be used for describing the design template.

There are lots of streams needing to be crossed; and it is possible to describe the template by a drawing. Indeed, one might argue that this last factor has been a, if not the, major problem in terms of adapting this concept for use with software. The descriptive forms used with software that we reviewed in Organized more for describing the details of specific solutions than for portraying their general forms, not least because any diagram still depends quite heavily upon the use of supplementary text. At the level of detailed program design, the idea of ‗solution patterns‘, often referred to as idioms, is fairly well-established (even if still not particularly well codified). At a very basic level of ‗coding-as-design‘, the problem characteristics that determine which form of looping construct a programmer should employ are familiar enough ‗templates‘ to most programmers.

Equally, more advanced and slightly more abstract level, the basic structure that needs to be employed for interrupt-handling is a recognizable pattern which must then be adapted if it is to be mapped on to both the specific features of a particular processor architecture and the particular device characteristics.

At more abstract levels of design, the one good example of wide reuse of design experience is that of compiler-writing. No-one would now begin to develop a new compiler from scratch by using a general-purpose design method, since the basic rules for the organization of compilers are particularly well understood. (The adoption of such a compiler-writing ‗pattern‘ is further encouraged by the availability of tools perform such tasks as lexical analysis and parsing, which in turn exist because the form of compilers is standard enough to merit putting effort into developing such reusable components.)