chapter 8 structuring system requirements: logic modeling 9.1

38
Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Upload: scot-miller

Post on 11-Jan-2016

236 views

Category:

Documents


5 download

TRANSCRIPT

Page 1: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Chapter 8Structuring System

Requirements: Logic Modeling

9.19.1

Page 2: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Learning Objectives

Use Structured English as a tool for representing steps in logical processes in data flow diagrams

Use decision tables and decision trees to represent the logic of choice in conditional statements

Select among Structured English, decision tables, and decision trees for representing processing logic

9.29.2

Page 3: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Logic Modeling

Data flow diagrams are good for identifying processes but do not show the logic inside the processes

Logic modeling involves representing internal structure and functionality of processes depicted on a DFD. These processes appear on DFDs as little more than black boxes.

Logic modeling within a process means how data is transformed into information.

Logic modeling can also be used to show when processes on a DFD occur

Logic modeling will not reflect the structure or syntax of a particular programming language.

9.39.3

Page 4: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Logic Modeling

Deliverables and OutcomesStructured English representation of process

logicDecision Table representationDecision Tree representation

9.49.4

Page 5: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Structured English Modified form of English is used to specify the

logic of information processes Uses a subset of English

Action verbs (read, write, print , sort, move, merge etc Noun phrases No adjectives or adverbs

No specific standards; each analyst will have his or her own particular dialect of structured English

9.59.5

Page 6: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Structured English Structured English is used to represent all

three processes typical to structured programming: Sequence, conditional statements and repetition.

Sequence statements require no special structure but can be represented with one sequential statement following another.

9.69.6

Page 7: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Structured English Sequence Statements can be represented

Statement 1;

Statement 2;

Statement 3;

Page 8: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Structured English

Conditional statements can be represented as If conditions statementsSyntax

BEGIN IF IF condition 1

THEN statement 1

ELSE DO statement 2

ENDIF

Page 9: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Structured English

Case statementsREAD variableSELECT CASE CASE 1 condition1 statement 1 CASE 2 condition 2 statement 2 CASE 3 condition 3 statement 3 …………… CASE4 condition n statement nEND CASE

Page 10: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Structured English Repetition can take the form of DO-UNTIL loops or

DO - WHILE loops. A DO-UNTIL loop might be represented as follows:

DO READ variable(s) BEGIN IF

IF condition1 THEN statement 1 ELSE statement 2 END IFUNTIL End-of-file

Page 11: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Structured EnglishA WHILE- DO loop might be represented as

follows: READ variable(s)

WHILE NOT End-of-file DO

BEGIN IF IF condition1 THEN statement 1 ELSE statement 2 END IF

END DO

Page 12: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Structured English

Read Inventory recordsWHILE NOT End-of-file DO BEGIN IF IF Quantity-in-stock less than Minimum-order-

quantity THEN GENERATE new order ELSE DO nothing END IF END DO

Figure shows Structured English representation for Hoosier Burger inventory control system

Page 13: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Example

The Hoosier Burger Food ordering system generates two types of usage data, for goods sold and for inventory. At the end of each day, the manager Bob, generates the inventory report that tells him how much inventory has been used for each item associated with sales.

The amount shown on the inventory report is used as one input to a large inventory control system Bob uses every day.

Consider a Hoosier Burger’s inventory system, which has two sources of data outside the system: suppliers, the food ordering system inventory report.

Page 14: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

INVENTORY REPORTS

Page 15: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Example Consider a Hoosier Burger’s inventory system, which has two

sources of data outside the system: Suppliers, Stock-On-Hand

Supplier provides supplies and send invoices as input to the inventory system, and the system returns payments and orders as outputs to the suppliers. The inventory report from the Customer order system provides the count on how much stock has been used.

The processes involved in the inventory system are: Receive and Update the inventory data file as the supplier gives

the information about the no. of items supplied, on the invoices. Receive and update the inventory data file as the usage count

from the Stock On Hand is received Generate order based on the inventory level obtained from the

inventory file and the minimum Order Quantities( which is already stored in the Inventory data file)

Generate payment only to those supplier where the supply date is 30 days or greater than today’s date.

Page 16: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Items Minimum Order Quantity

Quantity Left Quantity added

Quantity in Stock = Quantity Left + Quantity added

Burgers 50 dozens 5 50 50+5 = 55

Buns 25 dozens 0 25 0+25 = 25

Straws 5 cases 10 0 10

Napkins 1 case 1 0 1

Page 17: Chapter 8 Structuring System Requirements: Logic Modeling 9.1
Page 18: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Structured English

Structured English process description mimics the format usually used in programming languages.

The filenames are connected with hyphens and the file names and variable names are capitalized.

Terms that signify logical comparisons, such as greater than and less than are spelled out rather than represented by arithmetic symbols

Structure English specifications are short if they describe lowest level DFD process.

Structured English resembles spoken English

Page 19: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Problems with Structured English to represent logic If a process’ logic is complex i.e. if several

different conditions are involved and the combinations of these conditions dictate which of the several actions should be taken, then Structured English may not be adequate for representing the logic behind such a complicated choice; rather becomes more difficult to understand and verify.

In such cases, a diagram may be much clearer than a Structured English statement.

Page 20: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Decision Tables

A decision table is a diagram of process logic where the decision logic is reasonably complicated.

It is a matrix representation of the logic of a decision

Specifies the possible conditions and the resulting actions in a tabular form

9.239.23

Page 21: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Consider a payroll system, which generates a payroll based on types of employees and number of hours worked.

Employees can be of two types Salaried “S” or Hours worked “ H”. Hours worked has three values

Less than 40 Exactly 40 More than 40

If an employee is salaried and hours worked <40, pay the base salary. If an employee is hourly based and hours worked <40, pay hourly wage

and produce absence report. If an employee is salaried and hours worked =40, pay the base salary. If an employee is hourly based and hours worked =40, pay hourly wage. If an employee is salaried and hours worked >40, pay the base salary. If an employee is hourly based and hours worked >40, pay hourly wage

and calculate overtime. There are four possible outcomes (actions)

Pay base salary Pay hourly wage Calculate Overtime Produce Absence Report

Page 22: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic withDecision Tables Consists of three parts

Condition stubs Lists various conditions relevant to the situation the

table is modeling.Action stubs

It contains all the possible courses of action that result from combining values of the condition stubs.

Rules It is a part of the table that links the conditions to

actions. It specifies which actions are to be followed for a given set of conditions9.259.25

Page 23: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Figure 9-4Complete decision table for payroll system example

9.269.26

Page 24: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Decision Tables Indifferent Condition

Condition whose value does not affect which action is taken for two or more rules.

Rule 5 has the same action as Rule 1 and 3, and governs behavior with regard to salaried employees. The number of hours worked does not affect the outcome for Rules 1,3, and 5. For these rules, hours worked is an indifferent condition in that its value does not affect the action taken.

Because of the indifferent condition for rules 1, 3, and 5, we can reduce the number of rules by condensing rules 1,3 and 5 into one rule , as shown in fig 9-5.

The indifferent condition is represented with a dash.

9.279.27

Page 25: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Fig. 9-5 Reduced decision table for payroll system example

Page 26: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Decision Tables Standard procedure for creating decision tables

Name the condition and all the values each condition can assume

Name all possible actions that can occur for different set of conditions

List all possible rules : To determine the number of rules, multiply the number of vales for each condition by the number of values for every other condition. In fig 9-4, we have two conditions, one with 2 values and one with 3 values, so we need 2 x 3 or 6 rules. If we add third condition with three values, we would needed 2 x 3 x 3 or 18 rules

Define the actions for each rule Simplify the decision table : Make the decision table a simple as

possible by removing any rules with impossible actions. Consult users on the rules where the system actions are not clear and either decide an action or remove the rule.

Page 27: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Decision Table – Example 1 Consider a Hoosier Burger inventory reordering

function. Reordering depends on number of seasons

Academic year Summer Season Spring Holidays

Academic Year : When there is an academic season check whether the item is perishable or non perishable. If an

item is perishable, such as meat, vegetables, milk etc., the inventory system has a standing daily order with a local supplier stating that a pre-specified amount of food is delivered each weekday for that day’s use and a standing weekend order with a local supplier each Saturday for weekend use.

If an item is non perishable, such as straws, cups and napkins, an minimum order quantity is placed when the stock on hand reaches a certain predetermined minimum reorder quantity.

Page 28: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Decision Table – Example 1

Hoosier Burger’s business is not as good during Summer, Christmas and spring break holidays as it is during the Academic year.

Summer Season The standing orders with all their suppliers are reduced

by specific amounts during the summer i.e. Summer reduction.

Holiday Season The standing orders with all their suppliers are reduced

by specific amounts during the holiday break i.e. Holiday reduction.

Given these conditions, draw a decision table.

Page 29: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Decision Table – Example 1

What can be the conditions: Type of item (P for Perishable and N for Non Perishable) Day of week (D for weekday and W for weekend) Season of year (A for Academic, S for Summer and H for holiday)

What can be the possible actions? Standing Daily Order Standing weekend order Minimum order quantity Holiday reduction Summer reduction

How many Rules are in this example? 2 x 2 x 3 = 12 Rules

Page 30: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Decision Tables

Page 31: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Decision Trees A graphical representation of a decision

situation Decision situation points are connected

together by arcs and terminate in ovals Two main components

Decision points represented by nodesActions represented by ovalsConnection between decision points by arcs

9.349.34

Page 32: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Modeling Logic with Decision Trees Read from left to right Each node corresponds to a condition (choice) The choices are spelled out in a legend for the diagram Each path leaving a node corresponds to one of the

options for that choice. From each node, there are at least two paths that lead to

the next step, which is either another decision point or an action.

Finally all possible actions are listed on the far right of the diagram in leaf nodes.

Each rule is represented by tracing a series of paths from the root node, down a path to the next node, and so on, until an action oval is reached.

9.359.35

Page 33: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Decision tree representation of the decision logic in the decision tables with only two choices per decision point

9.369.36

Page 34: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Decision tree representation of the decision logic

Page 35: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Deciding Among Structured English, Decision Tables and Decision Trees

Criteria Structured English

Decision Tables

Decision Trees

Determining Conditions and Actions

Second Best Third Best Best

Transforming Conditions and Actions into Sequence

Best Third Best Best

Checking Consistency and Completeness

Third Best Best Best

9.389.38

Page 36: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Summary

Several methods of logic modelingStructured English

Primarily communication technique for analysts and users

Decision Tables Conditions are listed in condition stubs Possible actions are listed in action stubs Rules link conditions with actions

9.399.39

Page 37: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Summary

Decision TablesLists all possible rules

Decision TreesConditions are portrayed by decision pointsValues are represented by paths between

decision points and ovals that contain actions

9.409.40

Page 38: Chapter 8 Structuring System Requirements: Logic Modeling 9.1

Summary

Comparison of Structured English, Decision Tables and Decision TreesMost studies show that decision trees are

best for many criteriaThere is no best techniqueAnalyst must be proficient in all three

9.419.41