Describing Process Specifications and Structured Decisions

1
Describing Process Specifications and
Structured Decisions
2
What weve covered in lectures Software
engineering basics and frameworks SDLC and its
different approaches Requirements
analysis (Problem statement- Vord method
requirements specification- Requirements
documentation) Structured techniques (DFD ,
context diagram) What weve covered in reading
and chunks Coupling and cohesion ,more
structured techniques and basics of structured
analysis and design
3
What we still need to cover in lectures and
readings Data dictionary , decision tables and
decision trees Plus ERM modeling Structured
charts and transformation analysis Coupling and
cohesion ( class review) Object oriented
analysis User interface design Project
management Architectural design
4

• Purpose of Process Descriptions
• Communication between designer and programmer.
• Ensures a concise, unambiguous statement of
  requirement.
• Becomes part of overall system documentation.

5

• Choosing a Structured Decision Technique
• Use Structured English if many repetitive
  actions.
• Use Decision Tables if complex combinations of
  conditions, actions and rules.
• Use Decision Trees when the sequence of
  conditions and actions is important.

6

• Structured English Constructs
• 3 constructs
• sequence, selection, repetition/iteration
• Sequence actions which take place one after the
  other.
• Find a teapot
• Put in the tea
• Pour in boiling water

7

• Structured English Constructs
• Selection IF-THEN-ELSE construct
• IF condition A
• THEN action B
• ELSE action C
• ENDIF

8
Structured English Constructs IF you like tea
THEN drink tea ELSE drink coffee ENDIF
9

• Structured English Constructs
• Repetition a block of statements that are
  repeated until some condition is met.
• DOWHILE there are customers greet the customer
  hand over the goods take the money run ENDDO

10
Structured English The following scenario is
described by a clerk, who carries out the task of
pricing the orders I get the stack of orders
to price. I go through the orders one by one
until I have priced them all. I price each item
on the order in turn by consulting the sales
catalogue. Sometimes I cannot find the item
because it is a new product and I then have to
look at the supplement. If I have no luck there,
I put a question mark on the form. Then I put the
priced order in the out tray. When all the
orders have been priced, I take the stack from
the out tray and place it in the credit control
sections in tray. Write Structured English for
the pricing process described above.
11
Structured English Get stack of orders DOWHILE
there are orders in the stack get the top order
DOWHILE there are un priced items on the order
get next un priced item IF item is in the
catalogue THEN write item price on the order
ELSE IF item price is in the supplement
12
THEN write item price on the order ELSE write ?
on the order ENDIF ENDIF ENDDO put order
in the out tray ENDDO get the stack from the
out tray put the stack in the credit control
sections in tray
13
(No Transcript)
14


15
(No Transcript)
16

• Advantages
• Allows us to construct complex descriptions of
  business policy.
• Concise, precise and readable.
• Can be written quickly.
• Can be co-ordinated to the DD and DFD to check
  consistency.

17

• Decision Trees
• Distinguish between conditions and actions.
• Identify all conditions and actions and the
  ORDER.
• Identifies the decision paths at each node.
• Each node represents a question.
• Answers are TRUE or FALSE.
• Build tree from left to right.

18
(No Transcript)
19
(No Transcript)
20
(No Transcript)
21


22

• Decision Tables
• A method of laying out conditions and actions in
  a table format.
• A concise way of representing the logic of a
  process.
• Shows actions to be taken under differing
  combinations of conditions.

23
Decision Tables A decision table is a table
composed of rows and columns, separated into four
separate quadrants.
The upper left quadrant contains the conditions.
The upper right quadrant contains the condition
rules ofr alternatives. The lower left quadrant
contains the actions to be taken and the lower
right quadrant contains the action rules.
24

• Decision Tables
• Easily understandable.
• Unmatched for clarity and precision.
• Use if
• selection of applicable action is dependent on a
  number of conditions.

25

• Problems With Use
• May be hard to know where to begin with a
  decision table formulation.
• Users unfamiliar with them. Call it a table that
  describes a particular situation.

26

• Developing Decision Tables
• Determine the conditions affecting the decision.
• (rows in top half of table)
• Determine number of possible actions.
• (rows in bottom half of table)

27

• Developing Decision Tables
• A rule describes the action to be carried out for
  a specific combination of values of the
  conditions.
• At least one action must be specified for each
  rule.

28

• Developing Decision Tables
• If we have an application with 3 conditions,
• we will need ? distinct rules
• 2x2x2 8 rules

29

• Developing Decision Tables
• Create empty decision table.
• List all conditions and actions on left hand
  side.
• Number combinations of conditions along top of
  the table.
• List all the combinations of conditions, one for
  each vertical column in the table.
• For each column, identify the action to be taken.

30

