Updated 27 March 2013

CS3202 Iteration and Assignment 4

Updates (mainly Definition 1, p. 5) highlighted in red color. Due date: Thursday, 18 April, by 12 noon. Grace period: 2 hours. We accept your report without penalty until 2 pm. If you submit report: Between 2 pm on due date and 2 pm one day later, penalty is 5 points (out of your grade for basic SPA) After that we wont accept your report, and penalty is 20 points (out of your grade for basic SPA). Deliverables: Please refer to final submission guidelines (to be posted)

Extensions for Bonus Marks

1. General requirements and guidelines
Below we suggest two extensions that you may implement for bonus points, namely extended patterns and inter-procedural Affects, called AffectsBip (Bip stands for branch into procedures). Pattern extensions are simpler to implement than AffectsBip. We highly recommend that you implement simplified inter-procedural AffectsBip (Section 3.2) first, before implementing full-blown AffectsBip (Section 3.3).

2. Extension 1: Extended code patterns

First we extend design abstractions of SIMPLE by adding new relationships Contains, Contains*, and Sibling between AST nodes. Definitions Let tn1 and tn2 be any AST nodes: Contains (tn1, tn2) holds if tn2 is a child of tn1 (i.e., tn2 appears directly below tn1 in AST) Contains* (tn1, tn2) is a transitive closure of Contains Sibling (tn1, tn2) holds if tn1 and tn2 are two different children of the same node in AST Notice that the order in which tn1 and tn2 appear in AST is irrelevant for Sibling relationship Example: SIMPLE source program procedure Bill { 1. 2. 3. 4. 5. 2.1 x = 5; call Mary; y = x + 6; x = 5; z = x * y + 2; } procedure Mary { 6. y = x * 3; 7. call John; 8. z = x + y; } procedure John { 9. if i then { 10. x = x + z; } else { 11. y = x * y; } }

Examples of PQL queries with Contains, Contains*, and Sibling

Queries refer to the above source program. procedure p; stmt s; stmtLst then, else; if ifStmt; while w; assign a; plus add; variable v, v1; constant c; Select v such that Contains (ifStmt, v) -- returns all the variables that control some if statement Select v such that Contains (ifStmt, v) and Contains* (p, ifStmt) with p.procName=Bill -- as above, but in addition if statement must be in procedure Bill Select a such that Contains* (a, v) with v.varName=x returns all the assignments that refer to variable x (either on the left- or right-hand-side) Select p such that Contains* (p, c) with c.value=2 returns all the procedures that refer to constant 2 Select a such that Contains* (a, add) and Contains* (add, v) with v.varName=x - returns all the assignments with plus nodes that refer to variable x (either on the left- or right-hand-side of plus) Select p such that Contains* (p, ifStmt) and Contains* (ifStmt, w) return all procedures in which while is nested in if statement Select s such that Contains* (9, s) -- the same as Parent* (9, s) Select BOOLEAN such that Contains* (9, 10) -- true if statement 10 is nested in statement 9 Select v such that Contains* (10, v) returns all variables referred to in statement 10 Select s such that Sibling (s, 4) -- returns any s such that Follows*(s, 4) or Follows*(4, s) Of course, Contains, Contains*, and Sibling can be mixed with all other relationships implemented in the basic SPA, for example: Select v such that Contains (ifStmt, v) and Modifies (Main, v) pattern ifStmt(i, then, else) such that Contains (then, w) and Contains (else ifStmt)

2.2

Allowable arguments of relationships Contains, Contains*, and Sibling in PQL

