The Architecture Concepts

The Architecture Concepts:

It provide a methodological analysis of design methods, by trying to analyze their forms and to classify them in some way.)The idea of a method as a structured and 'procedural‘ way of doing things is on that should be familiar enough. 'Methods‘ are used to structure the way that we perform many routine tasks, such as making a cup of tea: Boil the kettle; warm the pot; add the tea; pour on water; wait a number of minutes; pour the tea into the cup. Like most methods, this puts a strong emphasis on the ordering of actions (if you don‘t think so, try changing the order of any of the operations in the above example, and see what results!). However, it provides little or no guidance on those issues that are more a matter of taste, such as:

·          how much tea to add

·          how long to wait for the tea to brew

since these are personal preferences of the tea-maker. Since they are also essential to

the success of the tea-making process, we can reasonably conclude that ‗procedural‘ guidance alone is insufficient for this purpose, and that some ‗domain knowledge‘ is also required. We can devise methods for organizing many other activities, from driving a car to constructing kitchen units, model aircraft and so on. However, such methods are rarely creative in quite the same sense that we consider the act of design to be creative. Rather, these methods are recipes for doing something that we have learned to do through ‗experiment‘ or ‗theory‘ (or some combination of both). We might be able to adapt a method like that in the example above for other tasks (for making coffee instead of tea, perhaps), but we cannot easily change its basic domain (that of making hot drinks).

A design method is generally much less prescriptive than the kind of method that we might use for making tea, or for assembling a new garden shed. Indeed, in some ways a software design method can almost be considered as a ‗meta-method‘, in that it is used to develop new processes, which in turn are ways of doing things – where the‗ doing‘ that is involved will be the task of the computer. Returning to the tea-making example the analogy in this case would be using a design method to design the form of the tea-making process itself. So we can reasonably expect that a design method should identify a general strategy to be used by the designer, and provide some rather general guidelines on its use, based upon experience. However, a method cannot be expected to be very prescriptive about how the ultimate solution to a problem is to be attained, since the specific design decisions required will be determined by the nature of the problem, rather than by the method. (Think of all the different processes that are used for making coffee!)

Vessey and Conger (1994) have suggested that the knowledge involved in successfully employing a design method can be categorized into two forms:

1. declarative knowledge, describing what tasks need to be performed at each step in the design process; and the rationale for method

2.               procedural knowledge, consisting of knowledge about how to employ a given method in a particular situation. In terms of our example of making tea, the declarative knowledge would include the tasks to be performed, and the order in which they should be performed (boiling water, adding tea to pot, adding water to pot), while the procedural knowledge would address such issues as how much tea to add and how much water to use when making tea for four people. Declarative knowledge is therefore fairly readily conveyed through the use of a ‗do this, then do that‘ form of description, whereas procedural knowledge is more likely to be acquired through experience. This experience may itself be acquired directly (as is likely when the knowledge is about how to make tea) or through exposure to case studies (which is probably more practical when the knowledge is about how to design software). Since we often express the declarative knowledge in what we term a procedural form, by specifying a sequence of actions that should be performed, this terminology can be a little confusing, although both uses of ‗procedural‘ are quite reasonable ones! (It is also worth noting that Détienne (2002) uses the terms declarative and procedural in yet another, slightly different, way.) Returning to the need to find ways of designing software: in Chapter 2, the following three main components of a software design method were identified, and their relationships are shown in 8.1

The representation part consists of one or more forms of notation that can be used to describe (or model) both the structure of the initial problem and that of the intended solution, using one or more viewpoints and differing levels of abstraction. What is a software design method?

The process part describes the procedures to follow in developing the solution and the strategies to adopt in making choices. This generally involves the designer in making a series of transformations on the different forms that comprise the representation part.

A set of heuristics or clichés provide guidelines on the ways in which the activities defined in the process part can be organized for specific classes of problem. These are generally based on experience of past use of the method with a particular problem domain, or for a particular form of structure. In terms of the classification of knowledge discussed above, the process part can be considered as embodying the declarative knowledge, while heuristics are more concerned with procedural knowledge. This description will be elaborated further in the next chapter; for the moment these terms will provide a very general descriptive framework. Software design methods fall into two very broad and general categories. These are essentially distinguished by the forms of representation that are used, although in turn the representation forms have some influence upon the forms of process that can be used within them

