Project Iteration 2: Initial Design
Present your initial design and your evolved use-cases. You are not required to submit any code or tests at this point, but nonetheless you should be coding some core functionality by now.Your web-based document needs to include all of the following components, in sections/subsections named as the boldface below.
- Give your names, group number, and project title at the top.
- Give an Overview as in the previous iteration; update your features list and GUI sketches to reflect your improved understanding and greater focus of your project. Additionally please identify the key features of your project, the ones you plan on targeting first for implementation. Or, you can instead identify core use-cases of your list of use-cases as the key use-cases to implement first. Also, if some features are "if time permits" indicate that as well.
- Describe the Architecture, both at the system level and the package level. If the architecture involves multiple components, describe the components and how they will interact. For instance, in a distributed game design, describe whether it is client-server, peer-to-peer, etc, describe where data is stored, etc. Include other external systems involved such as web server, database, etc. A UML Component diagram/Deployment diagram is recommended if your system architecture has more than a couple nodes. Also give a proposed factoring into packages.
- The Use-cases again. Refine the use-cases from the
previous iteration as
appropriate. For this iteration we are going to verify that
you have appropriate use-cases covering your proposed class
design, and that the actions in those use-cases map to methods
in the classes. One of the most common loss of points on this
assigment is incompleteness on these two issues.
At least one UML Sequence Diagram (required) illustrating one of your more complex use-cases must be included. This will show proposed messaging to implement the action of the use-case. Make sure the messages used in this diagram are in the class design proposal as well. - Include a Domain Model if you already did one in your requirements document or you subsequently concluded one was needed.
- A Class Design Proposal, in the form of JavaDoc web documentation. In other words, write commented Java code headers for the proposed classes. Write a brief overview of the responsibilities of each class, and for the non-obvious methods describe what they do. It is recommended (but not required) that you use CVS or other version control system to develop this design. (by the next iteration you will need to be using a version control system.) Break down your code headers into appropriate packages if that structure is apparent.
- A UML Class diagram (or diagrams). The diagram(s) should be reasonably complete in that associations etc alluded to in the class instances or use-cases should be shown in the diagram. However, also try to keep the diagrams from becoming so big and the edges so tangled that it is not readable. An unreadable diagram is a useless diagram. For instance, showing lots of methods in the classes, and thus making them really big, is generally not a good idea. Also, if things are getting messy diagram each package separately so there are many small diagrams instead of one large diagram.
- Give a listing of Resources you are using, as in iteration 1, but with any modifications.
Goals
Some of the goals you need to achieve in your design proposal include
- Create a proposal readable by an outsider (imagine a new member joins the team and is given just the document).
- Completeness: this is an important issue because there is no clear "goalpost". The target is to have classes proposed for the core of the design. One way to see if you missed any classes is if there is a use-case for which there is no obvious class(es) to assign its functionality to., or vice-versa.
- Avoid major pitfalls of poor object-oriented design.
- Your proposal for use of advanced Java is appropriate use of those features.
- Use UML as needed. You will need to at least do a class diagram and a sequence diagram, but if there are other complex aspects of your design which fit well into e.g. a UML state diagram, you should include one. One of the things we will look for in grading is diagrams we feel would have been very useful that were not included.
Posting Instructions
As before, produce an html document of your design and post it on the web.