View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

M4 Domain Design and CRC Summer 2007

Techzilla Specifications:

User Types

The system should ensure that users who login to the system only have the appropriate rights. The system does not have to encrypt passwords. They may be stored in plain text. For basic credit, each user has a single type. For extra credit, you can model the fact that someone may be a manager for Project 1, a developer on Project 2 and just a customer for all other projects.

Bug Reports

When a user wants to submit a Bug Report, they first must login and then select the Project from a list of available projects in the system (the projects which the admin has set up). The user must then provide the following information:

The system then creates a new bug, adds it to the project and timestamps it. The bug is given a status of new and the bug is assigned a unique ID number.

Managers can request the system display a list of new bugs. For each bug, they can change to status to rejected (the bug does not exist), open (the bug does exist but is not assigned to anyone), closed (the bug has been corrected), or assigned (the bug does exist and has a developer working on it). If the Manager sets the status to assigned, the system should prompt for a developer to assign the bug to. The manager should be able to select the developer from a system-supplied list of developers (dev user type) assigned to the project and should also enter an approximate estimate of the effort in hours.

Developers can search for all bug reports based upon any of the following criteria:

Developers can mark bugs assigned to them as fixed. This results in a status change. When marking a bug as fixed, the system should prompt for a resolution (text), which is recorded in the bug report. Developers should also be allowed to record the number of hours actually required to fix the bug.

Customers can request a display of all outstanding bug reports (all those with a status that is not closed or rejected) or of all rejected bug reports.


The system should provide the following formatted reports:

Other than the required information, your team is free to design the reports and layout in the manner you think is most appropriate.


You must be able to save the application data to an external file, shut down the application, restart it and load the data back from the external file.

Extra Credit

Besides the extra credit already listed, your team can propose other extra credit opportunities for design and implementation. As students propose extra credit ideas, I will post them here. Extra credit is applied to the programming portions of the assignment (10% of your grade) so that 10 points extra credit would add 1 point onto your class average.

1. Hook up a database to the system for the backend.
2. Extensive UI enhancements (really nice charting and graphing, autoscaling on window resize, etc)
3. Additional project management or bug track features (look at some of the commercial products for ideas)

M4 Requirements

  1. Make a team page and indicate your team members and which option you are pursuing.
  2. A brainstormed list of Domain classes
  3. A list of candidate classes after filtering
  4. A set of CRC cards for the candidate classes. Cards should be filled out on both sides (role stereotypes and responsibilties/purpose).
  5. A set of scenarios that cover typical uses of system and exercise the CRC Cards.
  6. Meet with assigned TA after submission to discuss your design

Grading Criteria

Brainstormed Classes.......................... 10
CRC Cards..................................... 30
Scenarios..................................... 20
Role Stereotypes, Purpose and Responsibilities 10
Team page setup............................... 10
TA Meeting.................................... 20

Link to this Page