Formal methods largely depend on the use of mathematical notations for the representation parts. These notations permit a degree of consistency checking between the descriptions used in the different stages of design, as well as more rigorous design transformations. However, while the representation parts for such methods have been the subject of considerable research and development, the process parts are less well refined and are apt to be developments of the ‗top-down‘ strategy which is discussed more fully in Section 9.3.

This imbalance leads us to ask whether the term ‗Formal Method‘ is really the most appropriate description. Because of this, the term Formal Description Technique (FDT) is sometimes preferred, as one that emphasizes the powerful notational aspects while playing down the much weaker procedural element. Figure 8.2 Some properties of formal and systematic software design methods. The rationale for method Systematic methods are generally less mathematically rigorous in form, both in terms of the representation part – which normally consists of one or more forms of diagram – and also of the process part. This is true even for those methods that are

Generally considered to be more prescriptive in their form, such as JSP and SSADM. As a consequence, there is far more scope to use ‗mix and match‘ techniques with systematic methods, in which ideas or representation forms from one method can be used to help resolve a particular issue, even though the design is being developed using the strategy of another method.

The third component of a design method, the heuristics (or clichés) usually consist of a set of techniques that are recommended for use in handling particular situations that may be encountered across a wide variety of problems. These heuristics are generally built up over a period of time, as experience is gained with using the method in a wider problem domain, and so they are essentially experiential in origin, although they may be highly systematic in form. We will encounter a number of examples of these in later chapters, and they play an important role in allowing a designer to reuse the experience of others. Examples of heuristics can be found in both systematic and formal methods. The design methods discussed in this book are all systematic in their form, although we will also examine an example of an FDT in Chapter 18. This bias partly reflects the relative preponderance of systematic methods in current industrial practices, and partly the wider variety of design models that they tend to provide.

The rest of this chapter will examine in greater detail the rationale for using any method to design software, and will consider some of the limitations that generally apply to the use of a design method.8.2 The support that design methods provide Since this is a book about design and design methods, it is not unreasonable at this point to raise the question: why should anyone use a method at all? Indeed, probably considerably more software has so far been produced without the use of an explicit design method than through the use of such methods – so what benefits might be expected from making use of a software design method (whatever form this might take)? Some answers to this were identified and were summarized at the beginning of this chapter. The last of these, that of providing an artificial framework to assist with thinking about an intrinsically invisible set of elements, is an important one, and one that is largely addressed by the representation parts of design methods. A second reason, and one that draws upon both the representation and process parts, is simply that of scale. Software-based systems increasingly underpin almost all aspects of a modern society. Some, such as those used to handle financial transactions within banks and similar institutions, were designed with the expectation that they would be large systems, while others may have become large through an undirected

Process of aggregation. (An example of the latter is the growth of many websites, where different elements are owned and maintained by separate individuals or organizations, but the site may still form a virtual whole.) For the former in particular, the cognitive tasks involved in planning and understanding such degrees of complexity are The support that design methods provide ones that may be usefully supported by using a systematic and structured approach to development and maintenance. For the latter, the need to ensure consistent behavior and the need to facilitate integration between diverse elements also imply the need for some degree of standardization, at least to the level of being able to describe the structures involved. While such systems are less obviously candidates for the use of design methods, there is certainly scope to employ the representation elements and possibly some of the more strategic ideas. One of the implicit features of design methods is that the use of any method will lead to designs that employ the architectural style associated with that method. With the long service life of much software, one way of preserving the integrity and structure of a system is to develop and maintain it by using a single design method. There are therefore two aspects of the software development process (and of the subsequent maintenance task that normally goes with software systems) that can be expected to benefit from using a method to provide a structured and systematic approach to the development process. These are:

·          technical issues

·          management issues

and so both of these are considered in this section. Technical issues‘ consist of the problem-related aspects of design. There are a number of these to consider, with the relative importance of each one being somewhat dependent upon a range of external factors such as the structure of the development organization, as well as the nature of the design problem itself. So the following points should not be considered as ranked in any particular order.

The use of a design method should help the designer to produce a system that is structured in a consistent way, which may be particularly important if the design is being produced by a team of designers who will need to ensure that their contributions fit together correctly. In such a case, the use of a design method both helps with defining the chosen architectural form and also establishes a set of common standards, criteria and goals for use by the team.

The use of a method should lead to the production of records and representations in standard form that can be used by a maintenance team to capture and understand the intentions of the original designer(s) This allows the system maintainers to make changes consistent with the overall structuring of The rationale for method the system, as originally planned, and so to help preserve its integrity.