Introduction

We have talked about system analysis, which is comparable to the planning of an entire city. SA looks at the system as a whole and where software might fit in.

We have talked about requirements analysis, which is comparable to planning one house within a city. RA looks at what features we want in a particular piece of software.

Now we will talk about technical design, which looks at how the software should be structured to achieve the features that we want. We are talking about general software structures, not detailed lines of code yet.

Technical design is similar to designing the architecture for one house.

Imagine that you want to build a house, and you know what features you want in it, where the house location is, and how much land you have.

You still need an architecture (design) for the house. Just knowing what you want is not enough. 

You could create a beautiful house, that you love to live in, and that lasts for a long time. Or you could design an ugly house, that is unlivable, and that falls apart soon.

What are some examples of poor house design? (no windows, kid's rooms in the basement, kitchen far away from the dining room, furnace in the living room) 

The same is true for software. You can implement the same feature set in a really good way, that is bug free (mostly), runs quickly, and is easy to maintain. Or you can create software that is full of bugs, impossible to repair, and runs slowly.

The goal of technical design is to find the right (or a right) design for the feature set and system environment that you are given.

Now, is there a guaranteed way to produce a good house design? 

No. Building architecture is partly knowledge, partly experience, and partly art.

The same is true for software design. There is no prescription for creating the right software design.

There ARE guidelines and general principles however. That is what we will study.

Topics from SEPA 13 (last year's book)

Read quote on page 339 (there are two ways...) Explain what it means.

Read quote on top of page 342 (the beginning of wisdom...) Explain what it means.

Definition -- Module, subroutine, function, part-of-program will be used interchangeably.

Me read each principle on page 340-341. Discuss each one.

Abstraction in SE....

What is it? (Looking at a program at varying levels of detail. Like zooming in and out of a map. At a high level, you see all the pieces, but not the details. At a lower level, you see details, but only part of the system. )

Example from the class projects? Call on team programmers. Name the high-level parts of the program, then some of the lower-level routines.

All levels of abstraction are useful, depending on what you are trying to accomplish at the time.

Modularity...

Fact -- Breaking a complex problem into smaller pieces makes it easier to understand. If you understand something better, you are more likely to get it right. You should apply this principle to software design.

Or to say it another way -- Creating one big program is a bad idea.

What does the picture on page 345 mean? (There is an optimum number of modules, or subroutines, for a software system. Too many or too few is bad.) Example of too many modules? (A 20 line program broken into 10 modules.) Too few? (A 10,000 line program as one routine.)

Read quote on side of page 346 (a software architecture is the development work...) Discuss and explain.

Let's look at the picture on page 347 (software hierarchies)

Define four terms -- depth, width, fan-out, fan-in.

Me draw pictures of too long (and too flat) control hierarchies. Discuss them. 

You can tell a lot about the quality of a software design just by looking at a block diagram of its modules, even without seeing any code.

We want to create software modules that are independent. There are two related aspects to independence.

Cohesion....

What is it? (All the code in each subroutine relates to the same thing.)

Example of a lot? (A printer driver for one OS and one printer.)

Example of little?  (A program where the printer code is part of the UI code.)

Do we want a lot or a little? (A lot.)

Coupling....

What is it? (The degree of dependence between modules.)

Example of a lot? (A subroutine that changes a data item stored in another subroutine.)

Example of little? (A subroutine that calls another one, with 2 input and 1 output parameters, and this is the only dependence between the two routines.)

Do we want a lot or a little? (A little.)

Relating this theory to the real world....

Does this emphasis on good design fly at a real job, with real deadlines and uptight managers?

In some cases, sadly, it does not. You will run into programmers and managers who don't care about design, and just want to get the program "working" as fast as possible.

But, over the long run, a focus on good design will help you. You will write better, bigger systems. Your programs will more likely be released and satisfy customers. You will advance to higher levels. And good engineers and managers do care about software design, and will recognize your good work

You will go farther by focusing on good design, even though you may get resistance sometimes.

Designing for Change (RD 19)

(This chapter gives an excellent overview of a topic that often takes years to learn through experience...)

Change is inevitable, so you might as well assume that it will happen. (Rather than trying to know everything in advance, which is impossible. Or being rigid and refusing to change, which is a bad idea.)

Now, can you design software so that you can handle any conceivable change? No, that is impossible. The basic tenets of the system, or its basic purpose, had better stay fairly constant. The trick is to understand what is basic (and not likely to change) versus what IS likely to change.

Basic method... 

Read "sources of change" on page 417. Explain each one.

Use information hiding (reduce redundancy). Explain what this is. Look at example on page 418 about ID = ++MaxID.

(Optional) Discuss the data type hiding with IDTYPE on page 419.

Read and explain each of the techniques on page 419.

Define families of programs. Look at and explain picture on page 420.

Use OO design. Read quotes on bottom of 421 and 422.

Topics from CC Chap 7

This chapter is an overview of software design from McConnell's viewpoint. 

I will not summarize everything he says. But are there any questions about it?

The important point is that design is an important step in software development. And design is separate from coding. 

Pay attention to design issues as you learn to be a software engineer. Learn about different design methods, try them out, see what works well for you. Keep learning.

Discuss outlines for functional specs.

Talk about importance of detail. What will the user interface look like? What will the inputs and outputs be? What input is allowed/disallowed? What will the program do with bad input?

A software designer who doesn't know the assignment ought to be able to take your functional spec and create a design.

 

Copyright 2001 by Charles H. Connell Jr.