CPSC 333: Introduction to Software Design

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Introduction to Software Design

Most of this material was covered during lectures on February 21, 1997; however, the notes on ``design characteristics and principles'' given below have been updated and expanded, and the material on ``system configuration'' was not covered this year in lectures (but should probably be skimmed).

• References
• Design Stages
  • Architectural Design
  • Detailed Design
• Design Characteristics
• Design Principles
• System Configuration

References

Some additional details about design principles (and several of the design methods that we'll cover later on) can be found in Pressman's book:

R. S. Pressman
Software Engineering: A Practitioner's Approach
McGraw-Hill.

The third edition of this book is available in the library. The fourth edition appeared, very recently, in 1997.

The list of ``characteristics'' of a good software design, given below, appears in the fourth edition of Pressman's texts. However, they originally appeared in the following article:

R. McGlaughlin,
``Some Notes on Program Design,''
Software Engineering Notes 16 (1991), pp. 53-54.

The ``design principles'' mentioned below are also from Pressman's text, but their original source is

A. Davis
201 Principles of Software Development
Mc-Graw Hill, 1995.

Finally, additional details about ``System Configuration'' (discussed at the end of this page) can be found in Chapter 9 of Page-Jones' book:

M. Page-Jones
The Practical Guide to Structured Systems Design
Second Edition, Prentice-Hall, 1988.

This is available on the library.

Design Stages

Software design is frequently broken down into two ``stages'' or major steps - architectural design, and detailed design.

Architectural Design

This might also be called ``preliminary design.'' During this stage of design, the requirements specification is used to produce a ``software architecture.''

For ``data design,'' this might mean that an entity-relationship diagram (and its data dictionary) are used to produce a set of ``data tables'' that will be used to maintain system data when the system is in use (as well, possibly, as well as a set of files that will be used to store this data when the system isn't running).

If the system is to be implemented using a high-level procedural language like Pascal or (arguably, C), and ``structured design'' is being used, then this would include identification of a set of modules (corresponding to functions and procedures in Pascal, and procedures in C), as well as a control hierarchy for these modules, and clearly defined interfaces for these modules. You will also need to identify what each module is required to do (without necessarily determining how it's going to do it).

For object-oriented design, this might include the addition of new classes to your class diagram that don't directly represent parts of the problem domain, but that support parts of the system's human-computer interface, management of data, system control, and so on. It might also include modifications of generalization-specialization structures or whole-part structures, in order to cope with limitations of whatever system or programming language will be used for system implementation.

Detailed Design

During this stage, algorithms and data structures are chosen for the components of the software architecture that were identified during architectural design.

At the end of Detailed Design, you should have selected algorithms and data structures, and produced pseudocode, for each module in the system, as well as for each function in the interface for each data area. Therefore the ``implementation'' or ``coding'' process that follows detailed design should be straightforward - almost mechanical - because it should (almost) only involve translating pseudocode into readable, well structured, source code in a high level programming language.

Design Characteristics

Citing an article of McGlaughlin (listed above), Pressman presents a set of characteristics or properties you should strive for, when developing a software design (and a set of design documents).

• The design must satisfy all the requirements explicitly included in the requirements specification, as well as additional ``implicit'' requirements that the customer may have.
• The design must be a readable and understandable guide for the developers who will write code for the system based on it, as well as for the developers who will later test and maintain it.
• The design should give a complete picture of the software system, ``addressing the data, functional, and behavioural domains from an implementation perspective.''

Pressman lists a set of ``guidelines'' related to design, as well:

1. A (structured) design should have a hierarchical organization that makes intelligent use of control among software elements. (However, good object-oriented designs might not be organized in this way.)
2. A design should be modular: Software should be logically partitioned into elements that perform specific functions and subfunctions. The resulting modules should exhibit independent functional characteristics.
3. A data should contain both ``data'' and ``procedural'' components.
4. A design should lead to interfaces that reduce the complexity of connections between modules, and between modules and the external environment.
5. A design should be derived using a repeatable method that is driven by information that was obtained during requirements analysis.

We'll present several design methods in the next few weeks; it might be worthwhile to think about these methods (and consider how they try to follow these guidelines) as each is discussed.

Design Principles

Pressman includes all these, as well as several more. They're taken from Davis's book, 201 Principles of Software Development, whose title suggests that the list can be extended quite a bit further.

• The design process should not suffer from ``tunnel vision.'' It will frequently be desirable to consider several design alternatives; each should be assessed using the requirements that are to be satisfied, the resources available for development, and the criteria and guidelines mentioned above.
• The design should be traceable to the analysis model. For each requirement, it should be possible to determine which element(s) of the design satisfy it.
• The design should not reinvent the wheel. Quoting Pressman (directly): ``Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns, often called reusable design components, 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. The design's structure should closely resemble the structure in the ``problem domain,'' when possible.
• The design should exhibit uniformity and integration. The design should be ``uniform'' in the sense that it should should ``appear'' that the entire design has been developed (in a consistent way) by a single person, even though this will almost never be the case. Define rules of style and format (as a group) before design begins, and follow them. The design is ``integrated,'' if interfaces between components have been carefully defined (and used).
• The design should be structured to accommodate change.
• The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered. Unusually heavy loads, or unexpected events, should possibly cause the system to slow down, but (ideally) never to ``crash.''
• The design should be assessed for quality as it is being created, and not after the fact. It is not possible to ``add quality in'' near the end of development. We'll see this notion again, when testing is considered (when it'll be said that a badly designed, and therefore error-prone, module should be ``thrown away and redeveloped'' rather than patched).

System Configuration

``Software configuration'' can either to be considered to be a final step in requirements analysis and specification, or a first step of software design. It concerns the fact that the ``system'' you might have specified in earlier steps of ``requirements analysis and specification'' might consist of several subsystems,

• that might need to run at different times,
• such that one or more of these subsystems might need to be duplicated for reasons involving safety or reliability, or (possibly) efficiency,
• such that one or more of subsystems should be implemented using hardware instead of software, or using a manual system, instead of an automated one, and
• such that it might be preferable to buy (and, if necessary, modify) an existing package, in order to implement one or more of these subsystems, rather than building new ones.

It also concerns how you choose which platform to use to implement each subsystem, whether to ``buy'' versus ``build,'' and so on.

If several subsystems with the above properties have been identified, then it will probably be necessary to ``carve up'' (or ``subdivide'') the requirements for the original system, in order to obtain specifications of requirements for these subsystems. You'll also need to specify interfaces between these subsystems and then (probably) design each, separately.

This won't be discussed in CPSC 333, and we won't be ``subdividing'' any of the systems considered in this course, at this point between requirements analysis and design. However, Chapter 9 of Page-Jones' book provides more information about this, and is available in the library.

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Introduction to Software Design