COMS W3156: Software Engineering, Fall 2001

1. COMS W3156:Software Engineering, Fall 2001 Lecture #14: Implementation II, LDAP Janak J Parekh janak@cs.columbia.edu

2. Administrativia • LDAP configured • HW2 due now • Design due in one week • Requirements update pending (v1.2) • LDAP renaming • Missing some boolean operators • Something else? • Webboard… • You are supposed to do the homework

3. Next class • I’m debating

4. Today’s class • Implementation, continued (testing) • LDAP

5. From last class • Conclusion: we need a compromise – highlight faults, while accepting that not all faults will be detected • Black-box test cases first (specifications) • Then, develop additional glass-box techniques (code)

6. Black-box module testing • Goal: devise small number of test cases that cover most of the possibilities • Every test case must be chosen to detect a previously undetected fault: don’t repeat • Equivalence testing and boundary value analysis

7. Equivalence class testing • Break down cases into equivalence classes • Example: database with max 16,000 records • If it works for 251, it’ll probably work for 12,000 • Define classes that need to be tested • Less than 1 record • From 1 to 16,000 records • More than 16,000 records

8. Boundary testing • Take the equivalence classes to the next level • 0 records • 1 record • 2 records • 723 records • 16,382 records • 16,383 records • 16,384 records

9. Boundary testing (II) • Test both sides of the classes • While the example referred to input specifications, can also boundary-test output cases • Example: payroll • Test deductions between, and including, min and max deduction values, as well as beyond them • Devise test cases to get these results

10. Boundary testing (III) • In general, for a range {R1, R2}, 5 test cases: • Less than R1 • Equal to R1 • Greater than R1, less than R2 • Equal to R2 • Greater than R2 • Need to start thinking this way

11. Functional testing • Test on functionalities of module • Step 1: determine functions of module • Step 2: Devise test data for each low-level function • Step 3: Determine higher-level functions • (picture) • This is hybrid black-box and glass-box

12. Functional testing (II) • In practice, need to do functional analysis, since it’s not always so simple • Often, cross-module functionality • Object-oriented doesn’t help • Difficult to resolve at times, but general principle remains sound

13. Glass-box testing • Look at the source code, and design test cases from there • Statement coverage • Path coverage • Branch coverage

14. Statement coverage • Run a series of test cases in which every statement is executed at least once. • Use a CASE tool to keep track of how many times each statement has been executed • Rational PureCoverage, which we do have, but we’re probably not going to use it • Problem: no guarantee all outcomes of branches are tested (i.e. if clauses)

15. Branch coverage • Run a series of tests to ensure all branches are tested at least once • Tools such as Generic Coverage Tool (gct) • Statement/branch coverage are structural tests

16. Path coverage • Test all paths • Challenge: reduce number of paths to be examined while still uncovering as many faults as possible • Restrict test cases to linear code sequences: identify set of points from which control may jump, and devise code sequences that begin at control flow and end at another control flow