Rules are more restrictive than for other relationships to avoid ambiguities. The arguments in relationships Contains, Contains*, and Sibling can be as follows: 1) A synonym of a syntactic type in SIMPLE (see abstract syntax grammar of SIMPLE). These syntactic types are types of AST nodes (any design entity except prog_line): NodeType : procedure | stmtLst | stmt | assign | call | while | if | plus | minus | times | variable | constant 2) Underscore _ cannot be used in relationship Contains and Sibling as this leads to ambiguities (i.e., it is not clear which design entity we refer to). 3) An integer can be used as an argument and then it is interpreted to be a statement number. 4) A synonym of prog_line can be used as an argument and then it is interpreted as a statement number. 2.3 PQL grammar extensions Please refer to Appendix A for PQL grammar for basic SPA. Modified PQL grammar rules: pattern : assign | while | if // _ can be used for stmtLst in patterns if and while, but INTEGER cannot be used: stmtLstRef : synonym | _ if : synonym ( varRef , stmtLstRef , stmtLstRef ) // synonym above must be of type if while : synonym ( varRef , stmtLstRef ) // synonym above must be of type while New PQL grammar rules: nodeRef : synonym | INTEGER Contains : Contains ( nodeRef , nodeRef ) ContainsT : Contains* ( nodeRef , nodeRef ) Sibling : Sibling ( nodeRef , nodeRef ) Synonyms that can appear in query results: IDENT listed in query result must be a synonym of a design entity that can be identified by name, value or statement/program line number only, i.e.,: procedure | stmtLst | stmt | assign | call | while | if | variable | constant | prog_line The query result is to be shown as follows: in case of procedures: a procName, in case of statements: an integer stmt#, in case of stmtLst: a stmt# of the first statement in the list, in case of variable: a varName, in case of constant: a value (integer), and in case of prog_line: a program line number (integer).

Type checking: Identify all such static semantic errors in Query Validator and report errors to avoid nasty errors during query evaluation. In addition to synonyms listed in query result, many other situations require type checking. For example, Contains* (a, 2) where a is assign is syntactically correct, but integer 2 is not valid argument in this context.

3. Extension 2: Affects and Affects* Inter-procedural

Inter-procedural AffectsBip (a1, a2) is defined between assignments in the same or in different procedures (Bip stands for branch into procedures). For two assignment statements a1 and a2 in the same procedure, if there are no procedure calls on any control path between a1 and a2, AffectsBip (a1, a2) = Affects (a1, a2) However, if there are procedure calls between a1 and a2, or if a1 and a2 are in two different procedures, to compute AffectsBip well branch into procedures. AffectsBip provides a programmer with more accurate picture of how the impact of assignments propagates through a SIMPLE program than Affects. 3.1 Example
Bill 1 Mary 6 John 9 7 X 8 4 10 dummy 11

procedure Bill { 1. x = 5; 2. call Mary; 3. y = x + 6; 4. x = 5; 5. z = x * y + 2; } procedure Mary { 6. y = x*3; 7. call John; 8. z = x + y; } procedure John { 9. if i then { 10. x = x + z; } else { 11. y = x * y; } }

2 X 3

Dashed arrows show Next relationship as defined in the Handbook. Solid arrows BranchIn to the procedures (as they are called) and BranchBack to the caller (as procedure execution is completed). Suppose we want to find all assignments a such that AffectsBip (1, a). We traverse CFG along Next links from line 1 as long as we do not hit a procedure call. Line 2 is call Mary We suspend traversal of CFG for procedure Bill and BranchIn to the first line of procedure Mary (line 6) and traverse control flow paths in procedure Mary to find assignments affected by assignment 1. We find that assignment 6 is affected. As procedure John is called in line 7, we BranchIn to the first line of procedure John. Exploring control flow paths in John, we find that assignments 10 and 11 are affected by assignment 1. As there is path from 9 to 11 in procedure John on which x is not modified, we BranchBack to procedure Mary and continue analysis from line 8. We find that assignment 8 is affected by assignment 1. Now we BranchBack to line 3 of procedure Bill and continue analysis. We find that assignment 3 is affected by assignment 1. As x is assigned a new value in line 4, we can stop analysis, the impact of assignment 1 wont propagate any further. 3.2 Extension 2a: Simplified CFGBip and AffectsBip CFGBip is easier to define and AffectsBip is easier to compute if we assume that each procedure is called only once in a SIMPLE program. In Iteration 1, we make this assumption. First, we define control flow relationship between program lines NextBip (n1, n2). NextBip is the same as Next except that we add BranchIn and BranchBack links for each procedure call, and remove Next links between procedure call and lines next to them.

