How the associations are designed is up to you to decide, largely
based on your high level design and any changes you need to make to it
as you refine the details of the design in this stage. For example if
each instance of class X needs to have access to an instance of class Y,
you might in one case say, "class X will have a member variable named
"y_ref_" that is a pointer to an instance of class Y". Alternatively,
in another case you might say "class Y will be a singleton that
provides access through its instance() method".
By the end of this stage, the code should be "all but written". That is, in the implementation stage you will still need to fill in the definitions of the methods and functions you have declared and make any extensions to the code required by those definitions. However, other than that, by the end of the low level design stage you should have at least a very detailed declaration of the structure of your code.
The low level design document should contain a listing of the declarations of all the classes, non-member-functions, and class member functions that will be defined during the implementation stage, along with the associations between those classes and any other details of those classes (such as member variables) that are firmly determined by the low level design stage. The low level design document should also describe the classes, function signatures, associations, and any other appropriate details, which will be involved in testing and evaluating the project according to the evaluation plan defined in the project's requirements document.
More importantly, each project's low level design document should provide a narrative describing (and comments in your declaration and definition files should point out) how the high level design is mapped into its detailed low-level design, which is just a step away from the implementation itself. This should be an English description of how you converted the technical diagrams (and text descriptions) found in your high level design into appropriate class and function declarations in your low level design. You should be especially careful to explain how the class roles and their methods were combined in your low level design, and any changes that you decided to make in combining and refining them.
Participation: every member of your team should be significantly involved in the production of this document, though how you structure the interactions within the team is up to you. For example, it's fine for one person to capture notes from a group discussion of the low level design document and write it up as long as the other team members contributed materially to the discussion that is captured.
Deadline: by 11:59pm on Friday, June 5, 2009, please e-mail your team's low level design document to Prof. Gill at cdgill@cse.wustl.edu.
As with the requirements and high level design documents, your team should treat this low level design document as a "work in progress", evolving it appropriately throughout the development cycle, and by the evaluation stage the documents you have produced previously should constitute most of your evaluation report, other than the evaluation results and analysis which you will add in that last stage of the cycle.