CS 325: Software Engineering

March 5, 2015

Modeling and Design of Rule-Based Systems

• Rule-Based Systems• Interpreter Pattern• Code Reviews

CS 325March 5, 2015Page 2

Rule-Based SystemsSome software systems are set up to make decisions via a (occasionally convoluted) set of rules.Consider a university’s computer science department , which uses a set of admission criteria to process applications to its graduate program. Applications that clearly satisfy all of the admission criteria are classified as “accepted”; those that do not satisfy the criteria are classified as “rejected”; and the remaining applications are marked as “pending”.

• The applicant must have paid the application fee. • The applicant must have a four-year undergraduate

degree in a technical area.• The applicant must have at least a 3.2 GPA on a 4.0 scale

in the last two years of undergraduate course work.• The applicant’s undergraduate degree is ranked (high,

average, or low) based on its relevance to the CS curriculum.

• The applicant’s undergraduate degree-granting institution is ranked (high, average, or low).

• The applicant must have a sum of verbal and quantitative scores of at least 1,150 on the GRE with a quantitative score of at least 700 and a verbal score of at least 400.

• International applicants must have a score of at least 90 on the TOEFL Internet-Based Test or a score of at least 7.0 on the International English Language Testing System (IELTS).

CS 325March 5, 2015Page 3

Rule-Based SystemsThese rules can be concisely represented in a decision table. 1 2 3 4 5 6 7

Is fee paid? Y N Y Y Y Y Y

UG degree relevant to CS? H - - H A L -

UG institution rank? H - - A H - L

All other conditions satisfied? Y - N Y Y Y Y

Rule count 1 18 9 1 1 3 3

Accepted X

Rejected X X X

Pending investigation X X

Wait for fee paid X

CS 325March 5, 2015Page 4

Rule-Based SystemsTo facilitate viewing the rule-based system as a software system, a grammar is defined to give the rules a syntax.rule-set ::= rule [rule]

rule ::= condition-list '==>' action ';'condition-list ::= condition [‘&’ condition-list]condition ::= condition-name ‘=’ condition-valueaction ::= ‘accept’ | ‘reject’ | ‘pending’ | ‘wait’condition-name ::= ‘fee-paid’ | ‘relevance’ | ‘inst-rank’ | ‘all-other’condition-value ::= ‘Y’ | ‘N’ | ‘H’ | ‘A’ | ‘L’Legend:

::= defined as‘abc’ literal abc[abc] abc is optionala | b selectively a or b

CS 325March 5, 2015Page 5

Rule-Based SystemsThe grammar translates in a straightforward manner into a class diagram, and an actual implementation follows.

CS 325March 5, 2015Page 6

Interpreter PatternSome programs benefit from having a language to describe operations that they can perform.The Interpreter Pattern generally describes defining a grammar for that language and using that grammar to interpret statements in that language.

Constant

evaluate(context)

ANDExpression

Operand1 : BooleanExpressionOperand2 : Boolean Expression

evaluate(context)

BooleanContext

VariableNames[]VariableValues[]

Client

ORExpression

Operand1 : BooleanExpressionOperand2 : BooleanExpression

evaluate(context)

NOTExpression

Operand : BooleanExpression

evaluate(context)

BooleanExpression

evaluate(context)

For example, a Boolean Expression is either a terminal expression (a Constant) or a compound expression (an AND, OR, or NOT Expression).A Boolean Expression is interpreted in the context of its variable names and values.For instance, the Boolean Expression (X AND NOT Y) OR Z in the context of (X,Y,Z) = (true, false, false) evaluates to eval(X AND NOT Y) OR eval(Z), which is (eval(X) AND eval(NOT Y)) OR false, which evaluates to (true AND NOT eval(Y)), which is NOT(false), resulting in an evaluation of true.

CS 325March 5, 2015Page 7

Interpreter PatternAs another example, consider Roman NumeralsReading left to right, a Roman Numeral can be interpreted via four “sub-interpreters”.

First, the thousands characters (the leading “M” characters) are read. This is followed by the hundreds characters (either a 900-sequence “CM”, a 400-sequence “CD”, or an optional 500-sequence “D” followed by zero to three 100-sequences “C”). The tens and ones characters are handled similarly.

One

one()four()five()nine()multiplier()

Context

UnparsedStringCumulativeParsedValue

Client

Ten

one()four()five()nine()multiplier()

Hundred

one()four()five()nine()multiplier()

Thousand

one()four()five()nine()multiplier()

RomanNumeralInterpreter

onestenshundredsthousands

one()four()five()nine()multiplier()

Notice that all of the derived “expressions” are terminal.

CS 325March 5, 2015Page 8

Interpreter Pattern• When a program presents a number of different,

but somewhat similar, cases with which it must contend, it can be advantageous to use a simple language to describe these cases and then have the program interpret that language.

• Recognizing cases where the Interpreter Pattern can be helpful can be problematic, and programmers who lack training in formal languages or compilers often overlook this option.

• One fairly obvious place where languages are applicable is when the program must parse algebraic strings in order to carry out operations based on the computation of user-entered equations.• A far more useful situation that uses the

Interpreter Pattern is when the program produces varying kinds of output (e.g., generating reports based on a database without having to resort to elaborate SQL queries).

CS 325March 5, 2015Page 9

Code ReviewsWhile there are many aspects to software quality, one particularly important emphasis is on the elimination of defects.Rationale: If the software doesn’t work right, other quality issues are irrelevant.

How can defects be effectively eliminated?Since low defect content is best achieved where the defects are injected, software engineers should:•remove their own defects

•determine the causes of their defects

•learn to prevent those defectsWhen should the defects be eliminated?Rather than waiting until late in the development process (i.e., during testing, when locating and correcting defects is difficult and expensive), modern processes advocate eliminating defects during code review (and possibly even design review).

CS 325March 5, 2015Page 10

Code ReviewsDefects are injected primarily during the code phase, with the design phase at second place and the requirements phase a distant third.

Repaire

d: R

equire

men

ts

Repaire

d: D

esign

Repaire

d: C

ode

Repaire

d: T

est

Repaire

d: In

tegr

ation

Repaire

d: C

usto

mer

050100150200250300350400

Injected: RequirementsInjected: Design

Injected: CodeInjected: Test

Injected: Integration

15

10

50

130

368

12

1026

64

15

1337

13

7

13

Injected: Require-mentsInjected: DesignInjected: CodeInjected: TestInjected: Inte-gration

Defects are removed primarily

during the code phase,

with the expensive test phase at second place and the much

cheaper design

phase a distant

third.

CS 325March 5, 2015Page 11

Code ReviewsIn testing, you must • detect unusual behavior• figure out what the test program was doing

• find where the problem is in the program

• figure out which defect could cause such behavior

With reviews and inspections, you • follow your own logic• know where you are when you find a defect

• know what the program should do, but did not

• know why this is a defect• are in a better position to devise a correct fix

CS 325March 5, 2015Page 12

Code ReviewsResource defects refer to mistakes made with data,

variables, or other resource initialization,

manipulation, and release.

Check defects are validation mistakes or mistakes made when detecting an invalid

value.

Interface defects are mistakes made when interacting with other parts of the software,

such as an existing code library, a

hardware device, a database, or an

operating system.

Logic defects are made with comparison

operations, control flow, and

computations and other types of logical

mistakes.