Definition 1: CFGBip, Simplified NextBip and NextBip*(updated 27 March 2013) Construction of CFGBip: 1) Introduce dummy nodes so that a CFG for each procedure has exactly one exit node and a node for BranchBack control flow link. 2) Introduce BranchOut and BranchBack control flows. 3) Remove control flow links between any node call P and the node to which control flow returns after the execution of procedure P has been completed. For any program lines n1 and nk, relationship NextBip (n1, nk) holds iff nk can be executed immediately after n1 in some execution sequence according to CFGBip. That is: There is a control flow link between n1 and nk in the CFGBip Or There is a chain of nodes n1 -> n2 -> -> nk-1 -> nk linked by control flow links in CFGBip and n2, .., nk-1 are dummy nodes End of Definition 1 Comments: Point 1): If the last statement in a procedure P iscall Q then dummy node is needed for BrachBack link from procedure Q to P. If the last statement in a procedure is while then a dummy node is needed for loop exit link. A control flow path (n1, , nk) in CFGBip is the one in which NextBip (ni, ni+1). NextBip* (n1, nk) holds for any program lines such that there is a control flow path from n1 to nk. Definitions 2: AffectsBip Let a1 and a2 be two assignment statements such that a1 modifies value of variable v and a2 uses the value of variable v. AffectsBip (a1, a2) holds if there is a control flow path in CFGBip from a1 to a2 i.e., NextBip*(a1, a2) such that v is not modified in any assignment statement on that path (excluding a1 and a2). AffectsBip* is transitive closure of AffectsBip.

3.3

Extension 2b: General case of CFGBip and AffectsBip

Under single-call-only assumption, each procedure has at most one BranchIn link (when procedure is called) and one BranchBack link (when execution of a procedure is completed). If we relax singlecall-only assumption, then any procedure that is called many times will have many BranchIn and BranchOut links. These links must be properly traversed to properly capture control flows in a program. For example, path 3, 4, 9, 10, dummy, 8 in a graph below is not a valid control flow path. An example:
procedure Bill { 1. x = 5; 2. call Mary; 3. y = x + 6; 4. call John; 5. z = x * y + 2; } procedure Mary { 6. y = x *3 ; 7. call John; 8. z = x + y; } procedure John { 9. if i then { 10. x = x + z; } else { 11. y = x * y; } }
Bill 1 Mary 6 2 X 3 7 X 10 dummy 11 John 9

4 X 5

3.3.1

Generalized CFGBip by graph explosion

In the first attempt to capture valid control flows, we embed a new instance of a graph for procedure P at each place where P is called.
Bill 1 Mary
6 2 X John 9 4 10 11 X 8 10 11 3 7 X

John
9

dummy

dummy

Invalid control flow paths do not show in such a CFGBip. We define NextBip, NextBip*, control flow path. AffectsBip and AffectsBip* in the same way as in Section 3.2 for a single-call-only case.

3.3.2

Generalized CFGBip with labeled edges

Here is another approach to generalized CFGBip. We make graphs of procedures aware of who called them, so that the control can branch back to the caller once execution of a given procedure is completed. Bill
procedure Bill { 12. x = 5; 13. call Mary; 14. y = x + 6; 15. call John; 16. z = x * y + 2; } procedure Mary { 17. y = x*3; 18. call John; 19. z = x + y; } procedure John { 20. if i then { 21. x = x + z; } else { 22. y = x * y; } }
1 2 2 7 X 3 2 7 X 4 10 7 dummy 11 John 9 Mary 6

4 X 5

