UML Class Diagrams

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

Post Reply
User avatar
Moocat
Forum Contributor
Posts: 143
Joined: Wed Oct 12, 2005 9:28 am
Location: USA

UML Class Diagrams

Post 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 :)
Deemo
Forum Contributor
Posts: 418
Joined: Sun Jan 18, 2004 11:48 am
Location: Washington DC

Post 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
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Post 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
User avatar
Moocat
Forum Contributor
Posts: 143
Joined: Wed Oct 12, 2005 9:28 am
Location: USA

Post 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?
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post 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.
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Post 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.
User avatar
Moocat
Forum Contributor
Posts: 143
Joined: Wed Oct 12, 2005 9:28 am
Location: USA

Post 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)
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Post 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.
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Post by alvinphp »

And this topic would be much better in Theory and Design.
User avatar
R4000
Forum Contributor
Posts: 168
Joined: Wed Mar 08, 2006 12:50 pm
Location: Cambridge, United Kingdom

Post 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
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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.
User avatar
Moocat
Forum Contributor
Posts: 143
Joined: Wed Oct 12, 2005 9:28 am
Location: USA

Post 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).
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Post 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.
User avatar
Moocat
Forum Contributor
Posts: 143
Joined: Wed Oct 12, 2005 9:28 am
Location: USA

Post 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.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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.
Post Reply