View
213
Download
0
Category
Preview:
Citation preview
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.
Recommended