As before, dashed arrows show Next relationship as defined in the Handbook, and solid arrows define inter-procedural Branch control flows. We label BranchIn and BrenchBack links with line numbers of respective procedure calls that yield those links. Notice that procedure John is called twice. Suppose we want to find all assignments a such that AffectsBip (1, a). We traverse CFG along Next links from line 1 as long as we do not hit a procedure call. Line 2 is call Mary. We suspend traversal of CFG for procedure Bill and BranchIn to the first line of procedure Mary (line 6) and traverse control flow paths in procedure Mary to find assignments affected by assignment 1. We find that assignment 6 is affected. As procedure John is called in line 7, we BranchIn to the first line of procedure John. Exploring control flow paths in John, we find that assignments 10 and 11 are affected by assignment 1. Because there is path 9, 11 in procedure John on which x is not modified, we BranchBack to procedure Mary (link labeled with 7) and continue analysis from line 8. We find that assignment 8 is affected by assignment 1. Now we BranchBack to line 3 of procedure Bill and continue analysis. We find that assignment 3 is affected by assignment 1. Line 4 is call John. We BranchIn to the first line of procedure John, repeat the same analysis and BranchBack to line 5 of procedure Bill (via link labeled 4). We find that assignment 5 is also affected by assignment 1 which completes analysis. Of course we can optimize the above analysis by avoiding to revisit procedures in case the result of analysis is known to be the same as before. Definitions 3: Labeled NextBip and NextBip* Defintion of NextBip is the same as before, except that BranchIn and BranchBack links are labeled with line number of a procedure call that originated branching. CFGBip is control flow graph based on NextBip. A control flow path (n1, , nk) in CFGBip is the one in which NextBip (ni, ni+1) and any traversed link BranchIn is followed by BranchBack with same label, with no other BranchBack links from the same procedure between them. NextBip* (n1, nk) holds for any program lines such that there is a control flow path from n1 to nk.

Definitions 4: AffectsBip Let a1 and a2 be two assignment statements such that a1 modifies value of variable v and a2 uses the value of variable v. AffectsBip (a1, a2) holds if there is a control flow path from a1 to a2 i.e., NextBip*(a1, a2) such that v is not modified in any assignment statement on that path (excluding a1 and a2). AffectsBip* is transitive closure of AffectsBip. 3.4 PQL queries with NextBip, NextBip*, AffectsBip, and AffectsBip* We can allow the above relationships in PQL queries, along with all other relationships that we already have. These extensions will affect Design Extractor (to compute NextBip), Query Preprocessor (to validate queries with new relationships), and Query Evaluator. Here are required extensions of PQL grammar: relRef : ModifiesP | ModifiesS | UsesP | UsesS | Calls | CallsT | Parent | ParentT | Follows | FollowsT | Next | NextT | Affects | AffectsT | NextBip | NextBipT | AffectsBip | AffectsBipT NextBip : NextBip ( lineRef , lineRef ) NextBipT : NextBip* ( lineRef , lineRef ) AffectsBip : AffectsBip ( stmtRef , stmtRef ) AffectsBipT : AffectsBip* ( stmtRef , stmtRef ) 3.5 Hints 1. When computing NextBip and building CFGBip, consider boarder cases such as shown in procedure P below: procedure P { 1. call Q; 2. while i { 3. call Q1; } 4. if i then { 5. call Q2; } else { 6. call Q3; } } 2. When traversing CFGBip up and down to answer queries with AffectsBip, be sure that you consider only valid control flow paths.

4. Appendix A: Summary of PQL type checking rules

Any valid query must conform to BNF grammar definition, as well as to additional rules, some of which cannot (or are difficult) to represent in BNF grammar. Blow is a summary of type checking rules: 1) All the synonyms used in a query must be declared. 2) A synonym listed in query results must be a synonym of a design entity that can be identified by name, value or statement/program line number. Otherwise, we cannot display a query result. Valid synonyms are procedure | stmtLst | stmt | assign | call | while | if | variable | constant| prog_line The query result is to be shown as follows: in case of procedures: a procName, in case of statements: an integer stmt#, in case of stmtLst: a stmt# of the first statement in the list, in case of variable: a varName, in case of constant: a value (integer), and in case of prog_line: a program line number (integer).

