The first draft
My first draft was to split the information into different categories: general, physical and graphical. Also there is a split between an instance of an entity and an entity, i.e. an instance of an entity resides somewhere inside a container.
My next step was to create a C++ class that does it. Add an entity editor, start working on it. And find out that the design was limited...
To make a long story short, the folowing diagram shows my first draft. The diagram was generated after a C++ class was created and it is generated by the program dia (free software).
I couldn't find a definitive answer on the subject, but it can be a good idea for a small program to start programming before any UML diagrams are done. Be aware that when you start to use a UML diagram, you might find that there is too much dependancy between objects. So be ready to start again from scratch.
This diagram introduce aggregation and composition. The former is represented with an white diamond. It indicates the part-of relationship. The difference between an aggregation and an association is very muddy. If you don't bother with it, it's not a big deal. The second one is composition and is represented with a black diamond. It indicates that the part object can only belong to a unique whole and that the part will live and die with the whole. Deleting the whole will usually delete all of its composition parts.
The hierarchy between GeneralInfo, GraphicalInfo and PysicalInfo is quite clear on that diagram. EntityLocation and Container are derived from Entity. EntityLocation adds an offset and a sprite. A sprite is just the graphic that is displayed at that location.
Some bad UML design seen on that diagram:
In EntityLocation, I specify too much information. This is not needed. It is usually implied that if there is a variable then there is also a method to set and initialize it.
- I could have left the association with the Info classes nameless. A nameless assocition means that the association has the same name than the class.
- The Box class doesn't add a lot of information to that diagram.
Problem with that design
The problem with that design is that adding functionnality is difficuly. I wanted to add a mapping between states and graphics. I want to be able to specify that a graphic of a tree goes with the state: season=winter. With only one state, this would be easy, however adding multiple states complicates the process, states can be something like "status=alive,dead", "season=spring,summer,fall,winter", "cut=yes,no". So for the case "status=dead,cut=yes,season=winter", I want to display the cutted base of a tree with some snow on it. To add to the confusion, the former graphic can actually be a composition of multiple graphics pasted on to each other that creates the final graphic. Also, the fact that cut=yes, means that the bounding volume of the entity has now changed. The editor needs to store a normal and a cut bounding box volume.
The other problem of that design is that everything is hard coded. For instance, there is a weight and volume associated with the physical information but nothing more. Although with inheritance we can add as many information as we want. An objects needs to be casted to the riight class to have access to this new information.
Next: Dia/UML Tutorial/Second design
Created: Sat Jan 16 18:04:10 EST 1999 Last modified: Sat Jan 16 18:29:51 EST 1999