Page 1 of 1

UML Class Diagrams

Posted: Wed Apr 05, 2006 1:02 pm
by Moocat
I'm still new to the OOP side of the field and I'm attempting to build a simple class diagram with UML. I'm having some problems figuring out how the relationships work though.

Let's say I have a player object/class and that player has a name, unique id and skills. Skills are seperate object/class containing name and id (for simplicity sake). There are many players in the game (multiplayer) and many skills may be assigned to each player. What is the relationship between them? 1..M? M..M? And what the heck do those little arrows mean? The ones that are filled and the ones that are not?

Thanks for helping out :)

Posted: Wed Apr 05, 2006 1:31 pm
by Deemo
i could be wrong but here is what i beleive is right:
The relationship of the skills to player is 1...M as you said. This means that every player has multiple skills. Although you may have many players, the UML diagram doesnt show that

Full arrow is Directional Association
Arrow sith Triagular head is implements
dotted arrow is Dependency
Arrow with diamond head is Composition

Posted: Wed Apr 05, 2006 1:56 pm
by alvinphp
You have three objects.

Player - This is where you add/delete/update/etc players.
Skill - This is where you add/delete/update/etc all the possible skills.
Relation_Player_Skill - This is what joins the skills with the players

The relationships would be this.

Player <-- 1..M --> Relation_Player_Skill <-- M..1 --> Skill

Posted: Wed Apr 05, 2006 3:06 pm
by Moocat
alvinphp wrote:You have three objects.

Player - This is where you add/delete/update/etc players.
Skill - This is where you add/delete/update/etc all the possible skills.
Relation_Player_Skill - This is what joins the skills with the players

The relationships would be this.

Player <-- 1..M --> Relation_Player_Skill <-- M..1 --> Skill
Why is the Releation_Player_Skill an object? Where do you get that from?

Posted: Wed Apr 05, 2006 3:09 pm
by feyd
The relationship between Players and Skills is a many to many relationship. In a relational structure, a middle man has to link the two together because any player can have any number of skills associated with them.

Posted: Wed Apr 05, 2006 3:55 pm
by alvinphp
Moocat wrote:
alvinphp wrote:You have three objects.

Player - This is where you add/delete/update/etc players.
Skill - This is where you add/delete/update/etc all the possible skills.
Relation_Player_Skill - This is what joins the skills with the players

The relationships would be this.

Player <-- 1..M --> Relation_Player_Skill <-- M..1 --> Skill
Why is the Releation_Player_Skill an object? Where do you get that from?
It is an object because it has methods and attributes. One of the methods in this object is associating players to skills. As this method deals with both Player and Skills you can't put this method in either object (Player and Skill) so you need to create a new object. The object is small, but very vital. And if you were to create just two objects (Player/Skill) then you would be forced to throw the above mentioned method randomly into one of your 2 classes creating an inconsistency.

Posted: Wed Apr 05, 2006 4:38 pm
by Moocat
I thought that would be more of just a relationship line. I didn't think it actually would have methods inside either. You said it connects the two through a relationship, but doesn't calling the skill just do that? I read up a little bit more and my understanding is something more like:


Player 1 --------> 0...M Skills
id ============== id
name =========== name
skills

(the = are just seperation)

Posted: Wed Apr 05, 2006 5:29 pm
by alvinphp
Moocat wrote:I thought that would be more of just a relationship line. I didn't think it actually would have methods inside either. You said it connects the two through a relationship, but doesn't calling the skill just do that? I read up a little bit more and my understanding is something more like:


Player 1 --------> 0...M Skills
id ============== id
name =========== name
skills

(the = are just seperation)
What are the attributes of your Skill object? If it is just one attribute what you have could work. However, if you have multiple attributes it is probably better to normalize.

For example. Your Skill entity has the following attributes....

Player Attributes:
Player_Id (PK)
Player_Name
Player_Position

Skill Attributes:
Skill_Id (PK)
Player_id (PK) (FK->Player)
Skill_Name
Skill_Description
Skill_Category


In your scenario you would have to add all the attributes everytime you added a skill to a player. In a 3 entity structure it would look like this...

Player Attributes:
Player_Id (PK)
Player_Name
Player_Position

Skill Attributes:
Skill_Id (PK)
Skill_Name
Skill_Description
Skill_Category

Relationship_Skill_Player Attributes
Skill_id (FK->Skill)
Player_id (FK->Player)

Everytime you added a skill to a player you would put it only in relationship_skill_player. You would then link this entity to the Skill entity to find out the Name, Description, and so on.

And this is more about database design and relationships then it is OOP. Though in OOP your class structure would be very similar to the database structure.

Posted: Wed Apr 05, 2006 5:32 pm
by alvinphp
And this topic would be much better in Theory and Design.

Posted: Thu Apr 06, 2006 2:37 am
by R4000
Im allready lost XD
wtf is a uml class diagram?
i proberly know, but ur throwing loads of MMO stuff around....

EDIT:
ah dont worry, googled it... i do know what it is.
good page for info: http://www.developer.com/design/article.php/2206791

Posted: Thu Apr 06, 2006 2:44 am
by Maugrim_The_Reaper
alvin's got it right I think... Your objects would closely resemble your database structure. Traditional games head in that direction most often since its more intuitive. But yeah, it's an M=>M relation without an intermediary.

UML is a method of graphically representing an OOP structure, i.e. boxes containing details of individual classes and arrows connecting the boxes which represent the relationships between objects. It makes everything more easily explainable than using plain text.

Posted: Thu Apr 06, 2006 1:44 pm
by Moocat
I may have failed to mention it, (ok I did :p) but I was looking more toward a Class Diagram than a database diagram. I believe I wouldn't need the relationship object in that type of model correct? That's more for a Database-entity relationship diagram from what I've been told (at work).

Posted: Thu Apr 06, 2006 2:44 pm
by alvinphp
Moocat wrote:I may have failed to mention it, (ok I did :p) but I was looking more toward a Class Diagram than a database diagram. I believe I wouldn't need the relationship object in that type of model correct? That's more for a Database-entity relationship diagram from what I've been told (at work).
If your application is one where people search for players and then add skills to the player then 2 classes would be fine where the method to add a skill to a player would be in the player class. However, if your clients search by skills and then add players to each skill (which I doubt) then you would want the method to add players to skills in the skill class. Again, you have a method that deals with 2 objects so it is not always easy to know which object the method should be in which is why some create a third object (even though that object is quite small). Hopefully this all makes sense.

Posted: Thu Apr 06, 2006 8:44 pm
by Moocat
Ah yes, I understand where you are coming from now. You would create a third object in order to objectify the relation of the two because you didn't know how the relationship would be used in terms of gameplay. The object would allow for an even more flexible system if in the future I decided to really switch things up and do things that wouldn't normally be allowed with a static method inside of a class. Although it wouldn't be that hard to re-write the class, I would then have to change all the calls to that method to the new object.

Posted: Fri Apr 07, 2006 4:01 am
by Maugrim_The_Reaper
Whichever promotes future flexibility with the least effort... Remember ease of maintenance is a big must-have. It's painful when all those small changes gang up on you and become a task that could consume days of effort and testing.