The diagram is a UML class diagram, using the notations for classes, associations (with multiplicities), and generalization. Although the notation is using perfectly valid UML, it appears to be in one of the less complete notations that Martin Fowler describes as UML as Notes or UML as Sketch. It's using the symbology of the language correctly, but omitting details to make it easier to read. Such a notation is useful to communicate between people, but wouldn't support something like forward engineering from models to code.
In the diagram that you presented, each of the boxes is a class. There is a
Game class with public methods
Frame class with public method
score(), and a
Roll class with a private member variable
pins. There's also a
TenthFrame class that inherits from
Some details about the members of classes have been omitted from the diagram. For example, there is an association relationship between
Game knows of 10 instances of
Frame. The use of the association relationship implies that
Game not only knows about the interface of
Frame (a dependency on
Frame), but also maintains 10 instances as part of the object. Although you could show this explicitly by adding a member variable to
Game that shows an array of 10
Frame objects, this is simply duplicating what the association relationship is already showing you. There is a similar relationship between
Roll - a
Frame has at least 1 and no more than 2
Looking through the slides that you linked to, you are right that the final solution doesn't appear to use anything other than a
Game class (at least that I can see looking through the code in the slide deck). When following the principles of Agile Modeling, there would be a Single Source of Information, meaning those models would have likely been thrown away after the code was written and they have outlived their usefulness.
What it looks like happened is that the authors used UML (since it's a familiar and standardized notation) to walk through the problem and explain how it was decomposed. However, as they were writing code, they decided that they didn't need all of the classes to realize the simplest implementation. However, the act of modeling improved their understanding of the problem and the rules associated with it, but may not have driven the implementation.