Reputation: 2121
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.
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
Upvotes: 2
Views: 299
Reputation: 334
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
.
Upvotes: 1