Question

Is my aggregation relationship of my class (between ArrayCoordinate and Tile) is correct (especially the arrow direction)? If not, could you please provide a quick explanation on it?

Note : I've read some article on this subject, and I feel can't fully understand this matter. Thanks in advance.

My class diagram

enter image description here

enter image description here

EDIT : Short description about the diagram : Those are my class from my tile based strategy game. The Tile Class represents each tile on my "game board" to store objects a tile can contains of (e.g. character, tree, etc). And the ArrayCoordinate represents the indexing of a tile, for iteration purposes (similar to C# Point class).

EDIT 2 : On Tile and ArrayCoordinate, the brief relationship explanation is : Every Tile has an ArrayCoordinate, and there is no tile without ArrayCoordinate. And every Tile always have at least 1 TileObject which also have ArrayCoordinate, to access it's location directly without accessing the Tile first. (Sorry if my explanation is confusing, please feel free to ask

Was it helpful?

Solution

Every UML is correct as long as we know it's interpretation (because we may not follow the standards for UML).

About your question:

Is my aggregation relationship of my class (between ArrayCoordinate and Tile) is correct (especially the arrow direction)?

Even that I know that your UML was designed on visual studio I don't really know the designing details of it and I'll be answering for general UML diagrams.

The answer depends on how do you interpret your own UML. Most of the times, when there is a relationship of 1-n between class A and class B, there is a arrow coming from class A pointing to class B, it may optionally have a * near class B (indicating that there is many of those B) and may also include a name in the arrow that indicates the name of the field that supports that aggregation. If the name is indicated in the arrow normally you can remove it from the UML fields so you don't have redundant information (replication). However your UML doesn't either have a name on the arrow nor it have a field that may indicate that relationship actually exists.

Secondly, and according to my reasoning, the UML representation of the aggregation between TileObject and Tile is in the wrong direction OR it is missing and actually exists but the UML as it is doesn't provide that information (expanding your TileObject class would help).

EDIT: About your new TileObject UML I would say that there was missing a field that supports the relationship with Tile however it seems that visual studio represents a 1-n relationship with a filled rhombus and doesn't include the fields that supports that relationship. Also it seems that sometimes visual studio represents a 1-1 relationship and other times it doesn't; in your example it represents a relationship between Tile and BattleManager with an unfilled rhombus however it doesn't do that between TileObject and ArrayCordinate. And if this is true then I am wondering why is there a n-n relationship between Tile and TileObject. (should it be a 1-n relationship instead?)

As I mentioned I am not really familiar with visual studio UML designer but I would try to keep the UML designing consistent (if possible). The only times that you want to skip consistency is to try to compact your designing.

About your second edit: I think you really should avoid to short the relationship between classes. By doing that you create an additional dependency and you have to know what is the purpose of that new field (which doesn't have a functional purpose but either a efficiency one). Finally most of times the benefits of doing that doesn't really worth.

Finally and answering your question: Your relationship between ArrayCordinate and Tile is fine because you stated the following:

ArrayCoordinate represents the indexing of a tile, for iteration

That means that must exist a relationship of 1-n between ArrayCoordinate and Tile.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top