To directly assess your mastery of the learning objectives of this course, we will conduct a series of learning assessments over the course of the semester. The use LAs of this course is inspired by mastery-based testing practices found in mathematics.
Most of the LAs will also appear as in-class paper-based ten-minute quizzes, given in class on various days.
Each LA will correspond to one of the learning objectives described below.
If you do not complete the learning assessment for a learning objective the first time, you will have multiple chances to retry.
The objectives may change slightly during the semester as the schedule shifts.
I expect that by the end of the semester, you will have mastered the basics of object-oriented design. In particular, I expect that you will be able to
I expect that by the end of the semester, you will have significantly extended your skills in the design, implementation, and analysis of algorithms. In particular, I expect that you will be able to
;
I expect that by the end of the semester, you will have significantly extended your skills in the design, implementation, and analysis of abstract data types and algorithms. In particular, I expect that you will be able to
[covered, not assessed];
I expect that by the end of the semester, you will be a competent beginning software developer. In particular, in addition to having the skills described above, I expect that you will be able to
The vast majority of LAs look something like the following
Please provide evidence that you have mastered this learning objective. Your evidence will often consist of a combination of program code and narrative text to explain the code and its relationship to the objective.
[a field for your answer]
Please include citations, as appropriate.
[a field for your answer]
[ ] I certify that the answers above represent my own work, except as indicated in the citations.
These notes were developed in response to some student answers to LAs.
Many of the LAs have two fields, one for your answer and one for any citations you might have. Use the top field for both commentary and code. Use the citations field only for citations.
Please take the time to anonymize your code.
Please make sure to include reasonable citations.
Please follow coding conventions. (You’ll get credit even if you don’t, but it’s good practice to follow coding conventions.)
Please follow good coding practices.
When describing code, start with a high-level explanation. Often, that’s all you need.
Do not ask me to follow links. Everything you want me to look at belongs in your answer field.
Make sure that your description of parametric polymorphism does not also apply to subtype polymorphism. They are both kinds of polymorphism, but they achieve their goals in different ways.
Make sure to include code that demonstrates that you understand and can use parametric polymorphism.
Make sure that your description of subtype polymorphism does not also apply to parametric polymorphism. They are both kinds of polymorphism, but they achieve their goals in different ways.
Make sure to include code that demonstrates that you understand and can use parametric polymorphism.
For data abstraction, think about how we’ve designed ADTs and their corresponding implementations all semester.
Make sure that you explain why we want to use data abstraction (why we want to separate interface from implementation).
Our textblocks are not a very good example of data abstraction, since the interface there is intentionally open-ended. Look for an interface where there is a clear expectation of what each method does; one in which all implementations should do the same thing on the same series of procedure calls.
Your goal here is to think at the internal design level; not separating user interface from implementation, but separating the interface to a library from the underlying implementation of that library.
Identify objects and classes that will contribute to a program or solution, design those objects and classes, and implement those objects and classes.
Note that this asks you to give a problem, describe what objects and classes will help you solve that problem,, and give the implementation of those classes. A single class, without context, is unlikely to suffice.
There was some confusion on the questions I was asking. I’ve clarified them on the latest version.
Make sure your algorithm is correct.
Make sure you explain the inputs and outputs.
Please follow custom and write ranges as “lower-bound inclusive, upper-bound exclusive”.
Searching algorithms traditionally search for (a) a matching value, (b) a key, or (c) an element that meets some criteria.
Hence, “find the smallest value” is not an example of sequential search.
Please make the “insert” in insertion sort explicit in both your
code (i.e., by writing a separate insert procedure) and your
narrative.
Very few people seem to have written an indexOfSmallest or
indexOfLargest procedure. Decompose!
Please follow custom and write ranges as “lower-bound inclusive, upper-bound exclusive”.
Please follow custom and write ranges as “lower-bound inclusive, upper-bound exclusive”.
Make sure that you clearly explain the principle of “divide and conquer” before you go on to your example of you employing that principle.
Even though Java includes it, get(int i) is not a core list operation.
Here and in other ADTs/DSs, start with the PUM, or at least something like the PUM. At least the PM. At least the P.
Bit trees are not BSTs. Neither are heaps.
Please include code for get and set.
Make sure to explain why we use arrays in implementations.
Make sure to explain how you are using an array in the implementation.
Make sure to include code that explicitly works with an array.
Make sure to explain why we use linked structures.
Make sure to explain what the linked objects are in your structure. (The “nodes” or equivalent.)
Make sure to include code that uses your linked objects.
This LA is a bit less open-ended. I will give you a particular ADT to design. You are responsible for all the parts.
When I say to give me a Java interface, please give a complete interface that I can compile.
This LA is also less open-ended. I will give you a particular ADT (or at least interface) to implement. You need not write working Java code. However, you should explain how you will lay out the data (L) and how you will implement the the operations (I).
The analysis part of data structure design means that you analyze the running time of your methods using bit-O notation (A).
I need more than “I wrote code with someone else”. Please describe your process and why it was successful (or how you made it successful).
Too few of you include comments in your unit tests. In my experience, you will forget why you wrote your tests. The comments help us remember.
assertEquals(Expected, Expression);assertEquals("Message", Expected, Expression)I expect to see a mix of tests and explanatory text. The text should explain what unit testing is and why we use it. It might also describe the tests. The tests should be sensible, real tests.
Please include a git log from a project.
Remember that the log is supposed to show collaboration. That means there should be more than one committer (or an explanation as to why there’s only one committer).
ode reading is more than “there’s a for loop here”. You should describe the design decisions embedded in the code and the relation of the class to a larger ecosystem. (Why did someone create this class?)
The specification says “Read, understand, and modify code that you did not write.” I’d like to see appropriate modifications and a description of that modification.
Central tips:
The following things would be nice, but are not strictly necessary.
// Add one to x above x++; does not help the reader and therefore
just clogs your code.Please focus on libraries in which you don’t know the internals. (That is, don’t say “I used Sam’s X class.”) You’ve demonstrated knowledge of using such libraries in the Code Reading LO.
Most of the libraries you’ve used are from the Java API.
Signal and recover from errors using exceptions.
Make sure you include an example of throwing an exception.
Make sure you include an example of catching an exception (or being ready to catch an exception).
Make sure that your recovery is reasonable.
Narrate both.