Comments on Project #1, CSCI 5931A, Fall 1998

Comments on Project #1
CSCI 5931A Advanced Database Development

Finally, after spending my weekend in grading, I have completely graded project #1. I cannot grade every detail of your work as it will take tens of hours more. I just selected the more important parts of your projects to grade. I also did not write down all the problems to save time. Instead you should read the problems I listed below.

Use Cases

Use case diagrams are used to specify the external view of the system: system functionalities (use cases) and how external users (actors) interact with the system. The goal is to define the boundary of the system.

One of the most common problems in project #1 is to model the students to "enrol courses", "pay tuition", "transfer courses", etc. Students do not interact with the systems to do these tasks. You don't want them to do that themselves for security reasons. Instead, it is likely staffs will interact with the systems to do these tasks (with input from students).

Other issues:

Use cases are functions provided by system and are not activities outsides the systems. Examples:

Many of you have the use case "offer course" with input from the faculty. However, "offer course" is an activity mainly provided by the faculty, not the system. If you include "offer course" as a use case, you may specify more clearly what functionality the system provides, for example, 'set and read notes' and 'schedule courses'. However, for these examples, you may simply want to use 'set and read notes' and 'schedule courses' as the use case names, which are more specific.
"Lead department" and "teach courses" are not functionality of the system.

If a use case is a central part of the system and is used by most other use cases, you may consider not including association to the use case. For example:

"authenticate password".

Do not use names that are too generic. Use names as specific as possible.

"read data from database", "access database", "view database", etc: does not tell the readers much.

Use cases are major system functionalites and should not be too refined, especially in the top-level view. Examples:

May consider merging the use cases "pay tuition" and "registrate course" into "enrol course".

Care should be given to identify the actors who interact with the use cases. Example:

If the actor "student" is associated to the use case "transfer courses", this means the students will be able to use the system directly to transfer courses. Thus, the more reasonable assumption is for the clerks to be associated with "transfer courses".

Do not confuse the use case diagrams with data flow diagrams. They do not show how data are moving. Examples:

Actor "Studnet" --> use case "Registrate Course" --> Actor "Clerk" looks more like something in data flow diagram and is not appropriate.
"Student" --> "Evaluate Courses" --> "Faculty" not appropriate.
Confusing a use case with a data source (e.g. "Access Database": "A database contains all users can access."; "class information system")

Priorities

Your priority list should in general include the followings:

Schedule courses
Enrol students.

This is because your business is to make money by offering courses to students. Without these two use cases, your system prototype will not adequate. Other use cases are less important and may be implemented later. For example, "make teaching notes" is obvious not of central importance. Even "check password" or "Create and manage accounts" are less important as in the first cut of your prototypes, you may ignore security issues and focus on the business functionality

Class Diagrams

The most significant and frequent errors are confusion between "course" and "course offering". Many missed the class "course offering". Many have wrong associations. For examples, associations between "enrolment" and "course" is incorrect. It should be between "enrolment" and "course offering". Formally, you are not enrolled in "CSCI 5931A", but the offering of "CSCI 5931A", section 1 in the Fall semester of 1998.