3) Arguments in relationships should be synonyms, _ and, depending on the relationship, integer (statement line numbers or program line numbers) or string (variable or procedure names). Relationship arguments should conform to program design abstraction models for SIMPLE, as defined in Section 6. 4) Please check conventions described in Section 7.2 (and summarized below), as they apply in addition to the above PQL core rules. 5) Underscore _ is a placeholder for an unconstrained synonym. Symbol _ can be only used when the context uniquely implies the type of the design entity denoted by _. 6) Under with-clause we can compare an attribute value and constant (integer or string, depending on the type of attribute) or two attribute values (provided they are of the same type).

--- The End ---

Organization of the final Project Report:

Cover page:
CS3202, date Project team: team# Team members: Group-PKB: name Group-PQL: name Consultation Hour:

matric number matric number

e-mail e-mail

0. Project story
In free format, describe your project story, experience. This section is up to you and you may leave it empty.

1. Summary of main achievements

1.1 1.2 Basic SPA functionality Extension for bonus points Did you implement all the required functions (iterations 1-3)? Did you implement any extension described in Assignment 4? Did you implement any other extensions that you this deserve mentioning? Please include test cases for extensions you implemented. Mention any other issues that you think are relevant unexpected problems you managed to resolve, particularly good design solution.

2. Project plans
Describe how you organized project work, the actual schedule, etc. Organize your description into the following sub-sections: 2.1 2.2 The actual schedule for the project, milestones Any comments on division of work and project discussion meetings Discuss problems encountered that affected project schedule.

3. UML diagrams
Draw UML diagrams that you found useful. For each diagram that you draw, explain how you used it (e.g., in project planning, communication, test planning or in other situations), and comment on the value a diagram added to your project.

4. Documentation of important design decisions

Follow guidelines in Handbook Section 10.2 to analyze, justify and document detailed design decisions. Pay attention to clarity of the description (check hints in Section 10.2). If you applied design patterns, document them in this section: a) Explain the design problem and pattern you applied 10

b) Document expected benefits and costs of applying a design pattern c) Document the actual benefits and costs of a design pattern that you experienced in the project after applying it.

5. Coding standards and experiences 6. Query processing

6.1 Validating program queries Describe query validation rules, only in case there is some difference as compared to what you described in your previous assignment. An example of query validation rule is: checking if all relationships have correct number and types of arguments, as defined in PQL definition in Handbook. DO NOT provide procedural description (pseudocode) of how Query Pre-processor checks the rules. If you use table-driven approach to query validation show the structure of your tables. 6.2 1. 2. 3. 4. Design and implementation of query evaluator Describe data representation for program queries Describe your strategy for Basic Query Evaluation (BQE) Describe optimizations Discuss detailed design decisions regarding BQE and optimizations

7. Testing: Group-PKB and Group-PQL

Describe your testing experience (not exceeding TWO pages).

8. Project evaluation
Free format. Here are examples of issues that you might address (do not feel obliged to address all of them and you can discuss issues not mentioned here): 1. How would you improve your SPA if more time was available? 2. What would you done differently if you were to start project again? 3. Comment on the experience gained in this project in respect to: a) working in the team, b) incremental development, c) complexity of the SPA problem and program solution, d) what did work well? e) what did not work well? f) what did you learn in this project course? 4. Comment on the tools used for the project a) Were the recommended tools useful? b) What other tools did you use (if any), and in what ways were they useful? c) What were the problems you faced when using each tool? d) In which areas would you like to have had more tool support? 5. What management lessons have you learned? 6. What advice would you give to the students who will take this course in the future? 7. Suggest how we could improve this project course. 8. Discuss any other experiences.

Appendix A: Abstract PKB API

Include up to date documentation of your abstract APIs for design abstractions.

11

Appendix B: Comments on Handbook

--- The End ---

12