2. CS 325: Software Engineering March 5, 2015 Modeling and Design of Rule-Based Systems Rule-Based Systems Interpreter Pattern Code Reviews

3. CS 325 March 5, 2015 Page 147 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 Internet- Based Test or a score of at least 7.0 on the International English Language Testing System (IELTS).

4. CS 325 March 5, 2015 Page 148 Rule-Based Systems These rules can be concisely represented in a decision table. 1234567 Is fee paid?YNYYYYY UG degree relevant to CS?H--HAL- UG institution rank?H--AH-L All other conditions satisfied?Y-NYYYY Rule count11891133 AcceptedX RejectedXXX Pending investigationXX Wait for fee paidX

5. CS 325 March 5, 2015 Page 149 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

6. CS 325 March 5, 2015 Page 150 Rule-Based Systems The grammar translates in a straightforward manner into a class diagram, and an actual implementation follows.

7. CS 325 March 5, 2015 Page 151 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.

8. CS 325 March 5, 2015 Page 152 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.

9. CS 325 March 5, 2015 Page 153 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).

10. CS 325 March 5, 2015 Page 154 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).

11. CS 325 March 5, 2015 Page 155 Code Reviews Defects are injected primarily during the code phase, with the design phase at second place and the requirements phase a distant third. 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.

12. CS 325 March 5, 2015 Page 156 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

13. CS 325 March 5, 2015 Page 157 Code Reviews