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