UML Domain Model : How to distinguish attributes and classes?

Question

I am currently making a domain model of a combat game, and I have difficulties determining whether certain elements should be a class of their own or attributes of some class. For example, I have used a category list to determine the following ideas/objects: Fighter, Level, Weapon, Armor, Attributes, Skills, Arena, Game Mode, Game Log, Opponent.

For example, I can't tell whether Level, Weapon, Armor, Attributes, Skills should be simply stated as attributes of a fighter or should they be delimited as their own object. I can't tell either if an opponent should be a distinct class since it is ultimately a fighter object with an 'attack/defend' association to another fighter.

How does one determine what would be the correct choice for each element in a category list? Can these be subjective?

FYI, I am using Craig Larman's "Applying UML and Patterns" 3rd Edition as an information source.

Answer 1

To clarify your question for a moment -- each Class in your domain model will have a set of Attributes. The question I think you are asking is whether the Type of each of these Attributes should be a Class themselves, or some other data structure (eg a struct, enum, primitive etc.)

If this is correct, then the answer comes down to design choices that stem from your analysis; there is no one 'correct way' -- this is the art of software design. There are however a few key things you might want to look for in making your decision:

1. Evidence of behavioural requirements. Does the object that an Attribute refers to need to encapsulate behaviour itself? Clearly it's impossible for certain data structures to encapsulate behaviour, which may lead you to make choices towards those that can (eg a class vs a struct).
2. Complexity of data structure. Does the object that the Attribute refers to need to encapsulate complex data structures ? (eg multiple, possibly hierarchical, data of various primitives and/or complex types) Or is it simple? (eg a single integer value). Again, complexity in structure will limit how you can represent it.
3. What are the non-functional requirements of your system? (eg performance requirements?) NFRs like performance, scalability and security may constrain your design choices, so that you might choose to represent complex types in simple ways or eliminate behavioural needs etc..
4. Does the design choice help you or hinder you? There's no point in representing something in an overly complex way that hinders your work or the system.
5. Audience. This is possibly the most important point -- who are you putting the domain model together for, and what are you trying to communicate to them?

So, for example, you could represent "Weapon" as an attribute typed as a class or using a simple type. Does "Weapon" have behaviour of its own? Does it contain multiple complex data? Is there a NFR that means it can only really be treated as an enum? And so on.