Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Class diagram

Status
Not open for further replies.

centrino

Programmer
Mar 17, 2004
8
MY
Hi. I am new to OO system analysis and design.
I am trying to develop a simple aircraft shooting game in java. It will be an application type not an applet.

However, I am confused in the OOA&D approach. I am confused about including things like save game , reload, difficulty level,game pause etc in the class diagram.

How can I include things such as ship, enemy ship, shoot, missiles available, etc.... in the class diagram?

Should these two parts be in different class diagrams or should I include both in the same diagram?...I mean should the game functions and interface components appear in the same class diagram?...can n e one pls guide me.

thanks a lot.


 
Using a model-view-controller (MVC) pattern, you should generally try to keep these things separate. If you are using a UML modelling tool, all the classes will be held in the tool's model. But you might want to create several diagrams that highlight different aspects of the design. Don't forget, the diagram is there to help you (and others) to understand the system. Just because you can put all the classes on one diagram, doesn't mean that you should. I have seen class diagrams printed in small fonts on A0 size paper. They look like spiders webs, and are great for advertising how clever you are or how much work you've done. But there is too much detail on them to make them any use for trying to understand what's going on.

A number of smaller, more focussed diagrams will help you to understand the major interactions in your system more clearly.
 
Centrino,

See if this helps:

FIrst of all, try to look at it as static models and dynamic models.

1. Use Class diagrams etc, to model just the classes and hierarchies in your problem domain, maybe just modelling the nouns of the problem statement. At a later stage in the design, you can include more detail like their methods and responsibilities.

2. Use other type diagrams such as simple sequence diagrams, statechart diagrams to make the dynamic elements clearer.

hope that helps

/Srikanth

Asked clerk for self-help section. “That will defeat purpose.”
 
...and use a mindmap in the beginning, to collect all that stuff - every keyword a word, and only simple lines, to indicate relationships.

When you're finished, collecting the important keywords, you may start to identify the central classes.

Whether a 'shot' is a method, reducing your 'numberOfShoots', or a separate class, perhaps implementing 'Shootable' or extending 'AbstractShot'... decide later.



seeking a job as java-programmer in Berlin:
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top