CSE403 Software Engineering,
Autumn 1999
Gary Kimura
Lecture #10 Notes
Design workshop
1)
Design workshop
a)
Today,
in small groups, we’re going to design a screen based calculator
b)
We’ll
have a simple well understood set of requirements
c)
Afterwards
we’ll examine and critique each design
d)
This
should be a learning process where if we can identify some of the good and bad
points then you can apply this to your TAG 2000 design.
2)
Requirements of the calculator
a)
Look
and feel just like a really cheap calculator but on a monitor
i)
One
accumulator display (10 characters wide)
ii)
A
10 keypad (‘0’, ‘1’, ‘2’, ‘3’, ‘4’, ‘5’, ‘6’, ‘7’, ‘8’, ‘9’, ‘.’)
iii)
Operations
keys for
(1)
+/-
(2)
/
(3)
*
(4)
–
(5)
+
(6)
sqrt
(7)
%
(8)
1/x
(9)
=
(10)
MC
(11)
MR
(12)
MS
(13)
M+
(14)
C
(15)
CE
(16)
Backspace
b)
Data
is entered two ways
i)
Via
the mouse by touch individual calculator keys
ii)
Via
the keyboard by entering the appropriately assigned keys
3)
Things to consider in the design
a)
Determine
how to communicate or specify the design
i)
The
format used to specify a design is often a matter of personal choice
ii)
Let’s
start the calculator using functional block diagrams that are described and
connected with English prose
iii)
As
time permits we can give the detailed interface
b)
A
broad stroke design and understanding is needed before tunneling down to the
details (i.e., don’t sweat the details until it’s time)
c)
My
preferred method is usually to start top-down, then go bottom-up, back to
top-down, and so forth
d)
Realize
that any design will never be perfect, and when later stretched it may break
e)
Keep
the design as clean and simple as possible
f)
Make
sure there is a way the system can be tested
g)
Even
though the requirements are simple the design needs to anticipate change
i)
A
well-structured design using information hiding can make changes easier to
incorporate. Think about the
algorithmic and structural hiding that can be done.
ii)
In
doing a design we often need to postpone adding a feature to Version 1 of a
product, but that doesn’t mean we can ignore how postponed features will be
added at a later date. The calculator
has many additional features that a good design should not exclude. For example
(1)
Multiple
bases (e.g., binary and hexadecimal)
(2)
Arbitrary
precision arithmetic
(3)
Multiple
accumulators
(4)
A
help system
(5)
Mimic
a paper-tape adding machine
(6)
Trigonometry
functions and other advanced calculations
h)
To
make the problem more tractable lets assume that the calculator will run on a
PC, and we are provided with a graphics package and an input package with some
kind of event driven model. That is,
the calculator can be a single threaded app that polls or waits for events, or
it can be a more “thread-less” model where an event executes a set of
instructions. The choice is yours.
4)
Let’s now break in groups and design a calculator
a)
Rough
out a high level architectural design (the napkin design)
b)
Then
tunnel down on the details