I'm starting to develop a board game in C++ using OpenGL.
Before starting, I want to draw the UML diagram, as shown bellow.
The game has:
A board that contains a desktop, a footer and the points of both players to show.
Pieces to put on the board
Followers (soldiers)
Mouse events
A set of rules that the players must obay in order to play
Something like The Risk, of Monopoly, etc
I'm not an expert in UML, so by looking at what I've written so far, do you think the UML (arrows and relations) is accurate with the description?
What would you change, and why?
Hard to tell without knowing the game (use case). Generally you seem to over-use aggregation. Also I miss the basic properties/methods of the single classes. Those are general observations.
Some detail observations:
The model does not differentiate between the game and the technology.
What for it this Object? It seems rather pointless. You'd better be off designing the game logic first: what are those Pieces and what can they do? Think of a better name (my dictionary suggests Token, Meeple, PlayingPiece). Things are only what their name is!
What are the Rules? I don't see any rule class at all.
Create a 2nd diagram/layer where you can concentrate on technology in a later stage.
Related
For my homework, I have to write functional requirement of a game called downfall (see Wikipedia).
We have to make this game, but with not two sides but n (any number of) sides.
In an example solution (another game), the teacher writes the functional requirements, then writes what use case they belong to.
I have created a use case diagram in which I have the player as an actor, and ChooseDial, RotateDial and EndTurn as use cases:
What I dont understand are the following:
Is the number of players functional requirement?
Is the table having two sides a functional requirement?
Is the goal of the game (getting coins from top to bottom) a functional requirement?
Is a rule like coins must reach bottom in order a functional requirement?
If they are, what use case could they belong to? Is my use case diagram wrong?
I have no idea where to put these functional requirements, because I feel like they arent part of any of my use cases.
About requirements
First, let's handle the requirement question:
A functional requirement tells something about what a software shall do. Everything related to goal, the gameplay or the rules of the game, is a functional requirement.
A non functional requirement tells something about how the software shall be, for example how accurate, how performant, how easy to use, how easy to maintain. Your narrative shows no such requirements.
About use-cases
Use case driven software development methods start with the high-level user's goals that are captured in use-cases. Personally, I see only one such goal:
Very rare usage: a multiplicity on the actor side of the use case. This says that 2 or more instances of players are involved in an instance of the use case. Of course, this makes sense only for the game as a whole, not for individual actions (like you have in your diagram).
In your diagram, you have shown 3 use cases:
is EndTurn an independent goal that the user may freely decide to chose ? No ! It's what always follows a player action. So this is definitely not a use case.
you say that RotateDials extends ChooseDials. This means that a player could ChooseDials but not rorate it. Is this a valid scenario ?
if on the other hand you'd say that ChooseDials includes RotateDials, the latter would always happen. But then, wouldn't ChooseDial not be more than just choosing a dial ? Shouldn't it then be called PlayTurn ?
I could understand that for learning purpose, you'd want to decompose the Play game in more detailed use-cases. Typically, once the players try to reach their goal Play game, this might include sub-goals of Play turn. As long as it is goal-oriented, and not too detailed, this is ok. But do avoid simple functional decomposition (it doesn't help for being more user-driven, and use-cases are not functions ). And, above all, do not misuse a use-case diagram for trying to show a sequence of activities.
Requirement traceability
The use cases do not capture the full requirements. It captures the most enssential thing: the purpose of the system and the user goals.
When writing down the requirements, it's then useful to get guided by the use-cases and their narrative, and to trace-back every use-case specific requirement.
But of course, there are some general requirements as well. These are not specific to a particular use-case. Some are even common to all use case. Mark these as general requirements (e.g. use case *).
Requirements management (RM) can be tricky indeed. A requirement like The board must have two sides seems to be more involved in the design, rather than the use case. In such cases you could relate that to the boundary rather than a single use case. That will indicate it's some "global" requirement (similar to a non-functional requirement). Usually in a project you start with a more or less strange mix of requirements mixed in user stories. The business analyst (BA) has to comb that information and come up with decent use cases (synthesize the added values). The system architect (with the BA) will then go through requirements and use cases to come up with a (business) class model.
There are tons of books and procedures describing RM. Lots of seminars too. I think if you grasp the condensed idea above you're ready to start. It's a marathon to start...
We want a chair class for a game.
How can we create this class so that it can work in another game too?
And by considering the solid principles.
Imagine for example, that we have 2 games: one is a poker game, another is a grand theft auto like game. In the poker game the class should have an id, playersited() : player , state : full , empty , reserved. I can think of these properties right now. But in the second game, the chair doesn't necessary need an id or a playersited() function. So how can I design this class that can be reused in another games?
You are looking for a generic game object that you could reuse in different games, but which might have different properties and different functions depending on the game.
Simple UML answer
If you're only looking at it from the UML perspective only, this design issue is simple: draw a class GameObject, put in it the properties and operations that you want to be common. Then in the model of your different games, just create a a specialisation using inheritance: PokerObject and GrandCloneObject in which you'd add the game specific properties and operations.
But this apparent simplicity would hide a lot of difficult points when you start to design links with other classes (reusable or not), and even more when you start to look at their interactions.
Limitations of such a generic design
In addition you want a SOLID design. The LSP will then reduce the reusability by forcing you to keep the reusable interaction between objects to rely only on common part.
If only 10% of the design is then really reusable in the end, and 90% is game specific, you'll gain no advantage and just make the code more complex by splitting classes artificially. Here I'd joint #kigiri's comment: "JUST DON'T"
A better approach
But if you're looking for is something really reusable at a higher scale, there is a solution if you look not at a Chair, "Weapon", "Item", but at a higher level of abstraction.
And here, I can only recommend you to read Mike McShaffry's Game Coding Complete book, that will introduce you a very powerful architectural pattern called the Entity Component System.
The Idea is to abandon deeply nested class hierarchies wiht very specific classes, but prefer a very flat model with:
Entities: these are the main objects used in the game, whatever the game is
Components: these are owned by the Entities, and represent either properties that an entity can have (e.g. LivePoints, Force, ...), or behaviors that the Entity shall have (e.g. renderFixedObject, soundWhenClicked, etc..).
This design allows to develop highly reusable objects allowing to add game specific components on the top of reusable entities and components.
I need to create use case diagrams for a small game. I have created what I think is a correct, high-level use case diagram. I now want to create sub-diagrams. Take "Play Game" for example, there are many actions involved in playing the game, like moving or jumping, so would "Play Game" become the system (box) in the sub-diagram? I am not quite sure the proper way to expand use cases is.
You would describe the scenarios behind the UCs starting with the sunny day scenario. This can either be described textual in the Cockburn way or by using activity diagrams using appropriately connected actions. If your modeling tool support this (hopefully) you would place those activities inside the UCs. Following would be to create collaborations and a class design in parallel.
I'd recommend to look into ICONIX since they have a quite neat design process model which did put me on rails many years ago.
Re. your question title: you do not create a "low level UC" since that's not the intention. UCs are about added value and that can not be sub-divided. Here I'd recommend Bittner/Spence as an excellent read.
As the title says I have problems creating a simple use case diagram for the game Hangman. The rules are simple, the computer generates a word, it gives you the length and the first and last letter, and you have 9 tries to guess the word. So far I've done this :Hangman Diagram
The problem is that this is my first diagram, and I think I didn't I put everything in order and the player is associated with more actions. Every suggestion will be greatly appreciated. Thank you in advance.
You have it very detailed.
Also there seam to be misunderstanding of Actors definition. Quote:
Actors. An actor is a person, organization, or external system that
plays a role in one or more interactions with your system.
Your Computer actor is in fact internal system therefore should not be modeled as an actor.
Also for the use cases
A use case describes a sequence of actions that provide something of
measurable value to an actor.
The point here is about providing measurable value.
I suggest you to try to change it when you think more about these UML principles.
EDIT:
Nice UML example for game is here: http://xnagamedevelopment.blogspot.cz/2009/03/use-case-diagram.html
Interesting discussion on game industry vs uml is here: http://www.gamedev.net/topic/192120-uml-for-games/
That discussion might not help with your assignment, though.
I am currently taking a course that gives an introduction to project planning. It is mostly about how to draw UML diagrams (blegh), but also has a few other topics.
One part in particular keeps bugging me. In the course they describe a method for going from a set of requirements to an initial class diagram, but everything about the method gives me this feeling that it is most definitely not the way to go. Let me first give an example before proceeding.
Let's consider a system that manages a greenhouse company. The company has multiple greenhouses, and every employee is assigned to his/her own greenhouse. A greenhouse has a location and a type of plant being grown in there. An employee has a name and phone number.
Here's what according to the course's method the class diagram would look like:
To me this looks like a database layout adapted for code. When I go about designing a program, I try to identify major abstractions. Like all the code that interacts with the database or the code that is responsible for the GUI are all different parts of the system. That would be what I consider to be an initial class diagram.
I simply can not imagine that this is a common way to start designing the architecture of a project. The classes look ugly, since if you take a slightly larger example the classes will be flooded with responsibilities. To me they look like data objects that have functionality to them they shouldn't have. It does not give me a clue on how to continue from here and get a general architecture going. Everything about it seems obsolete.
All I want to know if there's someone out there that can tell me if this is a common way to get a first class diagram on paper for reasons I am overlooking.
I would say it's reasonable to start with a logical model that's free of implementation constraints. That logical model is not necessarily concerned with physical implementation details (e.g. whether or not to use a database, what type of database, OS / UI choice, etc.) and thus represents just "real" business domain objects and processes. The similarity to a potential database implementation shouldn't be surprising for the simple example.
By understanding your business domain (through the logical model you've started to construct), you will be better placed to subsequently identify, for example, which architectural patterns are appropriate, what screens you need to build, and database elements to design. Possibly, there will be another part of the course that will aid you in this stage.
In practice, you will often know that you're intending to implement, say, a web-based application using MVC with a back-end database, and may look to model the implementation classes in parallel with your business items. For your course to use a method that emphasises the distinction between logical and physical stages doesn't sound unreasonable.
When I go about designing a program, I try to identify major
abstractions
Same principle in UML as well. You represent abstractions and their relationships and due to existing Visual Tools you can do a presentation of a system to stakeholders or even generate automatically stubs from your design.