• Developing Decision Tables
• You are the Green-Keeper at a golf club. If the
  grass is too long, cut it. If there are weeds,
  apply weed-killer. Otherwise, sit in a chair and
  enjoy the sun.
• Grass too long Y Y N N
• Weeds Y N Y N
• Cut grass X X - -
• Apply weed killer X - X -
• Sit down - - - X

31

• Each condition has 2 values.
• Each condition has 2 values.
• Therefore no. of rules is 4.

32

• Rationalizing Decision Tables
• Can reduce DTs by combining columns.
• Combine rules where the condition does not affect
  the action.

33

• Decision Tables
• Must discuss each rule with the user.
• Common the user has not thought about certain
  combinations of conditions.
• Advantage of decision tables is that you can
  concentrate on one rule at a time.

34
(No Transcript)
35
(No Transcript)
36
(No Transcript)
37
An Example A store wishes to program a decision
on non-cash receipts for goods into their
intelligent tills.The conditions to check are
agreed as 1. Transaction under 502. Pays by
cheque with cheque card (guarantee 50)3. Pays
by credit card The possible actions that a
cashier could take are agreed as 1. Ring up
sale2. Check credit card from local database3.
Call a supervisor4. Automatic check of credit
card company database
38
The condition rules are yes or no, therefore the
number of possible condition rules are 2
alternatives for condition 1 x 2 alternatives for
condition 2 x 2 alternatives for condition 3 or 2
3 8
39
We can see that some of the condition rules are
invalid, the customer cannot pay by cheque AND
pay by credit card or not pay by either method.
We have decided that these combinations are
mutually exclusive. This decision table can be
reduced to 4 condition rules.
40
Indicate the actions.
41
What if the customer has not shopped their
before? Missing some as obvious as this means
reconstructing the table!
42
The conditions are now 1. Transaction under
502. Pays by cheque with cheque card (guarantee
50)3. Pays by credit card4. Unknown
customer The actions remain the same but the
number of condition rules increases by a multiple
of 2.
43
(No Transcript)
44
(No Transcript)
45
(No Transcript)
46
TheDATA DICTIONARY(for DFDs)

• Concepts and Examples

47
Data Dictionary

• part of the specifications for a complete
• Dataflow Analysis (DFD)
• ER model
• OOAD model
• SADT
• etc.

48
Data Dictionary for a DFD

• specifies data elements in a DFD
• data flows
• simple data stores
• must be consistent with DFD
• specification compatible with diagram
• must be complete with regard to the DFD
• consists of data item specifications

49
Data Item Specification

• name (and aliases)
• informal description
• purpose
• range of values
• related data items
• connections to processes (flow information)
• formal data structure specification

50
Patient Data Record

• name patient data record (PDR)
• description
• A PDR is produced by the Patient Monitoring
  System and includes information on the current
  status of a specific patient in the intensive
  care unit, e.g. blood pressure, temperature, etc.
• A PDR is produced every five minutes.

51
Patient Data Record

• purpose
• Used to feed the Patient DB with up-to-date
  information on each patient.
• PDRs are accumulated, i.e. the average value of
  all received readings during a full hour is
  stored.
• range of values
• see specifications of PDR sub-elements

52
Patient Data Record

• related data items
• derived items
• PDR -
• Patient Input
• is-part-of
• N/A
• (PDR has no super-ordinate element)

53
Patient Data Record

• related data items
• is-decomposed-into (sub-ordinate elem.)
• patient-id
• patient-name (first and last)
• heart-rate
• temperature
• blood-pressure (optional)

54
Patient Data Record

• related data items
• is-decomposed-into (continued)
• status (critical or non-critical)
• delta values for
• heart-rate, temperature, blood-pressure
• as calculated during the last hour
• comparing to the full hour value
• (minimum 1, maximum 12)

55
Patient Data Record

• connections to processes
• comes from
• Patient Monitoring System
• (external source)
• goes to
• check accum. PDR
• (system internal process)

56
Formal Data Structure Definition?

• BNF - Backus-Naur-Form
• formal language
• context free grammar
• based on substitution rules
• widely used to specify syntax of programming
  languages

57
BNF

• rules used to specify substitution/refinement/stru
  cturing
• data-item gt data-structure
• person gt name address
• name gt first_name last_name

58
BNF

• meta-symbols used to describe structure
• sequence
• ......... exclusive alternatives
• ... iteration (gt1 repetitions)
• ( ... ) option

59
Patient Data Record - BNF

• formal structure specification

• PDR gt p_id p_name c_val status d_val
• p_name gt first_name last_name
• c_val gt heart_rate temp ( blood_pressure )
• status gt critical non-critical
• d_val gt d_heart d_temp ( d_blood )

60
(No Transcript)
61
(No Transcript)
62
(No Transcript)