SDA01 9/18/07 10:32 AM Page iii www.Vidyarthiplus.com Software Design www.Vidyarthiplus.com SDC01 9/18/07 10:34 AM Page 3 www.Vidyarthiplus.com UNIT 1 : SOFTWARE DESIGN PRINCIPLES INTRODUCTION Software design is the process by which an agent creates a specification of a software artifact, intended to accomplish goals, using a set of primitive components and subject to constraints. Software design may refer to either "all the activities involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems" or "the activity following requirements specification and before programming, as ... in a stylized software engineering process." Software design usually involves problem solving and planning a software solution. This includes both low-level component and algorithm design and high- level, architecture design. Software design is the process of implementing software solutions to one or more set of problems. One of the important parts of software design is the software requirements analysis (SRA). It is a part of the software development process that lists specifications used in software engineering. If the software is "semi- automated" or user centered, software design may involve user experience design yielding a story board to help determine those specifications. If the software is completely automated (meaning no user or user interface), a software design may be as simple as a flow chart or text describing a planned sequence of events. There are also semi-standard methods like Unified Modeling Language and Fundamental modeling concepts. In either case, some documentation of the plan is usually the product of the design. Furthermore, a software design may be platform-independent or platform-specific, depending on the availability of the technology used for the design. Software design can be considered as creating a solution to a problem in hand with available capabilities. The main difference between Software analysis and design is that the output of a software analysis consist of smaller problems to solve. Also, the analysis should not be very different even if it is designed by different team members or groups. The design focuses on the capabilities, and there can be multiple designs for the same problem depending on the environment that solution will be hosted. They can be operations systems, webpages, mobile or even the new cloud computing paradigm. Sometimes the design depends on the environment that it was developed for, whether it is created from reliable frameworks or implemented with suitable design patterns. www.Vidyarthiplus.com SDC01 9/18/07 10:34 AM Page 8 www.Vidyarthiplus.com External requirements 1 Clarify Requirements nature of specification requirements 2 Analyse needs Functional and build ‘black specification box’ model of problem Functional specification 3 Postulate a ‘white box’ design List of mismatches solution 4 Validate solution (including use of prototypes) White box model 5 Design plan Implementation of the design plan using a suitable form of software Figure 1.3 A model of the design process. n postulate a solution; n build a model of the solution; n evaluate the model against the original requirement; n elaborate the model to produce a detailed specification of the solution. www.Vidyarthiplus.com SDC01 9/18/07 10:34 AM Page 16 www.Vidyarthiplus.com A software designer may need to acquire some degree of ‘domain knowledge’ as a routine part of the input needed for undertaking any particular design task. Some of this may be obtained from the specification (which may well run to hundreds of pages), but by no means all of the necessary knowledge is likely to be available in this way. So, as shown in Figure 1.7, the software designer may need to be responsive to many channels of communi-cation. This is an aspect that will be addressed further in Chapter 3, while some of the ways of transferring the domain knowledge will also be examined more fully in later chapters. To continue with the needs of software development: it is clear from the above that the main task of the design phase is to produce the plans necessary for software production to proceed. The form and extent of the plans will be determined by the design practices and means of implementation chosen, as well as by the size of the Requirements specification Plans for realization of the design Constraints Domain knowledge Figure 1.7 The designer’s channels of communication. www.Vidyarthiplus.com SDC01 9/18/07 10:34 AM Page 17 www.Vidyarthiplus.com system being developed. Clearly, in a large project employing many programmers the design plans will need to capture a much wider range of factors than will be needed by the one-person project, where the designer may well be the programmer too. 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 compi- lation 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. These are all concerned with specifying the form of the design product itself. But as was observed above, the overall design task may also involve producing process- oriented plans too, concerned with such matters as the preferred order of development for subprograms/modules and so on, and the strategy for their eventual integration into the complete system. (These are rather like the assembly directions that are needed for construction of the garden shed.) However, for the moment we will chiefly concern ourselves with the needs of the design product. As in many more ‘classical’ forms of engineering, software designers produce plans that specify how the final product is to be assembled in terms of the items listed above. This usually requires the use of a variety of forms of representation, since each of these provides a different ‘view’ of a system. In a way, the use of these multiple views corres- ponds to the use of plan, elevation and end views in technical drawing, as well as to the cross-sectional forms used to indicate assembly details. (The concept of tolerance is perhaps lacking though, since software components generally have to ‘fit’ rather precisely.) For software systems, however, a further degree of complexity has to be consid- ered. For designing software consists of designing a process; and so it becomes neces- sary to model and describe its behaviour as well as its structure, and also the functions that it will perform. So the designer’s model will ideally include descriptions that also encompass these aspects of the eventual system. 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 represen- tation providing a different viewpoint on the form of a design, as shown in Figure 1.8. The more complex the system, the more we need a full set of viewpoints to understand its behaviour, and to provide a specification that is sufficiently complete for it to be used as an aid in the construction of the system. We will return later to consider more fully the ways in which the dynamic nature of a software system influences (and complicates) the process of design; for the moment we will continue to focus our attention upon the nature of the design process in general. www.Vidyarthiplus.com SDC01 9/18/07 10:34 AM Page 18 www.Vidyarthiplus.com 18 Figure 1.8 Examples of design viewpoints. www.Vidyarthiplus.com principles for software design • The design processwww.Vidyarthiplus.com should not suffer from “tunnel vision.” A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job. • The design should be traceable to the analysis model. Because a single element of the design model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model. • The design should not reinvent the wheel. Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited! Design time should be invested in representing truly new ideas and integrating those patterns that already exist. • The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world. That is, the structure of the software design should (whenever possible) mimic the structure of the problem domain. • The design should exhibit uniformity and integration. A design is uniform if it appears that one person developed the entire thing. Rules of style and format should be defined for a design team before design work begins. A design is integrated if care is taken in defining interfaces between design components. • The design should be structured to accommodate change. The design concepts discussed in the next section enable a design to achieve this principle. • The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Well- designed software should never “bomb.” It should be designed to accommodate unusual circumstances, and if it must terminate processing, do so in a graceful manner. • Design is not coding, coding is not design. Even when detailed procedural designs are created for program components, the level of abstraction of the design model is higher than source code.