CS 325: Software Engineering
March 3, 2016
Modeling and Design of Rule-Based Systems
•
•
•
Rule-Based Systems
Interpreter Pattern
Code Reviews
Rule-Based Systems
Some 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 InternetBased Test or a score of at least 7.0 on the International English Language
Testing System (IELTS).
CS 325
March 3, 2016
Modeling and Design of Rule-Based Systems
Page 147
Rule-Based Systems
These 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
X
X
Rejected
X
Pending investigation
Wait for fee paid
CS 325
March 3, 2016
Modeling and Design of Rule-Based Systems
Page 148
X
X
X
Rule-Based Systems
To 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-value
action ::= ‘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 optional
a | b selectively a or b
CS 325
March 3, 2016
Modeling and Design of Rule-Based Systems
Page 149
Rule-Based Systems
The grammar translates in a straightforward manner into a
class diagram, and an actual implementation follows.
CS 325
March 3, 2016
Modeling and Design of Rule-Based Systems
Page 150
Interpreter Pattern
Some 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.
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 325
March 3, 2016
Modeling and Design of Rule-Based Systems
Page 151
Interpreter Pattern
As another example, consider
Roman Numerals
Reading 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.
Notice that all of the derived “expressions”
are terminal.
CS 325
March 3, 2016
Modeling and Design of Rule-Based Systems
Page 152
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 325
March 3, 2016
Modeling and Design of Rule-Based Systems
Page 153
Code Reviews
While 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 defects
When 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 325
March 3, 2016
Modeling and Design of Rule-Based Systems
Page 154
Code Reviews
Defects are injected primarily during the code phase, with
the design phase at second place and the requirements
phase a distant third.
368
400
350
300
250
130
200
64
50
150
26
37
100
10
10
13
50
0
5
Injected: Requirements
2
7
1
5
1
Injected: Design
3
1
3
1
Injected:
Code
1
Injected: Test
Injected: Integration
Injected: Requirements
Injected: Design
Injected: Code
Injected: Test
Injected: Integration
CS 325
March 3, 2016
Modeling and Design of Rule-Based Systems
Page 155
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.
Code Reviews
In 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 325
March 3, 2016
Modeling and Design of Rule-Based Systems
Page 156
Code Reviews
CS 325
March 3, 2016
Modeling and Design of Rule-Based Systems
Page 157