17. All-definition-use-path • Define each occurrence of a variable as a definition of the variable (int i=1) or use of the variable (y=i+5) • Identify all paths between definition and use • Set up a test case for each path • Still theoretically 2d paths (d = #branches) • Can be shown that in real programs this is not reached

18. Dead code • Sometimes programmers will have an “infeasible path” that cannot be reached given any input • Statement coverage detects this

19. Complexity metrics • Intuition suggests more complex code implies more bug-prone code • Various metrics to determine complexity • LOC • McCabe’s measure of cyclomatic complexity • # branches in the module • Found to be reasonably accurate • Halstead utilizes a linear combination of several metrics (operators and operands) • Problem: both Halstead and McCabe practically are linear with LOC

20. Code walkthroughs/inspections • Works very, very well* • Explaining your own code finds many faults • Suggest you try it in a group environment • Much cheaper than execution-based testing • Takes less time • Faults are detected earlier

21. Comparing testing mechanisms • Brief conclusion: all are valid, but some work a bit better than others • In some studies, it’s been shown that code reading was most effective at detecting “interface faults”, while black-box testing was most effective at finding “control faults” • Conclusion: code walkthroughts/inspections work

22. Cleanroom • Combine a number of different techniques, including incremental lifecycle • Critical aspect: cannot compile a module until it passes inspection • Has been successful for both small and large programs • Metric: testing faults from time of compilation

23. Challenges of testing objects • Can’t execution-test a class, only objects • Information hiding and simple methods complicate things: need to call both setter and getter methods to test variable changes • Need to test inherited methods! • Context may have changed: methods it may call may have been overridden

24. Miscellany • Management: how much time and money to test? • Cost-benefit analysis • Reliability analysis: statistical determination of faults remaining • When to rewrite? • Predetermine “maximum number of faults” • Challenges • When, how to reuse code

25. LDAP • Lightweight Directory Access Protocol • Essentially a hierarchical (treelike) database • Attributes: Attribute-value pair • Objects: collection of Attributes (record) • Records are uniquely identified using the DN, or distinguished name • Not XML, but you don’t need to talk the language: JNDI does the work

26. Distinguished name • Unique name assigned to everything in the database • Implicit hierarchy: “root” is the right part • Comma (,) is delineator • Utterly flexible • “cn=Janak,ou=PSL,ou=CS,o=Columbia” • “cn=Janak,dc=psl,dc=cs,dc=columbia,dc=edu”

27. Our LDAP database • Designated as “o=softe” – it’s the root of the tree • Three nodes (each have the root affixed): • ou=services • ou=actors • ou=states • Each item under this must have its own DN

28. Entries in LDAP • Every entry will have its own unique DN: the “identifier” will usually be a CN (Common Name) component of the DN • “cn=A1,ou=services,dc=softe,dc=cs,dc=columbia,dc=edu” • “cn=johndoe,ou=actors,dc=softe,dc=cs,dc=columbia,dc=edu”

29. Schema • Each entry can be one of any (millions) of types • We’ve explicitly created three for you • Service • Actor • ActorState • Names changed from requirements; will fix

30. Service • Service reference ID: CN tag in DN: use your group ID • Required: • ServerIP (string) • ServerPort (int) • ServerType (string): A or S • Optional • WorldName • ServerExtensions

31. Actor • Actor “name”/login id: CN tag in DN • Required: • HP: int • XP: int • Gold: int • Password: String • We’ll give you crypting code • Optional: • ImageURL

32. ActorState • CN in DN: unique identifier • Concatenate Actor, World, and Service • ac=actorname+wn=worldname+sv=servicename • Required • LocationX: int • LocationY: int • Status: int • WorldInstance: int

33. JNDI • Straightforward API, built into JDK 1.3 and higher • Can do more than LDAP: DNS, etc. • For LDAP, uses concept of directory context in which the operation will be done • ldap://softe.cs.columbia.edu:389/o=softe • Once set, go ahead and do operation(s) • Recitation!

34. JNDI Lookups • getAttributes() method searches by (unique) DN • similar to lookup() but more powerful • Returns Attributes object: collection of attribute-value pairs; you can “get” and “put”; like a Hashtable

35. JNDI Searches • search() searches within a DN for all entries that match the Attributes set you provide • Returns NamingEnumeration (subinterface of Enumeration) • Each entry in the Enumeration is a SearchResult, which you can convert toString() and then do a lookup

36. JNDI Lists • list() finds all in the DN context • Returns NamingEnumeration, consisting of NameClass pairs • getName() method in this class

37. JNDI Writes • Just like we can getAttributes(), we can… • (re)bind() • Ok, so the parallel isn’t ideal • Name: DN • Object: null (Java can serialize to LDAP!) • Attributes: our good friend

38. JNDI Deletes • unbind(); • Must supply whole DN to it • Use search() if you don’t know what the full DN of the relevant object is • Almost never throws exception, even if the record isn’t there • idempotent

39. JNDI Miscellany • Name class • You don’t have to use this: it’s a bit more “civilized” way of dealing with DN’s, though • For the scope of this class, it’s acceptable just to use Strings for DN’s

40. Our permissions setup • Services: readable by all, writeable only by those who have password • Actors: read/write by password only • ActorStates: read/write by password only • Net effect • Client has no password, and no need of one • All servers will share the same DN and password (yes, logins are via DN too!)

41. What does this mean for you? • Implementation/Testing • You now know what your testing plan will look like • LDAP • You finally know all the details to use LDAP not only for your design, but also your implementation • Shouldn’t need a whole lot for the design • We give you code samples: adjust it to suit your needs