Design Document Grading

Team: Yakko Wakko Dot Dayplan

Grade: (90 out of 100)

The following is a breakdown of the grading.

Document presentation (5 out of 5)

Important points:

Organization: good
Document author: OK
use of English: a few grammar errors in the class descriptions. Mainly the wrong tense for verbs.

Comments:

Project Description of Target System (5 out of 5)

Link to other documents? OK, you used a link to the description contained elsewhere, as suggested.

Comments:

High-level architecture (25 out of 30)

static description (box-and-line type diagram, or suitable substitute): It looks like you tried to modify the example architecture for your own purposes. That's good, but there are some things that don't make sense to me. I don't understand why you have separated out the Dayplanner applet on the WWW server side. The applet is going to be contained inside some HTML document that contains the correct APPLET tags to download the class definitions. The HTML and class files reside in the FileSystem that is serviced by the HTTP Server on the WWW Server. The action of invoking the Dayplanner applet is a request from a WWW client to the WWW Server that hosts the Dayplanner applet.
You should indicate where the .dayplan file exists. I believe for now it can only exist on the file system served by the WWW server that hosts the applet. Ultimately, that will change.

It is not at all clear what role the External Viewer and the View Control components are playing in your system.
dynamic description (Can I tell how the system executes over time?): There are some terms used in this dynamic description that are unclear and not previously defined. For example, what is the "free-text"?
use of standard or understandable notations: There is an arrow in the high-level architecture that is thicker than the others. I assume this is just an error. I am interpreting the control arrows to mean passing a message to an object and the data arrows to mean passing arguments in a message. Given that interpretation, I don't understand the data only arrows.
completeness

Comments:

Design specification (25 out of 30)

module/class definitions (identified, interfaces provided): you provide information on the class names, the superclass and a prose description of what that class does. You do not provide explicit description of the instance and class variables nor the method list associated with the class. This is important design-level information that is required for coding.
following a prescribed method (mainly for OO people): no real evidence that you followed a process for deriving your object model and static design specifications.
use of standard or understandable notations: You appear to use the Coad/Nicola notation, but you should be explicit, and even put a reference to a definition of the notation in your applicable documents section. The static model diagrams are a bit hard to comprehend with the lines going all over the place, but that is not such a big deal.
completeness

Comments: How do the problem domain and interface descriptions relate to the high-level architecture?

User Interface (30 out of 30)

where relevant, is the human interface well-defined? Yes.
evidence of UI design (screens, drawings, etc.) Yes.

Comments: well done

If you wish to have your Design Document regraded, revise it within one week of receiving comments. Be sure to maintain a link to the original version of the Design Document in your notebook for comparison purposes. To get a regrade, you must send e-mail to the instructor requesting the regrade.