Introduction to Software
Construction
Chapter 1-3
What Is Software Construction?
What we will cover?
Why Is Software Construction
Important?





Is a large part of software development
Is the central activity in software development
With a focus on construction, the individual
programmer's productivity can improve enormously
Construction's product, the source code, is often the only
accurate description of the software
Construction is the only activity that's guaranteed to be
done
The power of metaphors



The chemist Kekulé had a
dream in which he saw a snake
grasp its tail in its mouth.
When he awoke, he realized
that a molecular structure based
on a similar ring shape would
account for the properties of
benzene.
Further experimentation
confirmed the hypothesis
Software Metaphors

Metaphors have the virtue of an expected behaviour that is
understood by all.



A software metaphor




unnecessary communication and misunderstanding are minimized,
allows for quicker learning and a higher level of abstraction for the
problem at hand.
is more like a searchlight than a road map.
it doesn't tell you where to find the answer;
it tells you how to look for it.
A metaphor serves more as a heuristic than it does as an algorithm.

a heuristic process.


This will tell you how to look for a solution, not where to find
an algorithm process.

Gives you specific directions for a solution, and where to look to find the solution.
Heuristic vs. algorithm


The main difference

the level of indirection from the solution

example: Getting to someone's house
Heuristic






Find the last letter we mailed you.
Drive to the town in the return address.
When you get to town, ask someone where our house is.
Everyone knows us—someone will be glad to help you.
If you can't find anyone, call us from a public phone, and we'll come get
you.
Algorithm

Gives you the instructions directly – GPS
Common Software Metaphors (1)

Software Penmanship: Writing Code




looks at writing software the same way that most people think that an author
writes a book. You just sit down and start writing from start all the way through
to the finish.
along with starting from scratch, just as in writing a story, expect to take at least
one version of your program and completely through it away.
this works great if you are working for yourself, however, most employers like to
see productive work, not work you throw away.
implies a software-development process that's too simple and rigid to be healthy
Common Software Metaphors (2)

Software Farming: Growing a System




like planting seeds and growing crops
You design a piece, code a piece, test a piece, and add it to the
system a little bit at a time. By taking small steps, you minimize the
trouble you can get into at any one time
a good technique is described with a bad metaphor
its suggestion that you don't have any direct control over how the
software develops.
Common Software Metaphors (3)

Software Oyster Farming: System
Accretion


like a oyster gradually adding coats of
calcium carbonate to a pebble to reduce the
irritation.
make the simplest possible version of the
system that will run


it doesn't have to perform realistic
manipulations on data, it doesn't have to
produce realistic output
however, once the version is complete, we
slowly add small working components to the
system and test them.

will eventually lead to a fully functioning system
by slowly over time adding little bits of working
code to make the operation smooth and
pretty.
Common Software Metaphors (4)

Software Construction: Building Software



The image of "building" software is more useful than that of "writing" or
"growing" software.
It's compatible with the idea of software accretion and provides more
detailed guidance.
Building software implies various stages of planning, preparation, and
execution that vary in kind and degree depending on what's being built.
Building houses vs. building software

In building a house, you won't try to build things you can buy
already built.




You'll buy a washer and dryer, dishwasher, refrigerator, and freezer.
Unless you're a mechanical wizard, you won't consider building them
yourself.
You'll also buy prefabricated cabinets, counters, windows, doors, and
bathroom fixtures.
If you're building a software system, you'll do the same thing.



You'll make extensive use of high-level language features rather than
writing your own operating-system-level code.
You might also use prebuilt libraries of container classes, scientific
functions, user interface classes, and database-manipulation classes.
It generally doesn't make sense to code things you can buy readymade.
The Intellectual Toolbox

A good craftsman


knows the right tool for the job and knows how to use it
correctly.
A good programmer


The software practices and techniques that work become the
toolbox.
add what worked as well as what didn't work to the toolbox
to make it more effective
Prerequisites to Construction

Before beginning construction of a house, a builder reviews
blueprints, checks that all permits have been obtained, and surveys
the house's foundation.



As with building construction, much of the success or failure of the
project has already been determined before construction begins.


A builder prepares for building a skyscraper one way, a housing
development a different way, and a dog-house a third way.
No matter what the project, the preparation is tailored to the project's
specific needs and done conscientiously before construction begins.
If the foundation hasn't been laid well or the planning is inadequate, the
best you can do during construction is to keep damage to a minimum.
The importance of these steps cannot be overstated.

if this process is poorly done, we will still be lucky if the result is even
working, let alone useful
Emphasizing Quality

At the end of the project


In the middle of the project


plan for a high quality product
Your design limits the end results.


emphasis is on good construction practices
At the beginning


emphasis is on testing
by the time you start construction, it is too late to correct a weak or
faulty design.
The best we can do in construction is to recognize that the
design is bad and go back and try again.

However, this can be an very expensive proposition, but at times
necessary to actually save money.
Cost to fix defects (1)
Cost to fix defects (2)
Problem-Definition Prerequisite

The problem definition lays the
foundation for the rest of the
programming process
 you need a clear statement of
the problem before you can
even think of a solution
 the problem definition must
also be general enough that it
does not presuppose a solution
 the definition should be in the
user's language and from the
user's point of view
 the solution may turn out to be
something that is not related to
computers at all
The penalty for failing to define the problem
Requirements Prerequisite

Ensure :




The user's needs are driving the system, not the programmers
System scope is agreed upon
Minimal changes will be needed after construction begins
since requirements are never stable:





use the checklist on pages 33-34 of your text.
make sure that the cost of changes is understood
establish a good "change control" procedure
use an approach that accommodates changes
lastly you can always kill the project.
Without good requirements

you can have the right general problem but miss the mark on
specific aspects of the problem
Architecture Prerequisite


Buy versus build (market research)
System architecture




Major data structures
Functionality




Key algorithms that are present in the user requirements
User interface
Hardware requirements
Nonfunctional







why was a particular architecture chosen?
what things did we consider when we made our choices? (Cover your own butt)
Error processing
Robustness
Over engineering
Fault tolerance
Performance
usually means the average response time, which is system dependant
Strategy to handle changes
Without good software architecture

you may have the right problem but the wrong solution. It may
be impossible to have successful construction
Key Construction Decisions




Choice of Programming Language
Programming Conventions
Your Location on the Technology Wave
Selection of Major Construction Practices
Choice of Programming Language
Programming Conventions


Allows for more productive coding between
programmers on projects, as it provides a common
platform from which the system is built.
Before construction begins, spell out the programming
conventions you'll use. Coding-convention details are at
such a level of precision that they're nearly impossible to
retrofit into software after it's written.
Your Location on the Technology Wave

Programmers who program "in" a language



Programmers who program "into" a language


limit their thoughts to constructs that the language directly
supports.
If the language tools are primitive, the programmer's thoughts
will also be primitive.
first decide what thoughts they want to express, and then they
determine how to express those thoughts using the tools
provided by their specific language.
Most of the important programming principles depend
not on specific languages but on the way you use them
Selection of Major Construction Practices