OK, so I have this homework question whereby we are given a rather complex system description and need to create several UML diagrams that describe the system being described.

I'm having an issue with designing the Use-Case diagram for it. Here is a very simplified description of the system:

The system being described is one that simulates jobs being performed by a multi processor machine. The simulation system is comprised of several components including:

  • Manager
  • Simulator
  • Scheduler
  • Parser
  • etc.

A user opens the simulation system by defining a configuration file (including job descriptions) into the manager, and hitting "run". When the simulation finishes, a statistics file is generated (and can be presented to the user)

The problem I have with the Use-Case diagram is what do I put as the Actors? As far as I'm aware, an Actor should be a human user, an external piece of hardware, or an external piece of software.

Going with this logic, the use case for the above system is overly simple, it's just one Actor labeled "user" which interacts with one action which will be named "simulation".

But I feel as if maybe I'm supposed to put all the components of the system as actors.

Anyone have any ideas? Thank you!


4 Answers 4


Since this is a homework assignment, the best thing that you can do is ask your instructor for input. The person grading you has expectations, just like in the workplace your coworkers, managers, and customers have expectations. The expectations need to be defined by the person receiving the work.

That said, I can provide my take on how to structure a use case diagram for this particular situation.

The first thing that I would do is to identify the external-facing operations that your simulator system exposes. The text of your question identifies a few - load a configuration file, run the simulation, view statistics. Are there others? Can you pause simulations? Or adjust configuration in the middle of a simulation? Or export the statistics to various formats? Anything else that your system exposes to a user or outside system should be given a use case "bubble".

Next, I would define relationships between the use cases. The three relationships that appear on a use case diagram are extends, includes, and inherits. The extend relationship allows one use case to continue beyond the base use case. If Use Case B extends Use Case A, then all of the steps in Use Case A are completed prior to executing Use Case B. The includes relationship captures dependencies and allows behavior from one use case to be included in another. If Use Case B includes Use Case A, then the operation of Use Case A is available as part of Use Case B but does not state where during the execution of Use Case B it is used or if it is required or not. Finally, inheritance allows for a use case that inherits some of the operations of a different use case but changes or adds additional steps.

Third, I'd identify all of the actors on the use case. These would be human users or external systems that interact with the system under design. It may be wise to consider roles. Humans of different roles may have different access to functions.

Finally, I'd identify relationships between actors. One actor may be a superset of another actor, and this can be indicated on the diagram, making it cleaner and easier to read.

Scott Ambler has a good article on the use of use case diagrams and an article on reuse in use case diagrams. I find much of his work helpful when considering modeling and documenting software systems.

After all of that, I would have to recommend once again going to the person who will be using your use case diagram - in this case, the instructor grading you - to find out exactly what they need from you. In UML Distilled, Martin Fowler almost discourages the use of Use Case Diagrams in favor of other tabular or textual representations of use cases. Diagrams don't have as much value as other more detailed descriptions. Use case diagrams aren't things that you tend to see or use in industry, but you should be aware of their existence and how to read and create them should you be asked to do so.


Actors interact with use cases. So your user actor interacts with different tasks they can perform with the simulator (configure, run, generate report, export data, etc.).

The use case diagram should show how other actors (if they exist) interact with the use cases the user actor interacts with.


First, identify the subject for which you want to describe use cases. From your description, I assume you need to draw use cases for the simulation system as a whole (and not for each of the components 'manager', 'simulator' etc.). In that case, the user is the only actor.

A use case must yield a result that is of value to the actor. So 'Create configuration' would not be a good use case. It seems to me that the only valuable result is the statistics file. In my view, there is only one use case, "Perform simulation", which covers all steps, including creating the configuration, running the simulation and viewing the statistics.

To summarize, I think you are completely right: one actor, one use case.


An actor does not have to be a human user, it can also be a system itself. In your case, the system actually running the simulations can be considered an actor itself because it will also interact with use cases ('the system' will run a simulation)

  • So, If I understand, instead of creating actors for different components, I can create an Actor named "System" which will call and interact with the different actions? It seems almost overkill, since all the system's operations are done internally (one class calls a method of another class for example)
    – user475680
    Nov 16, 2015 at 16:30
  • You are talking actors and use cases, not classes. User would have use cases such as 'define job configuration file', 'submit job to be executed', 'view job result', System would have use cases such as 'execute job'
    – JDT
    Nov 16, 2015 at 16:34
  • It's true that an actor can be a system, it's not the system under design. A use case model of a system is supposed to show the system as a black box and the functions exposed at its edges. If you show the system as a use case, you turn the use case model into a white box of the system.
    – Thomas Owens
    Nov 16, 2015 at 17:21
  • The system under design here is the system that users interact with to schedule jobs and get output. What I refer to as "the system" is the multiprocessor machine running the simulations, which acts as an actor here as you are not designing said machine, only working with it.
    – JDT
    Nov 16, 2015 at 18:10

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.