I am currently developing a use case diagram for an army generation system in a game I'm developing. I have a process 'GenerateArmy' that requires a combination of troops and a supply limit that are retrieved from some other processes. Is there anyway to express this in the diagram to give it some more context? I can't find such examples online so I assume i'm doing something wrong here...

Army Generation System Use Case Diagram

3 Answers 3


I fully agree with Thomas' excellent answer. I'd nevertheless like to add some more information in regard of your intent.

A use-case diagram is meant to show what the outside world can expect from a system, and not how the system works internally:

  • Generate enemy army could indeed be a goal of value for the MatchCreator, and qualify for a use-case.
  • In a use-case diagram there is no sequencing and the only links allowed between two use-cases are inclusion or extension.
  • Get troop combination, get supply limit and generate army are not use cases, but a functional decomposition of the activity required to perform the use-case.
  • I can't see what's included in Get troup combination but it might probably be far too detailed for a use-case.

So it is possible that you are looking for something else:

  • To document details about use-case requirements, you may consider some kind of narrative that describes the use case, or even in a use-case slice, if you go for Use Case 2.0 approach.
  • To document a flow of activity you may better consider an activity diagram. THis also applies if you get objects from various sources and you must explain how this will be synchronised for achieving the intended behavior.
  • If it's less about the sequencing and decomposition of activities, but more about interactions, and especially if you already think of parameters, you're maybe even one level of detail further: you may consider a sequence diagram to document the interactions between components/objects.
  • Yeah I guess I can see how I'm just decomposing the Generate Enemy Army function. I just thought those leaf nodes should be included because they are neccessary for the Generate Enemy Army Use case to operate and finish. i.sstatic.net/FDKqy.png I'm having trouble distinguishing when I'm displaying functional decomposition as opposed to whatever it is I'm supposed to be expressing with the leaf nodes Edit: I should have mentioend that those 3 leaf nodes were supposed to have <<include>> if that makes any difference Commented Jul 4, 2020 at 15:44
  • 1
    @SebastianKing UML itself is neutral about what a UC should be. It just says that it's a set of behaviors offered byt the system in interaction with the actors. However, many authors have developped a value/goal based approach to UC to avoid micro-modelling. In this view, an include UC is meant to address a more detailed goal. But there should be value for the UC independently of the context. If there is not independent value, there are big chances that you're going into functional decomposition, and all authors agree that this should be avoided because other models are more appropriate.
    – Christophe
    Commented Jul 4, 2020 at 16:45
  • @SebastianKing The diagram should give the big picture: Generate Army UC and maybe the other high-level UC. UC could be documented as "essential use-case", in which you'd mention 3 actor intents: decide a troop combination, set limits, and generate the army. This helps to cover user oriented interaction needs, without already freezing the flow or the UI. You keep total freedom (e.g. implement the whole UC within one windows using widgets for each intent and a button to lauch generation; or implement a mobile version addressing sequentially each intent before confirming and ending the UC).
    – Christophe
    Commented Jul 4, 2020 at 17:01
  • No comment about the wrong arrows in use?
    – user188153
    Commented Jul 12, 2020 at 20:13
  • @qwerty_so I think this is part of what I meant to say in my second bullet ;-) I didn’t address the arrow on the association between actor and UC, as this seemed a minor issue compared to the other issues.
    – Christophe
    Commented Jul 12, 2020 at 20:19

You don't express that information in a Use Case diagram.

Martin Fowler has a good take on the UML Use Case diagram:

Use cases appear in the UML in the form of use case diagrams, but these diagrams are of little value - the key value of use cases lies in the text which is not standardized in UML. So when you do use cases put your energy into the text.

That doesn't mean that Use Case diagrams aren't valuable. They can provide a high-level overview of the use cases and their relationships.

In addition to the Use Case diagram, consider a tabular method for capturing use cases. There are a number of different formats that can be used - searching for "use case format" turn up a lot of options.

  • Hey, thanks for your answer. What does he mean by "text which is not standardized in UML / Put your energy into the text"? Like a description of the use case? I will definitely take a look at the other formats. Commented Jul 4, 2020 at 13:12
  • @SebastianKing He means the textual or tabular formats for use cases. Alistair Cockburn goes into great detail in Writing Effective Use Cases, but there are others. I believe that Martin Fowler also has a description of textual/tabular use cases out there somewhere, too. These textual and tabular formats are not part of UML, so you'll have to look to other sources to define them.
    – Thomas Owens
    Commented Jul 4, 2020 at 14:08
  • 1
    @SebastianKing Indeed,Cockburn is an excellent source. There's also Bittner & Spence. The only problem with these, is that they tend to attach a predefined flow to a use-case, whereas other forms of use cases such as Constantine&Lockwood's "essential use cases", or the more Jacobson's more modern "Use-Case 2.0" provide more agile & modern approaches, that do not foce you to a big up-front detailed analysis
    – Christophe
    Commented Jul 4, 2020 at 14:30
  • Ah okay gotcha, Thanks for the resources guys. I'll take a look! Commented Jul 4, 2020 at 14:40

As outlined elsewhere, use case diagrams are too high level for what you're trying to describe. To go back to basics, actors in use case diagrams represent types of users, organisations or some kind of external system.

Perhaps what you're really looking for is a sequence diagram. This would illustrate the sequence of events that you describe.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.