While the 8th Light craftsman reviewed Darek’s apprenticeship on Friday (…HUGE props to both he and Chris on becoming 8th Light’s newest craftsman!), I offered him a distraction by tutoring me in some of the intricacies of the Unified Modeling Language (UML) and helping me think through some coupling problems in my tic-tac-toe code.

I’d struggled with what exactly UML arrows mean in terms of how a class “uses” or “knows” about another class, so here’s a quick rundown on three of the most common arrows you’ll see.

Dashed Line with a Normal Ending

We’ll start out with one line and a normal arrow ending. In the image above we see how the Game class “uses” the UserInterface. The dashed line in the image above depicts a dependency in which the Game class knows about the UI class and uses it, but it doesn’t own the UI— it doesn’t create the UI. (See my earlier post on Dependency Injection for details on the UI’s creation).

A modeling language that preceded UML was Booch-94 by Grady Booch, and he actually referred to the dashed-arrow relationship as a “using” relationship, which I think is a bit clearer. Our Game uses the UI, but the UI class doesn’t know about or “use” the Game class in any way.

Lines with Different Endings

The image above shows how my Game class creates and then “owns” the PlayerFactory (…which is technically a violation of the Dependency Inversion Principle), and then how the PlayerFactory “owns” and creates a HumanPlayer or ComputerPlayer, that then inherit some behavior from the Player superclass. The Game also knows about Players, but not about a specific type of player.

The solid arrows with the normal endings represent how the Game class is responsible for and uses the PlayerFactory class. The arrow between the Game and PlayerFactory that ends on the PlayerFactory signifies that the PlayerFactory doesn’t know anything about the Game class— it’s a uni-directional relationship.

Similarly, the dashed arrow between Game and Player ends on the Player class because the Game uses and knows about the Player, but the Player knows nothing about the Game. It’s a dashed line because Game is not responsible for creating the Players, it delegated that responsibility to the PlayerFactory

Finally, the arrow with an open triangle ending between the HumanPlayer, ComputerPlayer and Player class signifies that Human and Computer inherit something from the Player class. In this case it’s the behavior of serving up the information of what move they decided to make. The arrow terminates on the Player superclass because again it’s a uni-directional relationship. The HumanPlayer and ComputerPlayer need to know some information from the Player class, but the Player class doesn’t need to know anything about it’s subclasses.

There’s a lot of information on UML diagrams out there and it seemed liked several authors interchanged some key terms that made it difficult know which end of the arrow was up. Here’s three resources that helped me decipher it (Darek being the fourth, of course):

UML Distilled by Martin Fowler Object Mentor article on UML Class Diagrams UML Basic Notations on Tutorial Point