CSE403 Software Engineering,
Autumn 1999
Gary Kimura
Lecture #11 Notes
Design workshop Continued
1)
Design workshop
a)
Today,
we’ll examine the calculator designs we worked with on Monday
b)
But
first, TAG 2000 project reviews tomorrow during quiz sections
c)
Then
we’ll quickly review your calculator designs
d)
Then
we’ll look at the design for the window’s calculator
e)
Finally
we’ll look at some alternate design considerations
2)
TAG 2000 Project reviews tomorrow
a)
10
minute presentation
b)
Accomplishments
during the previous two weeks
c)
A
schedule (or revised schedule) of milestones for the project
d)
Tasks
for the next two weeks
e)
Any
blocking issues
f)
Friday
design drafts documents are due
3)
Now the designs we did on Monday
4)
A look at the existing windows calculator
a)
Some
quick facts
i)
Written
in C
ii)
26
total files (14 C files, 8 header files, 4 ancillary files)
iii)
5008
source lines (2679 lines of code)
b)
Basic
Logical Structure
i)
Startup,
initialization, and main procedure
(1)
The
main procedure is input driven
(2)
Each
keystroke, mouse key click, and menu click invokes the main procedure
ii)
Display
the calculator module (keys, etc.)
iii)
Computational
packages (mostly infinite precision)
(1)
Normal
math functions
(2)
Trig
functions
(3)
Other
operations such as (shift left, etc)
iv)
Input
module
(1)
Mimic
calculator keys (‘0’, … , ‘9’, ‘.’, backspace, exp, etc.)
(2)
Knows
which keys are valid given its current state
v)
Display
the accumulator module
vi)
Watchdog
logic to terminate long running operations
vii)
Set
various calculator modes module (e.g., base)
viii)
Miscellaneous
modules
(1)
Debug
support
(2)
Unicode
support
(3)
Statistics
c)
Some
design/implementation issues
i)
Converting
strings to integers back to strings
ii)
Switching
calculator mode was an obvious add-on to the structure
iii)
Rounding
epsilon to zero
iv)
Single
display error routine
v)
Debugging
the calculator by replacing the input module to run a script and capturing its
output.
vi)
What
about timing tests?
5)
A few alternate ways of looking at this problem
a)
The
calculator has a main loop that waits for an input action before calling
routines to do the computation and then display the output
i)
Note
that state information can be augmented by the main loop program counter
ii)
This
is a fairly monolithic architecture
b)
The
calculator is conceptually a box containing state information (e.g., three
accumulator registers, one visible register, one the hidden register, and one
the Memory register, also last key entered, etc.)
i)
Connected
to the calculator state are an input module, display module, computation
module, etc.
ii)
Each
individual input event (i.e., a keystroke) alters the state of the calculator,
which in turn drives the computational and display module. The flow of control can either be
(1)
Each
event starts a new flow of control. The
input module modifies the calculator state, calls the computational module, and
then the display module. Thus a decimal
digit adds the digit to the displayed register state, the computational module
does nothing, and the display module puts out the digit unless there was a
display overflow.
(2)
Each
event starts a new flow of control. The
input module modifies the calculator state, but gets back a vector of
additional routines to call. Thus a
decimal digit adds the digit to the display state and then returns only a
display function to be called.
iii)
There
is really no main loop or control module which means that with proper locking
simultaneous access to the calculator state is possible
iv)
An
extra thread can also be used to terminate wayward operations
c)
The
calculator can be table driven
i)
Indexed
by each input character or event
ii)
Each
row in the table specifies an action to perform (most of the keys will have a
default noop and/or invalid action)
iii)
There
are support modules for display update, math functions, etc.
iv)
The
design of this calculator is fairly extensible