Com S 362 --- Object-Oriented Analysis and Design HOMEWORK 6: SECOND ELABORATION ITERATION (File $Date: 2002/12/07 16:08:17 $) Due: Problem 1, November 18, 2002, at 11AM; Problem 2, December 11, 2002 at 11AM. Problem 1 is an individual homework problem; it should *not* be done in teams. Problem 2 is a team homework problem. 1. [JUnit and JML] Readings for JML: A Notation for Detailed Design by Leavens, Baker, and Ruby, April 2001. In Haim Kilov, Bernhard Rumpe, and Ian Simmonds (editors), Behavioral Specifications of Businesses and Systems, chapter 12, pages 175-188. Copyright Kluwer, 1999. Available from http://www.jmlspecs.org. For a JML reference, see the "Preliminary Design of JML: A Behavioral Interface Specification Language for Java", by Leavens, Baker, and Ruby, October 2002. This is also availble from http://www.jmlspecs.org. For this individual problem first make a copy, in your own directory, of the file HistoricalData.java which is in /home/course/cs362/public/homework/hw6/ on the department Linux machines. For example: $ cp /home/course/cs362/public/homework/hw6/HistoricalData.java . This file is also available from the course web page. a. (30 points) Write a JUnit test class, named HistoricalDataTest, which does unit testing on the class HistoricalData. (Hint: you can use Eclipse to generate a skeleton test file that has a main method with the "text ui" interface to get started on this.) You should write a test that has a test method for each method of HistoricalDataTest. (You don't have to write a separate test for HistoricalData's constructor or for the toString method if you don't want to. Note that a subclass of TestCase should have a public constructor as follows public HistoricalDataTest(String name) { super(name); } that takes a single string as an argument, and calls the constructor of TestCase with that string.) We will grade your work on the clarity and completeness of your test. Run your test with the JUnit textual interface on the supplied version of HistoricalDataTest. It should find failures on all the methods. Hand in a printout of your HistoricalDataTest class and the output from this test run. b. (15 points) Implement the class HistoricalData by replacing each of the lines indicated in the file. Your code should pass the JUnit test you wrote for it. It should also follow Reil's heuristics. Furthermore, use the minimum amount of space for objects of type HistoricalData. (Hint, you may find it convenient to use Double.NEGATIVE_INFINITY in your code.) Make a printout of the code for HistoricalData to hand in at this point. c. (10 points) Write a design class diagram for your implementation of HistoricalData that includes its fields and methods. This can be handwritten. Hand in your design class diagram. d. (30 points) Write, in JML, a specification for each of the methods in the class HistoricalData. These should appear as annotations in your code. Your specification should include at least (i) a normal postcondition (ensures clause) for each method (including toString) and for the constructor, (ii) any necessary preconditions (requires clauses, also see below), and (iii) an invariant. Except in the specification of the toString and hashCode methods, you are not allowed to use any informal descriptions, written (* ... *), in the JML specifications. The invariant can be a private invariant. You should write pre- and postconditions for any new methods you wish to add as well. Whatever data fields you declare in your implementation should probably be declared to be spec_public in JML. About the preconditions -- Java's type double has three special values: NaN (not a number), and positive and negative infinity. We don't want to allow these as measurements added to the HistoricalData. Thus your specification should require that these special values are never given as measurements. Note that NaN is quite special when used in comparisons in Java; to reliably test for it, use the static method Double.isNaN, which takes a double as an argument. You don't have to write heavyweight specifications in JML. You should instead use lightweight specifications as discussed in class; that is for methods, just "requires" and "ensures" clauses. The preconditions you write should be enough to guarantee that no exceptions are thrown, unless you want to use more sophisticated features of JML. Note that for the equals, hashCode, clone, and toString methods, any specifications you write have to start with the JML keyword "also". Hint: JML has operators \sum and \max which you may find convenient to use to specify the method addAll. For example, (\sum int i; 0 <= i && i < 3; i + 4.0) == 0+4.0 + 1+4.0 + 2+4.0 == 15.0 See section 3.1 of the "Preliminary Design of JML" for details on these. Compile your code and its specification using the JML runtime assertion checking compiler, jmlc, as follows. First change directories into the Eclipse workspace subdirectory containing your file (c:\eclipse\workspace\hw6 or some such on Windows), or export the files HistoricalData.java and HistoricalDataTest.java from Eclipse into a directory you can find. Then from that directory, execute: $ javac HistoricalDataTest.java $ jmlc -p HistoricalData.java Then (without recompiling HistoricalData.java!) run your JUnit tests again, as follows. $ jmlrac HistoricalDataTest (If you run the tests from within Eclipse, be sure that the jmlruntime.jar file is in the project build path. It's found in the JML/bin directory, e.g., in /opt/JML/bin/jmlruntime.jar on Linux.) Fix any errors in your specifications (or in your code) as pointed out by the runtime assertion checker, until your code passes the tests without assertion violations or failures. Hand in a printout of your code for HistoricalData.java with the JML annotations. e. (5 points) Did you find any errors in your code from using JML (either during the writing of the specifications or the testing) that were not found just by using the JUnit tests? If so, briefly describe them. 2. [Second Elaboration Iteration] In this problem, you and your team will do the second elaboration iteration for your team project. For this problem, read chapters 9-23 of Craig Larman's book Applying URL and Patterns (Second edition, Prentice-Hall PTR, Upper Saddle River, NJ, 2002). Also read chapters 4 and 11 of Martin Fowler with Kendall Scott's book UML Distilled (Addison-Wesley Longman, Inc., Reading, MA, 2000). Finally, as an example look at the web page for the StickSync project: http://www.cs.iastate.edu/~cclifton/courses/sticksync/ Your overall task is to decide on more use case scenarios, and implement them. Details follow. a. (20 points) Summarize what you learned about your team's project's requirements, design, and and implementation from iteration 1. This can be a paragraph or two of text. b. Use Case model. The use cases should be revised to reflect the lessons you learned in the first elaboration iteration. (i) (5 points) List all the names of all the use cases for your project. (This can be an index on a web page with hyperlinks to the use case text if you wish.) (ii) (10 points) Determine a subset of the use cases (and scenarios within these) for your project that you will implement in the second elaboration iteration of your project. You must plan to implement at least three more scenarios. Note that you will have two weeks to implement these. (iii) (10 points) Briefly justify your team's selection of use cases based on your project's risks. (iv) (60 points) Write all of the use cases from which you are implementing scenarios in this iteration in fully dressed format. (See Larman's book, section 6.6 or go to usecases.org for the format.) Also, even if you are only implementing scenarios from one use case, you must have at least 5 fully dressed use cases. (v) (30 points) Write all of the remaining use cases in casual format (see Larman section 6.3). (vi) (60 points) Write system sequence diagrams (see Larman chapter 9) for all of the scenarios that you are implementing in this iteration. You must have at least 3 SSDs. c. Starting Design Class Diagram (20 points) Present the design class diagram for the classes present at the end of the first elaboration iteration. Use the notation described in Larman Chapter 19 for this. d. Design model. (i) (50 points) Present your interaction diagrams for your design, along with any commentary needed to help understand them. You can use either sequence diagrams or collaboration diagram notation for this, although we recommend the collaboration diagram notation. These can be (and probably should be) hand drawn. (See Larman chapters 15-16 for notation.) (ii) (20 points) Include on your interaction diagrams dog-eared boxes (annotations) with names of patterns to indicate what patterns you are using to assign responsibilities. See Larman's chapter 17 for examples of this, e.g., Figure 17.7. (If you find that most of your annotations are justifying assignment of responsibilities based on a single pattern, such as Expert, you can make a prominent annotation stating the default for your diagram, and only write out annotations for the justifications that do not use the default pattern.) (iii) (30 points) Present a revised design class diagram for classes in your implementation and planned for this iteration. Use the notation described in Larman Chapter 19 for this. The design class diagram should identify the methods in each class and have arrowheads on associations to indicate navagability. Be sure to label this so it can be distinguished from the design class diagram that was present at the end of the first elaboration iteration. (iv) (optional) Include any other artifacts for your design that you feel are useful. For example, you might need a database design. f. Code and test (i) (60 points) Give us a printout or access to your code. This must be in Java. Your code should be clearly written and indented, and should include either javadoc documentation comments or JML specifications. (ii) (40 points) You must have JUnit test classes for testing at least 6 of your classes. Handing these in without any additional comments certifies that your code passes these tests. If it does not, you must include output or descriptions saying what tests do not pass. (iii) (30 points) Your code should include at least 4 classes or interfaces with JML specifications (pre- and postconditions for methods, and invariants). Be sure to clearly indicate which classes or interfaces have such specifications. g. Demo (40 points) You must schedule a demonstration with our teaching assistant, which should show how the system works on the test case scenarios you implemented, and which also demonstrates some of your testing. This should be scheduled within a 4 days of the due date of this homework. Your grade for this will depend on how well the system implements the scenarios that you have decided to implement for this iteration. We recommend against drawing figures using a tool (like Rational Rose), because you would spend a significant part of your time working with the tool. (However, it's okay if you really want to do this.) Instead we suggest drawing the figures by hand; if you wish, scan them in to your project's web site. All of your project's artifacts, with the possible exception of figures drawn should be on your project's web site. Hand in a printout of these artifacts. Don't forget to hand in the course's "Certification of Individual Contribution and Understanding Form". You can find this form in 3 formats from the course web pages at the URL: http://www.cs.iastate.edu/~cs362/docs/ or on the department machines in the directory /home/course/cs362/public/docs/ The certification form must be printed and signed, you cannot turn that in by email.