CSC407S/ECE450S/CSC2103S Assignment 1

Part (a) due Feb.1,   part (b) due Feb.15

For this assignment you are to do an Object-Oriented Analysis for the problem statement given below (part a); and then produce an Object-Oriented Design, a Java program, and sample output from your program (part b). You mainly will be marked on the quality of your analysis and design, and on how well you explain them. For both parts, neatness, legibility, good grammar and good spelling all count (as they most certainly do in the real world!).

For part a) you are to hand in a document containing UML OOA class diagrams and written explanations of these diagrams. Do not produce one large diagram. Rather, divide it into parts and present it that way.

For part b) you are to hand in a document containing UML OOD class diagrams and written explanations of the diagrams. Again, divide the diagrams into pieces for explanation and presentation. You are also to implement (part of) your design in Java, and hand in neatly formatted source code, along with actual test output from your program.

To save you programming effort, you can assume that the parts of the system that deal with file input are being designed and implemented by somebody else. Design only an interface to the file input section. To enable you to test your part of the implementation, provide scaffolding as a place-holder for your interface that allocates and connects together test objects programatically, different testing sets depending upon the filename parameter (see below).

The Problem (A Customer Speaking)

[Note that the problem statement given below is both incomplete and self-contradictory.]

"We need a program that helps us to plan new releases of our software. We currently have a big XML file that lists all the new feature requests together with who (from within our company) champions it, the names of any outside clients that want the feature, and how badly they want it (on a scale of 1 (least) to 10 (most)). The feature requests have a numerical id, a short description, a long description, and the software product to which each applies. There is also a sizing in person-days attached to each request that is supplied by our developers, and an assigned priority attached by our product managers of high, medium, or low.

"The program should get the name of this file and from the command line, and also the name of a product and the number of person-days of development resource we have available to work on the next release of that product. e.g.,

    java Plan features.xml Planetaria 340

"The program should provide a suggestion for a good list of features for the next release, the sum of whose sizings are less than or equal to the available resourcing. Allocate as many of the higher priority features as you can. Favour features that are more highly desired by customers. With any room left over, choose lower priority features if you must in order to pack the plan.

"For the output, echo back the input and summarize the total number of all features in the file (for that product) together with the sums of their feature sizings broken out by priority (also providing the grand-total). Similarly, summarize the same things for the chosen in-plan features. Then output the list of in-plan features for the product, in priority order, giving id, short description, priority, sizing, champion, and how badly customers want the feature. Finally, clearly separated from the above, output the highest priority features that didn't quite make it in-plan, up to available resourcing * 1.5.

"If this project works out, we can see many more different types of applications all dealing with the same file. Be sure to design it to be easily extensible. Oh, and use Java. It's our corporate standard for this kind of thing.