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.
LAs will be given as take-home problems.
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.
In solving those problems, you should rely primarily on (a) the course Web site, (b) the standard Java reference pages, (c) your notes, (d) the code you’ve written, and (e) CLRS. You should not search the Web for answers, you may not use LLMs, and you definitely may not use StackOverflow or Geeks4Geeks. When a problem asks you to provide sample code, you should use code you’ve already written for the class (or updated version of that code).
If you use resources other than your own code, such as those mentioned above and including code I’ve written, you should make sure to cite those resources.
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
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 that you’ve written for the class (or an updated version of that 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 subtype polymorphism.
Overloading (using the same name but different parameter types for different meethods) is not the same as subtype polymorphism.
For data abstraction, think about how we’ve designed ADTs and their corresponding implementations.
Make sure that you explain why we want to use data abstraction (why we want to separate interface from implementation).
Emphasize the general concept of interface (what) vs. implementation (how), not the Java specifics.
Our textblocks are not a 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 utility code from the underlying implementation.
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.
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”.
Please make the “insert” in insertion sort explicit in both your code (i.e., by writing a separate insert procedure) and your narrative.
Decompose! You should write an indexOfSmallest or indexOfLargest procedure.
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.
Make sure you understand the “is in” notation and why we use it.
You may only use the master theorem to check your work. Please solve these by bottom-up or top-down analysis.
Even though Java includes it, get(int i) is not a core list operation.
Here and in other ADTs/DSs, start with the SAM, or at least something like the SAM. At least the SM. At least the S.
Bit trees are not BSTs. Neither are heaps.
Please include code for get, set, and either an iterator or forEach.
You need not include code for remove.
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).
Make sure to describe the basic purpose of iterators.
While you may choose a data structure I implemented, make sure that you implemented the iterator.
You need not implement the remove method.
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).
If your first collaborations were not successful, you will have to wait until you have a successful collaboration.
You should explain the “big picture” of build tools. Why do we have them? What do they do?
You should also explain the basic use of Maven.
In this instance, your “code” will likely be appropriate selections from your pom.xml that you’ve written or modified. You should explain those selections.
I expect to see a mix of tests and explanatory text. The tests should be sensible, real tests. The text should explain what unit testing is and why we use it. You might also describe the tests.
Make sure to include messages in your unit tests (assertions). In my experience, you will forget why you wrote your tests. The comments help us remember. (These probably aren’t necessary in all cases, but they are usually good and should be part of your demonstration of best practices.)
assertEquals(Expected, Expression);assertEquals(Expected, Expression, "Message")Remember that your goal is to demonstrate that you know what an IDE is and that you are capable of using an IDE.
Make sure that your answer would not apply to a more basic program editor.
Do not provide Java code, unless it helps you tell a story.
Make sure to explain what version control is / what version control software helps you do.
Please include a git log from a project. You should be able to obtain the log with git log or git log > FILENAME.txt.
Please explain what key aspects of that log demonstrate.
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).
Make sure that the code that you’re discussing comes from this class (e.g., code provided in a reading, lab, or mini-project template). Make sure to include that code in your discussion.
Code reading is more than “there’s a for loop here”. You should describe the design decisions embedded in the code. You should also describe 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 descriptions of those modifications. (Make sure to include the modified code.)
Central tips:
// Add one to x above x++; does not help the reader and therefore just clogs your code.You can think of a library is one or more related classes.
You should describe the library you built and how it might be used in other programs (or, preferably, how it is used in another program).
Do not use java.lang.String as the library.
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 already demonstrated knowledge of using such libraries in the Code Reading LA. I want you to describe the use of a library which you only understand through the documentation.
Please don’t use libraries that get used in your programs, but that you haven’t used directly, such as the speech libraries from the AAC MP.
Most of the libraries you’ve used are from the Java API.
Signal and recover from errors using exceptions.
Make sure you include a real example of throwing an exception.
Make sure you include real example of catching an exception (or being ready to catch an exception).
Make sure that your recovery is reasonable.
Narrate both.
How much time can we spend on an LA?
As much as you want.
How much time should we spend on an LA?
Here’s my model.
(a) What’s the basic idea? Let me check the reading. (5 min).
(b) Hmmm … I know I did this. But where? (5 min).
(c) Find that thing, copy, paste, edit (5 min).
(d) add commentary (5 min)
So about twenty minutes.
Will you grade SoLA N before we have to turn in SoLA N+1?
That’s my goal. However, life is complicated.
What code should we use for the LAs?
You might use code from a lab. You might use code from a mini-project. I would prefer code from mini-projects, since it’s more “you wrote” than “you adapted”.
Can we use the same code for multiple LAs?
Certainly. Thanks for asking.
Will we keep getting a chance to redo an LA until we get it right?
Yes, only until the semester ends. And there are no token chages for LA redos.
Will we have only one chance for LAs based on the last week of class?
No. You will have at least two chances for each LA.
Do we have to do a SoLA each week?
I expect you to try at least one LA each week.