O'Reilly logo

Programming Game AI by Example by Mat Buckland

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Appendix B
UML Class Diagrams
T
he Unified Modeling Language (UML) is a useful tool for object-
oriented analysis and design. One part of the UML, the class diagram,
is utilized frequently throughout this book because this type of diagram is
especially good at clearly and succinctly describing the static relationships
between objects.
Figure 1 shows the class diagram utilized in Chapter 7 to describe the
relationships between some of the objects used in one of the book’s
projects.
465
Figure 1. Example UML class diagram
If this is the first time you’ve seen a UML class diagram you’ll probably
find the figure perplexing, but by the time you’ve finished reading this
appendix it will make perfect sense (knock on wood J).
Class Names, Attributes, and Operations
First of all let’s start off with the name, attributes, and operations of a class.
Classes are represented by a rectangle divided into three compartments.
The name of the class is in bold at the top of the rectangle, attributes are
written beneath, and operations are listed in the bottom compartment. See
Figure 2.
For example, if one of the objects in a game is a racing car, it can be speci-
fied as shown in Figure 3.
Of course, a racing car object is likely to be much more complex than this,
but we only need to list the attributes and operations of immediate interest.
The class can easily be fleshed out more fully at a later stage if necessary.
(Quite often, I don’t show any attributes or operations at all and use class
diagrams simply to show the relationships between objects, as demon
-
strated by Figure 1.) Note that the operations of a class define its interface.
The type of an attribute can be shown listed after its name and separated
by a colon. The return value of an operation may also be shown in the same
way, as can the type of a parameter. See Figure 4.
466 | Appendix B
Class Names, Attributes, and Operations
Figure 2. The class/object rectangle
Figure 3. Example of attributes and operations
Throughout the book I rarely use the “name : type” format for parameters
as it often makes the diagrams too large to fit on the page comfortably.
Instead, I just list the type, or sometimes a descriptive name if the type can
be inferred from it.
Visibility of Attributes and Operations
Each class attribute and operation has a visibility associated with it. For
instance, an attribute may either be public, private, or protected. This prop-
erty is shown using the symbols + for public, - for private, and # for
protected. Figure 5 shows the RacingCar object with the visibility of its
attributes and operations listed.
As with the types, it’s not imperative that you list the visibilities when
drawing class diagrams; they only need to be shown if they are immedi
-
ately important to the part of the design you are modeling (or, as in my
case, describing).
When all the attributes, operations, types, visibilities, etc., are specified
it’s very easy to convert the class into code. For example, C++ code for the
RacingCar object looks like this:
class RacingCar
{
private:
vector m_vPosition;
vector m_vVelocity;
public:
void Steer(float amount){...}
UML Class Diagrams
| 467
Visibility of Attributes and Operations
Figure 4. Specifying the type
Figure 5

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required