A touch of class
Time to take a step back from programming…
I have asked my 2nd year students to provide a simple class diagram design for their project. As this is meant to be a design, the deadline for this is some time before the deadline for the actual game demo – to prevent folk from simply documenting what they implemented, and encourage them to consider what they will do ahead of time.
Class diagrams are only one of many diagram types used in software analysis and design – but is quite likely the most commonly and widely used diagram for object-oriented analysis and design, and a core part of the Unified Modelling Language, UML. This is very widely used and taught, and there are many software packages available for creating class and other UML diagrams.
Class diagrams can have a very close relationship to the actual code created in an object-oriented project such as a typical C++ application. Close enough that many tools will support the creation of basic class diagrams from finished code or the creation of class stubs from a design. As a popular and well established technique there are also many books and online resources. An easy place to start is the class diagram Wikipedia page.
From there, and a brief web search, you should be able to find any number of detailed tutorials and online resources. Free tools also abound – from the web-based ones life Gliffy to downloadable like ArgoUML.
It is well worth the extra time put into design before coding starts – it can help you iterate to a better solution much quicker, and with experience can significantly boost the development process. Some years ago when I was teaching a course on object-oriented analysis and design I read a letter by Damion Schubert in Game Developer on UML – from which I emailed some questions to Damion and to Jay Lee, a lead programmer who had been working with Damion. Both were kind enough to provide some long and very detailed answers. Just a couple of quotes to finish. A short quote from Jay to illustrate the value of working on design before code:
It was interesting to note that the people who had the least success in keeping up with their schedule and meeting their estimates were also ones that were the most resistant to adopting UML.
And from Damion, a quote highlighting the value of a diagram as a tool for supporting communication between a designer and those tasked with implementation:
…in the case of designers, the most important thing is that we talk the same language as the programmers. It is the lead programmer’s responsibility to find the best way to receive input from people like me. If my lead programmer didn’t have anything in place, I’d certainly point him towards UML. This is a necessary result of the programmers being the design team’s ‘hands’.
