Introduction
完成一个Shoddy Software Incorporated系统的软件设计，分为五个小Task。
Scenario
As software becomes more and more complicated, it creates a need for formal management of testing and bug-reporting. Shoddy Software Incorporated have been looking for a suitable way to scale up their existing testing schemes, and have come to you for the design of a system that would meet their needs.
Their proposed system has three key data elements:
- All stored bug reports, along with associated metadata:
a. Who reported it
b. When it was reported
c. Any runtime traces that were generated
d. Comments from the reporter
e. Whether the report has been fixed
f. To which part of the system the bug report belongs. - Testing strategies
a. Input data
b. Expected output
c. Actual output
d. To which bug report the test belongs
e. Comments about reproducibility - Comments
a. Who made it
b. When
c. What was the comment
d. Does it require further action?
They are looking for a system which allows for new bug reports to be generated by their quality assurance team, and for testing strategies to be added by their test team. The system then requires two interfaces:
- A system for adding and browsing bug-reports.
a. It should allow for the fixed status of reports to be changed.
b. It should allow for new comments to be added - A system for adding testing strategies to bug-reports
a. It should allow for input data and expected output to be added
b. It should allow for later actual output to be set
c. It should allow for new comments to be added.
At any time, the managers of Shoddy Software Incorporated would like to be able to generate a report on their software. This should show which parts of the system have the most unfixed bugs, which bug-reports are missing testing strategies, and how many bugs remain to be fixed. It should also show how many of the reports in the system have been fixed versus how many remain unresolved. They also stress it’s important to be able to search the database on any the fields stored across either of the data sets, or both.
Your application then needs to provide the following functionality:
- Allows for new bug reports to be added
- Allows for new testing strategies to be added to bug-reports.
- Allows for the user to browse bug-reports
- Allows for the user to browse testing strategies
- Allows for the user to search reports and strategies.
- Allows the user to output a report on the state of the system
- Allows for the user to add comments to bug reports.
- Allows the user to add comments to testing strategies.
Your solution will consist of a class diagram, a use-case diagram, an activity diagram for the process of the user creating a bug report, creating a testing strategy for it, and then marking it as fixed before generating a report as outlined above.
Task 1
Candidate class list and Diagrams
The candidate class list should incorporate justifications and discussion as to why each class was selected for inclusion, and how its relationship to other classes was derived. The class diagram should show attributes, operations, scope and relationship of classes to each other.
Task 2
Activity diagram
The activity diagram should incorporate the classes involved in a user specifying a computer system.
Task 3
Use case diagrams
The use case diagram should incorporate each of the user activities indicated in the brief.
Task 4
Code architecture
This involves creating a code architecture that shows an appropriate level of coupling and cohesion, along with the necessary amount of inheritance and encapsulation to express the system.
Task 5
System implementations
This is for implementing the system as described and providing the completed Java code.
Submission requirements
- Your program must be submitted as a zip file of the full project.
- Whatever IDE you use, it should be possible to open and run the project directly from the extracted archive.
- Diagrams and materials associated with the tasks above should be presented in a word-processed document.
- All references and citations must use the Harvard Style.