1. Introduction to UML (slides adapted from Michael Mateas)
UC Santa Cruz
CMPS 171 – Game Design Studio II
11 January 2011

2. Lab Update Alienware machines still need OS update
Working on getting update on when task will be performed
Have not received list of /usernames for Mac teams
As a result, am assuming these teams do not yet have access to the Max boxes in the lab

3. Microsoft Visit
Will have visitors from Microsoft Game Studios in class next Tuesday
Jason Major (Halo series game engine programmer)
Recruiters (MGS and Microsoft Entertainment)
Presentation open to all
Also, recruiting focused presentation at 4pm, E2 180 (Simularium)
More detail on recruiting, internships, permanent positions
Bring a resume
Schwag

4. Upcoming deadlines Short, in-class quiz Thursday (on today’s material)
Geared for 25 minutes in length
Short answer questions
Class notes, Wikipedia article
Tuesday (Jan. 11): release plan due
A big effort
Sprint 1 begins this day
Thursday (Jan. 13): sprint 1 plan due
Ideally want to have this done by the 11th, so your team doesn’t lose two days during the Sprint
Remember to set up one scrum meeting per week so Ken Hullett (TA) can also attend (only about half of the teams have done this so far)
Friday (Jan. 14): scrum board up, updated burndown charts
Many teams already have scrum boards up – good job!!
Friday (Jan. 14): team status reporting
Due by midnight
Report on team activities this week
Be sure to use new team status reporting template

5. Introduction to UML
The Unified Modeling Language (UML) consists of a collection of diagrams for describing a software design
Creating a UML description forces a team to develop a software design before diving into the nitty-gritty of writing code

6. Class diagrams A class diagram describes your object oriented design
Classes are drawn as boxes.
Members are listed inside the box. Fields appear in the top sub-box, methods in the bottom sub-box
Access indicated by + (public), - (private), # (protected) and ~ (package)
Classes are connected together with lines indicating class relationships

7. Generalization links
Generalization links indicate subclass relationships
Parent/child relationships
An open arrow points to the parent

8. Aggregation links
Aggregation indicates that instances of one class will contain instances of another class
In aggregation, the lifespan of the enclosed instances is independent of the lifespan of the enclosing instance
Container classes (lists, hashtables, etc.) will always have aggregation links to what they contain, though many classes will contain member instances of other classes

9. Composition links
Composition links indicate that one class contains instances of another class, but the contained class is created and destroyed with the instance class
The contained instances will be destroyed when the containing instance is destroyed
In C++, this is the difference between a member variable of type MyClass* and MyClass

10. Realization
Realization links relates a class that implements (realizes) a behavior specified by another model element, to the model element that specifies this behavior
In Java, classes that implement an interface realize the interface
In C++, classes that are children of a pure abstract class realize behavior specified by the pure abstract class

11. Dependency links
Dependency links represent arbitrary relationship between classes, where a change made to one class may require a change to another class
The arrow points from the dependent towards the independent class
You’ll want to use link labels for dependency links
On the class diagram, only indicate important dependency relationships (ones that help communicate in the team)

12. Demo of StarUML

13. Creating class diagrams for games
When creating a game architecture, you’ll want to make sure you’ve covered at least the following game elements in your class (structure) diagram:
Input handling
Representation of game levels, if present
Player class
Enemy classes, including container holding active enemies
Physical object classes, including a container to hold them
Collision detection
Classes for drawing player, enemies and other game objects
Classes for handling audio
Classes for game interface (menu system) and HUD

14. Discovering your object taxonomy
The golden rule: Nouns are classes, verbs are methods
Once you’ve done a preliminary analysis of the nouns (objects) in your architecture, organize them into an inheritance hierarchy
Inheritance organizes objects that share functionality
Once you have a preliminary understanding of your inheritance hierarchy, then work on composition and aggregation (which objects contain which other objects)
Many of you will be building your code within an engine or library, typically subclassing library classes to create game-specific functionality. So you’ll be including some engine (library) classes in your structure diagram

15. Study questions What does UML stand for? What is a class diagram?
How is a class represented in a class diagram?
What information goes in the three parts of a class box?
How do you represent parent/child relationships?
What are the two ways to represent containment/aggregation relationships?
How is realization represented?
How is visibility represented?
Given a description of a class, draw its representation using UML
Given a description of two classes, and a relationship between them, draw the classes and their relationship