CSCE 431: Final Exam Review

1. CSCE 431:Final Exam Review

2. Outline • Interfaces and Contracts • From Models to Implementation • API Design • Testing • Verification • Scripting Languages and Rapid Prototyping • Licensing and SE Code of Ethics CSCE 431 Final Exam Review

3. Final Exam • Wed 5/7 8:00-10:00am, RICH 106 • Covers Interfaces and Contracts through Licensing and SE Code of Ethics • Covers Homework 3 • Focus on material covered in slides • Assigned readings are background material to aid your understanding CSCE 431 Final Exam Review

4. Interfaces and Contracts Object design • Object design model (class diagrams) • Interface contracts, syntactic and semantic • Library APIs, error handling Implementation • Interface contracts, syntactic and semantic • Library APIs, error handling • Source code CSCE 431 Final Exam Review

5. Object Design • Purpose • Prepare for implementing the system model • Transform the system model for better implementability, extensibility, performance, … • Explore ways to implement the system model • The result of object design should match the structure of the implementation CSCE 431 Final Exam Review

6. Activities • Reuse: identify and adapt existing solutions • Off-the-shelf components • Libraries • Design patterns • Interface specification • Specs of each class interface • APIs of subsystems • Object model restructuring • To improve some characteristics (extensibility, understandability, etc.) • Object model optimization • Greater speed, lower memory use, etc. CSCE 431 Final Exam Review

7. Executive Summary • UML models can be gradually refined to include more details about interfaces • UML+OCL: Notations and language to express contracts (pre/post conditions, invariants) in UML • Interesting part is constraints that span multiple classes (constraints over UML associations) • Language neutral constraints CSCE 431 Final Exam Review

8. Access Control Guidelines • Expose as little as possible • But the “basis” should be complete—and efficient • The less exposed, the more freedom to change the class implementation • Fewer things to learn and document • Access attributes only via operations (except when no class invariant) • Hide substructures • Do not apply an operation to the result of another operation • Write a new operation that combines the two operations • “Law of Demeter” CSCE 431 Final Exam Review

9. Law of Demeter1 • Method Mof an object Omay only invoke the methods of the following kinds of objects: • Oitself • M’s parameters • Any objects created/instantiated within M • O’s direct component objects • Global variables, accessible by O, in the scope of M • Example violation: x.y.foo().bar() • Layered architectures satisfy the law • One goal: compositionality • The meaning of a complex expression is determined by the meanings of its immediate constituent expressions and the rules used to combine them • Testimonial (from JPL): We have found, however, that breaking the LoD is very expensive! On Mars Pathfinder, the integration costs of the law breaking parts of the system were at least an order of magnitude higher, and we had to pay that cost on every integration cycle – not just once! We should have paid the cost once by implementing a more sophisticated protocol that did obey the LoD. 1Karl Lieberherr and Ian Holland, Assuring Good Style for Object-Oriented Programs, IEEE Software, Sep. 1989, pp. 38-48. CSCE 431 Final Exam Review

10. Contracts and Formal Specification • Contracts enable the caller and the provider to share the same assumptions about the class • A contract is an exact specification of the interface of an object • A contract include three types of constraints: • Invariant: • A predicate that is always true for all instances of a class • Pre-condition(“rights”): • Must be true before an operation is invoked • Post-condition(“obligation”): • Must be true after an operation is invoked CSCE 431 Final Exam Review

11. Example from ARENA: League, Tournament, Player • Constraints: • A Tournament’s planned duration must be under one week • Players can be accepted in a Tournament only if they are already registered with the corresponding League • The number of active Players in a League are those that have taken part in at least one Tournament of the League CSCE 431 Final Exam Review

12. Outline • Interfaces and Contracts • From Models to Implementation • API Design • Testing • Verification • Scripting Languages and Rapid Prototyping • Licensing and SE Code of Ethics CSCE 431 Final Exam Review

13. Transformations CSCE 431 Final Exam Review

14. Model Transformation Example • Object design model before transformation: • Object design model after transformation: CSCE 431 Final Exam Review

