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