Software Design

Chapter 11

Purposes of Design

• Design transforms the specification into a design.

• The end purpose of the design is to produce detail and information suitable for the coding activity.

• The end-user of the design are coders and sometimes testers.

What Is a Design?

• A design is a specification of the software organization and methods.

• Specifically, we can think of these things as the software architecture, data structures and algorithms

• In addition, a design provides the framework for partitioning the requirements into “subsystems”.

General Design Ideas

• The design activity adds another layer of “focus” in our “fuzzy into focus” strategy of software development.

• During design, we actively assign the responsibility for fulfilling the individual requirements to subsystems: systems within the actual system

• Ultimately, we need to end up with “units” of work that can be parceled out to the code-smiths (programmers).

Iterative Enhancement

• The notion behind iterative enhancement is simple: design complex system as a simple system. Then, “enhance” the system to systematically add the complexity.

• By doing this iteratively, the each component of the complexity is added independently, which the the idea of dealing with “independent parts” as a strategy for handling complexity.

Step-wise Refinement

• Step-wise refinement differs from interative enhancement in that complexity should be ignored until an appropriate level of detail is acheieve.

• In short, details of complexity should be pushed down into the details where the problem can be subdivided and the complexity can be look at as it relates to each of the individual subsystems.

Information Hiding

• In a nutshell, information hiding can be though of as a “need to know” approach to data and algorithms.

• Only code or modules that really need to know how data is manipulated (algorithms) or how it is represented (data structures) should have visibility.

• Why? This approach helps prevent designers from designing in dependencies on data implementation.

Adding to the Test Plan in Design

• During design, the test plan can (and should) be updated to include strategies for the execution of tests to exercise the actual design.

• In addition, in some testing strategies, tests can be updated to test individual subsystems hidden from the outside view.

The Designer's Art

• The designer acquires experience as time goes on.

• Very seldom is the “art” actually codified, but there are some fundamental rules and notions that can be taken advantage of, but these rules are not foolproof, nor are they a substitute for training, thought and good judgment!

By Engineers for Engineers

• The design is written by engineers for engineers.

• Because of this, the design can use jargon, notation methods and design techniques that are alien to the end user.

• This allows for succinct representation of design using notation that has evolved expressly for that purpose.

From Requirements to Design.

• The first part of the design (system architecture) is fuzzier that the later parts (subsystem and module specifications).

• Typically, we divide the design activity up into these two areas: “architecture: and “detailed design.”

• For system architecture, remember the Bauhaus concept: “Form follows function!”

Common, Needed Functions

• It’s often helpful to identify common funtions early, such as sting handling functions.

• Common functions are functions that needed by more than one subsystem or module.

• Early identification allows us to prevent multiple implementation of the same function. This would destroy our system’s “cohesion”.

Major Data Structures

• Major data structures fall into two camps: Permanent and temporary.

• The permanent data structures are the data structures (such as global data) that will persist for the entire duration of the system activity.

• The temporary data may be common data structures that are used to pass information between routines (such as parameter lists) that will be discarded after it has served its functions.

Major Algorithms

• The major algorithms are the algorithms that ‘do the work’ of the system.

• For a payroll system, an algorithm that computes withholding for taxes is clearly a major algorithm.

• There can be multiple functions that involve major algorithms: if the payroll system is for international use, the withholding algorithm would probably be different for each country! We need to know we will have to handle that somehow.

High-level (“Architectural”) Design

• Architecture is usually the product of the designer’s experience. After building printer firmware for several years, a designer would call upon experience of previous printer systems to build the next.

• However, in the face of no experience, how is it done? Many design methods (FSM, OOD and Dataflow-diagrams) can “automatically” generate an architecture without any previous experience. Note that this architecture may not be optimal, but is almost always quite suitable and understandable

Designing Major Subsystems

• Major subsystems lend themselves the the previous principles: they can almost always be designed using the same techniques used at the system level.

• These techniques are to identify the inputs, outputs, major algorithms, data structures, etc.

Traceability Matrices

• Tracability Matrices allow us to track the partitioning of the requirements into the individual subsystems.

• In addition, these matrices allow us to find which requirements are fulfilled by each subsystem.

• Remember, a single requirement may be assigned to more than one subsystem!

Subsystem Interfaces

• In general, it is best to minimize the number of interfaces to each subsystems. This can help reduce “coupling”, but not always. At least it can localize coupling problems to select location.

• Subsystem interface should always, in the author’s opinion, return a success/failure code.

Environment Interface

• In addition to subsystems, the “environment” has an interface, sometimes beyond our immediate control.

• An example of the “environment” interface would be operating system calls, calls to an off-the-shelf library (such as a string handling library and so on.)

Detailed Design

• “Detailed Design” is essentially the decomposition of subsystems into “work packages” for the code-smiths (programmers).

• This activity focuses on the final step of decomposition, but still leave room for the code-smith’s art: it stops short of code itself!

Decomposition of Subsystems into Modules

• Decomposition into modules implies that the assigned requirements must also be allocated to the individual modules. Traceability matrices come into play here as well.

• Again, we identify and specify the major subsystems (in this case, each subsystem is a module) and interfaces.

Designing Major Modules of a Subsystem

• Verb-noun combinations are useful for identifying module functions (“determine_temperature”, etc.)

• Support functions (sometimes call “utility functions”) that are unique to this particular subsystem are also candidates for modules.

Defining Module Interfaces

• Module interfaces are essentially of two types: internal and external.

• Visibility of the internal interfaces are unique to the module itself: this is the idea of information hiding. Most modern programming languages have features that support this.

• External interfaces should be limited to expose only the functionality that is required by the rest of the subsystem or system.

Specifying the Module Functions

• Usually module functions can be easily specified: public function names, input parameters, output parameters, and error codes.

• Occasionally, which a ticklish or unique algorithm is needed, it can be specified using “pseudocode”.

• Be careful not to over specify: the code-smiths have skill sets that will be brought to bear that add value. We often gain little or nothing by over-specifying modules.

Module Documentation

• The documentation for the modules will vary from group to group, but should as a minimum include:– Name of the module.– Description of parameters.– Name of the file the module source code resides

in.– Error conditions and codes returned by the

module.