15. Same Transformation in Code: Refactoring: Pull Up Field public class Player { private String email; //... } public class LeagueOwner { private String eMail; //... } public class Advertiser { private String email_address; //... } public class User { private String email; } public class Player extends User { //... } public class LeagueOwnerextends User { //... } public class Advertiser extends User { //... } CSCE 431 Final Exam Review

16. Summary of Models to Implementation • Four mapping concepts • Model transformations • Improve the compliance of the object design model with a design goal • Forward engineering • Consistent transformation of models to code • Refactoring • “Preserve semantics, improve readability/modifiability” • Reverse engineering • “Extract design from code” • Model transformations and forward engineering techniques • “Optimizing” within the class model • Mapping associations to collections • Mapping contracts to exceptions • Mapping class model to storage schemas CSCE 431 Final Exam Review

17. Outline • Interfaces and Contracts • From Models to Implementation • API Design • Testing • Verification • Scripting Languages and Rapid Prototyping • Licensing and SE Code of Ethics CSCE 431 Final Exam Review

18. Characteristics of a Good API • Easy to learn • Easy to use even without documentation • Hard to misuse • Easy to read and maintain code that uses it • Sufficiently powerful to satisfy requirements • Easy to extend • Appropriate to audience CSCE 431 Final Exam Review

19. Designing an API: “Eat your own dog food” • Write to your API early and often • Even if not yet implemented • Even if not yet fully specified • These avoid wasted implementation and specification effort • Code you write lives on as unit tests and example uses (documentation) • Expect the API to evolve • “The rule of Threes” (Will Tracz:, Confessions of A Used Program Salesman, Addison-Wesley, 1995) • Write one client before release, will not support another • Write two clients before release, will support more with difficulty • Write three clients before release, will work fine CSCE 431 Final Exam Review

20. Interface • Simple • General • Regular • Predictable • Robust • Adaptable CSCE 431 Final Exam Review

21. Broad Issues to Consider in API Design • Interface • Classes, methods, parameters, names • Resource Management • How is memory, other resources dealt with • Error Handling • What errors are caught and what is done to handle them • Information Hiding • How much detail is exposed • Impacts all three of the above CSCE 431 Final Exam Review

22. Abrahams’ Categorization • The basic guarantee: invariants of component are preserved, no resources are leaked • Basically, an object can be assigned to • The strong guarantee: that the operation has either • Completed successfully, or • Thrown an exception, leaving the program state exactly as it was before the operation started • The no-throw guarantee: that the operation will not throw an exception http://www.boost.org/community/exception_safety.html CSCE 431 Final Exam Review

23. Outline • Interfaces and Contracts • From Models to Implementation • API Design • Testing • Verification • Scripting Languages and Rapid Prototyping • Licensing and SE Code of Ethics CSCE 431 Final Exam Review

24. Fault Avoidance and Detection • Static Analysis • Hand execution: Reading the source code • Walk-Through (informal presentation to others) • Code Inspection (formal presentation to others) • Automated Tools checking for • Syntactic and semantic errors • Departure from coding standards • Dynamic Analysis • Black-box testing (Test the input/output behavior) • White-box testing (Test the internal logic of the subsystem or class) • Data-structure based testing (Data types determine test cases) CSCE 431 Final Exam Review

25. Typical Test Categorization • Unit testing • Integration testing • System testing • Reliability testing • Stress testing • Acceptance testing CSCE 431 Final Exam Review

26. Verification vs. Validation • Validation: “Are you building the right thing?” • Verification: “Are you building it right?” • Acceptance testing about validation, other testing about verification CSCE 431 Final Exam Review

27. Another Test Categorization – By Intent • Regression testing • Retest previously tested element after changes • Goal is to assess whether changes have (re)introduced faults • Mutation testing • Introduce faults to assess test quality CSCE 431 Final Exam Review

28. Goal – Partition Testing • Cannot test for all possible input data • Idea: For each test, partition input data into equivalence classes, such that: • The test fails for all elements in the equivalence class; or • The test succeeds for all elements in the equivalence class. • If this succeeds: • One input from each equivalence class suffices • No way to know if partition is correct (likely not) • Heuristics - could partition data like this: • Clearly good values • Clearly bad values • Values just inside the boundary • Values just outside the boundary CSCE 431 Final Exam Review

29. Mock Objects • Often (practically) impossible to include real objects, those used in full application, into test cases • To test code that depends on such objects, one often uses mock objects instead • Mock object simulates some part of the behavior of another object, or objects • Useful in situations where real objects • Could provide non-deterministic data • States of real objects are hard to reproduce (e.g. are result of interactive use of software, erroneous cases) • Functionality of real objects has not yet been implemented • Real objects are slow to produce results • Tear-up/tear-down requires lots of work and/or is time consuming CSCE 431 Final Exam Review

30. White Box Testing • White box – you know what is inside, i.e. the code • Idea • To assess the effectiveness of a test suite, measure how much of the program it exercises • Concretely • Choose a kind of program element, e.g., instructions (instruction coverage) or paths (path coverage) • Count how many are executed at least once • Report as percentage • A test suite that achieves 100% coverage achieves the chosen criterion. Example: • “This test suite achieves instruction coverage for routine r ” • Means that for every instruction i in r, at least one test executes i CSCE 431 Final Exam Review

31. Coverage Criteria • Instruction (or statement) coverage • Measure instructions executed • Disadvantage: insensitive to some control structures • Branch coverage • Measure conditionals whose paths are both/all executed • Condition coverage • How many atomic Boolean expressions evaluate to both trueand false • Path coverage • How many of the possible paths are taken • path == sequence of branches from routine entry to exit CSCE 431 Final Exam Review

32. Some Coverage Criteria all-defsexecute at least one def-clear sub-path between every definition of every variable and at least one reachable use of that variable all-p-uses execute at least one def-clear sub-path from everydefinition of every variable to every reachable p-use of that variable all-c-uses execute at least one def-clear sub-path from everydefinition of every variable to every reachable c-use of the respective variable CSCE 431 Final Exam Review

33. Some Coverage Criteria all-c-uses/some-p-uses apply all-c-uses; then if any definition of a variable is not covered, use p-use all-p-uses/some-c-uses symmetrical to all-c-uses/ some-p-uses all-uses execute at least onedef-clear sub-path from everydefinition of every variable to every reachable use of that variable CSCE 431 Final Exam Review

34. Who Tests the Tester? • All tests pass. Is the software really that good? • How does one know? • Is the software perfect or is the coverage too limited? • Test the tests • Intentionally introduce defects • If tests find the defects, test suite good • If no bugs are found, test suite insufficient • Have to plan defect types and locations • Random? • Weight based on code criticality? • Amount of coverage? CSCE 431 Final Exam Review

35. Code Reviews • Method shown to be effective in finding errors • Ratio of time spent in review vs. later testing and error correction • Ranges from 1:20 to 1:100 • Reduced defect correction from 40% of budget to 20% • Maintenance costs of inspected code is 10% of non-inspected code • Changes done with review: 95% correct vs. 20% w/o review • Reviews cut errors by 20% to 80% • Several others (examples from Code Complete) CSCE 431 Final Exam Review

36. Reviews vs. Testing • Finds different types of problems than testing • Unclear error messages • Bad commenting • Hard-coded variable names • Repeated code patterns • Only high-volume beta testing (and prototyping) find more errors than formal inspections • Inspections typically take 10-15% of budget, but usually reduce overall project cost • Reviews can provide input to test plan CSCE 431 Final Exam Review

37. Outline • Interfaces and Contracts • From Models to Implementation • API Design • Testing • Verification • Scripting Languages and Rapid Prototyping • Licensing and SE Code of Ethics CSCE 431 Final Exam Review

38. Program Properties • Well-formed formulas: “Hoare triples” • {P} A {Q} • Ais a program fragment • P; Q predicates over the program state • If A is started in any state that satisfies P, the state after Aterminateswill satisfy Q • Partial correctness – A may not terminate • Total correctness – A will terminate CSCE 431 Final Exam Review

39. Rules • Inference Rules • Consequence • Conjunction • Language-specific rules • Skip • Abort • Assignment • Conditional • Composition • While – loop invariant CSCE 431 Final Exam Review

40. Weakest Preconditions • Compute least-constraining P condition that satisfies Q after A terminates CSCE 431 Final Exam Review

41. Outline • Interfaces and Contracts • From Models to Implementation • API Design • Testing • Verification • Scripting Languages and Rapid Prototyping • Licensing and SE Code of Ethics CSCE 431 Final Exam Review

42. Scripting Language • Programming language that supports scripts - programs written for a special run-time environment that can interpret (rather than compile) and automate the execution of tasks which could alternatively be executed one-by-one by a human operator • Can be viewed as a domain-specific language for a particular environment; in the case of scripting an application, this is also known as an extension language • High-level language, ~10x less code than system programming language • Often implies “small” (≤ few thousand lines of code) • Can be domain-specific, e.g. Awk, Sed string processing languages • Can be environment-specific, e.g. UNIX Shell, Visual Basic for Applications - http://en.wikipedia.org/wiki/Scripting_language CSCE 431 Final Exam Review

43. Scripting Languages • Used for one-time tasks • Customizing administrative tasks • Simple or repetitive tasks • Example: run an application with a sequence of different parameters • Extension language • LISP in EMACS an early example • Controls execution of an application • Programmatic interface to graphical application CSCE 431 Final Exam Review

44. Classes of Scripting • Web browser – PHP, Javascript,… • Extension language – Lua, Tcl, VBA,… • GUI – JavaFX, Tcl/Tk,… • String processing – Awk, Sed,… • OS scripting – Shell, Cshell,… • General languages – Perl, Python, Ruby,… • Overlap among these CSCE 431 Final Exam Review

45. System Programming Languages vs. Scripting Languages • System programming languages • C, C++, Java,… • Designed for building data structures and algorithms from scratch • Concerns: efficiency, expressiveness, strong typing, design support, read-only code, compiled • Scripting languages • Tcl, Perl, Python, Ruby, Awk, Sed, Shell, Lua,… • Designed for gluing components together • Concerns: rapid prototyping, typeless, higher level programming, interpreted, code-on-fly CSCE 431 Final Exam Review

46. System vs. Scripting Language Level 1000 [Ousterhout 1998] Scripting Visual Basic 100 Java Instructions/statement C++ Tcl/Perl C 10 Assembly System programming 1 None Strong Degree of Typing CSCE 431 Final Exam Review

47. Not Either/Or • Most platforms provide scripting and system PL • IBM • Job Control Language (JCL) - sequence jobs on OS/360 • ~1st scripting PL • Jobs ran in FORTRAN, PL/1, Algol, COBOL, Assembler • UNIX • Shell – sh/csh • C • PC • Visual Basic • C/C++ • Web • JavaScript, Perl, Tcl • Java CSCE 431 Final Exam Review

48. Observations • People write similar LOC/h • Scripting takes 2-3x less code • So 2-3x less development time • Scripting memory consumption ~higher • Java outlier • Lot of variation • Scripting ~10-20x longer load and preprocess • Scripting ~similar search times • String-oriented application • C/C++ code had more bugs CSCE 431 Final Exam Review

49. What is Rapid Prototyping? • Quick assembly of a partial or complete system for experimentation prior to full requirements, specification and implementation • Quick assembly of a tool or system for temporary or permanent use, using special-purpose languages and existing tools • Goals • Rapid! - <10% of time for traditional C/C++ implementation • Functionality – implement functions to permit experimentation or use • Okay performance – system only needs to be fast enough to try it out or to be acceptable • Easily modified – for iteration during experimentation, or for maintainability CSCE 431 Final Exam Review

50. Relationship to Agile • Agile • Build system using “final” technology • Each iteration is a working system, gradually adding features • User stories more than requirements/specs • Rapid prototyping • May never be a “production” system • Need the system to elicit user stories • What does user want? • “I know it when I see it” – Potter Stewart CSCE 431 Final Exam Review