1 / 41

COMS W3156: Software Engineering, Fall 2001

COMS W3156: Software Engineering, Fall 2001. Lecture #14: Implementation II, LDAP Janak J Parekh janak@cs.columbia.edu. Administrativia. LDAP configured HW2 due now Design due in one week Requirements update pending (v1.2) LDAP renaming Missing some boolean operators Something else?

skyler
Download Presentation

COMS W3156: Software Engineering, Fall 2001

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related