Introduction to UML (slides adapted from Michael Mateas) UC Santa Cruz CMPS 171 – Game Design Studio II www.soe.ucsc.edu/classes/cmps171/Winter11 ejw@cs.ucsc.edu 11 January 2011

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

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

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

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

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

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

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

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

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

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)

Demo of StarUML

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

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

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