Software Maintenance
and Evolution
CSSE 575: Session 6, Part 1
Below – The new book we’ll be using for
the next lectures. Above – Feathers.
The “SEAM” Model
Steve Chenoweth
Office Phone: (812) 877-8974
Cell: (937) 657-3885
Email: [email protected]
1
The Seam Model
• A basic skill in software
maintenance – figuring out
effective ways to test it.
– Unit and integration testing
Above – Seams in action – From
Steven Ellis’s site on how to
throw a fastball.
http://www.stevenellis.com/steve
n_ellis_the_complete/2007/06/ho
w_to_throw_a_.html.
• There are several ways
in which a method, say,
tends to resist testing.
• The Seam Model gives a systematic way
around those problems.
2
A huge sheet of text
• When you start looking at code
you aren’t already familiar with,
this is what it is!
• The goal is to find interesting
places to study in depth
– Analyze for possible problems
– Try making changes
Above – source code that played a role in a
Minnesota court case over the legitimacy of
breath test results. What does it do?
http://www.mndwidefenseblog.com/2009/05/articl
es/source-code/court-of-appeals-rips-the-lid-offdwi-intoxilyzer-source-code-issue/
• But if the code can’t be unit tested easily, how can
you actually run it and see what it does?
3
A “Seam” Example
• Feathers shows a method in C++, which could be
run in a unit test, except for the line –
PostReceiveError(SOCKETCALLBACK, SSL_FAILURE);
which calls a tricky-to-include-in-testing external
function.
• What are the options here – without changing
any of the lines in this method itself?
4
The rest of the method would
be much easier to set up
NUnit style unit tests for,
except this one line!
5
6
“Seam” Options, in summary
• Postprocessing: We can change, for testing,
what external code gets linked here.
• Preprocessing: This happens to be C++ code,
and so you could do some “#” macro that
changes what happens in the call.
• Object substitution: We can make objects for
testing, like a subclass that overrides what
gets called here.
7
“Seam” Goal 1 – Unit Testing
• Find a way to alter the behavior of some code,
without changing the code itself.
• For testing - Usually applied to code that causes
trouble if run as intended, like for unit testing.
Examples:
– Communications calls
– Database calls
– GUI calls
• This gives you “test” versions of your software,
which are easier to run without messing with
these external entities.
8
“Seam” Goal 2 – Enhancements
• Find a way to enhance the behavior of some
code, without changing the code itself.
• For adding features - Usually applied to code
that you want to “do more” without altering
this class or method.
• This gives you easy ways to make
enhancements, without adding bugs into the
existing code.
9
These are key strategies!
• If you can find ways to do these things
systematically with your code, it means:
– More timely testing
– Easier ways to guess difficulty in changing and
enhancing the code
– Understanding what’s easy and hard, in terms of
choices for how to change it
10
The SEAM model extends…
• OCP - The “Open-closed principle” of OO:
– Software entities (classes, modules, functions, etc.) should
be Open for extension, but Closed for modification.
– Question Feathers asks - Can we apply this principle to
extending these entities for testing?
– Put another way – If we have to alter the code
substantially to do anything like a unit test, we’re on a slow
boat to China!
– Goal – “Change the code
without changing the code!
11
And the SEAM model uses…
• DIP The “Dependency Inversion
Principle” of OO:
– Depend upon abstractions. Do not
depend upon concretions.
– We should couple at the abstract level,
not at the concrete level.
• E.g., try not to refer to concrete classes
directly
• In this case, is there a way that the test
versions and the production versions of the
code can be based on an abstract version of
both?
– We’ll discuss DIP some more in the next
slide set.
Above – Yes, “concretion”
is a word! Here’s one
now.
12
And has a lot to do with…
• LSP – The “Liskov substitution principle”:
– Let q(x) be a property provable about objects x of
type T. Then q(y) should be provable for objects y
of type S where S is a subtype of T.
– I.e., subtypes don’t alter
any of the desirable
properties of their
parents!
13