Communication Lab 9
Level Design (Building Blocks)
Due: Saturday, April 1st at 11:59 pm
Code walkthroughs are
an important part of the software engineering process. As your group gets more an more
used to your current software design decisions, everyone has a harder time seeing the
problems. A code walkthrough allows a reviewer with fresh eyes to look at what you have
done. The reviewer can tell you whether the code is understandable, and point out possible
Another advantage of the code walkthough is that it gives you a chance to compare your
code to your
You might think that the specification was an accurate representation of the code that
you have written so far, but an outside observer might have other ideas.
In today's communication lab, we will pair you with another group for a code walkthrough.
You will each present your code to each other. In addition, we will make sure that every
pair has a dedicated programming TA with it at all times, in order to facilitate the discussion.
Preparing for the Communciation Lab
This communication lab is a little different from ones in the past that you must
come prepared a head of time. In particularly, you need to bring two things.
A print out of your dependency diagram (nothing else) from your architecture specification.
A snapshot of your code either on a laptop or on one of the lab computers.
Neither of these items requires that you create anything new for the lab. Your snapshot
can either be the current state of your repository or your submission for technical
prototype. Your dependency diagram can be the one you submitted, though if you have
made changes to the architecture since my comments before Spring Break, you may want
to bring an a new version of this diagram.
Each group should take turns doing a walkthrough. In the time alloted, that means
20-25 minutes per group. The group making the presentation should have a single
presenter by the computer with the code, while the reviewing team gathers around.
If you want to swap out presenters during the walkthrough, that is okay. However,
it might get crowded around the computer, so make sure that the reviewers can always
see the code.
At the start of the presentation, hand out your dependency diagram to the other
team so that they can look over it while you walkthrough the code. Then your presenter
should show off the major classes in your code (e.g. the ones that correspond
to those in the dependency diagram, not the minor classes like the North-East-South-West
enumeration that you did not bother to write down). We recommend that you show off the
classes in the following order.
The root controller class
Any controller subsystems (e.g. specialized controller classes)
The primary model class(es)
The primary view class(es)
Your presentation should show how they all fit together.
Reviewing the Code
While one group is presenting their code, the other group -- the reviewers -- should be
frequently making comments and asking questions. In particular, the reviewers should
ask themselves the following:
Is the code organization understandable?
How easy is it to break up the work among several people?
How extendable is the software architecture?
Do the class relationships match the dependency diagram?
We do not necessarily want the reviewers to ask the questions above to the presenter.
Instead, reviewers should ask questions that help them form their own answers
to the questions above. And if there answers indicate problems with the architecture
design, the reviewers should point that out to the other team.
There is nothing to turn in for this communication lab. The purpose of this lab is to
give you peer feedback on your architecture, so that it can be finalized (and so you can
focus on content from now on).