2

In system design using use case diagrams are all use cases initiated/done by the external user: e.g. add line item, print receipt

Or can use cases be entirely internal/automatic: e.g. calculate running total, or even present running total

In regards to the second example would a cashier system have a use case of present running total? Is automatic presenting of information on a screen a use case?

5

A use Case should always have an Actor that starts it off. That Actor need not be a person, it could be another system outside the boundary of the one being modelled.

Something that just happens automatically within the system being modelled isn't really a Use Case. However, if you don't mind being a bit controversial, then many people think it's OK to treat "time" as an Actor. See Is TIME an actor in a use case?

0

In practice

In practice, a use case represents a set of behaviors of a system under consideration and the relation with the actors involved in that context. So in principle it's external actors, humans or systems.

Internal interactions that occur within the system are in general modelled with other representations, such as a sequence diagram, a communication diagram or an activity diagram.

In theory

The UML standard is more flexible in its specifications:

When a use case applies to a subject, it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for actors or other stakeholders of the subject.

The words in italic are refined with the following explanations:

A subject of a use case could be a system or any other element that may have behavior, such as a component or class.

An actor models a type of role played by an entity that interacts with the subjects of its associated use cases (e.g., by exchanging signals and data). Actors may represent roles played by human users, external hardware, or other systems.

Note that the word "may" is to be understood in the sense of RFC 2119 (i.e. a possibility, not an exhaustive limitation).

So in theory you coud very well have a use case diagram with the subject being a component of your system, and the actor being another component that interacts with it. There are forever very few situations where this representation is preferred to the other type of behavioral diagrams mentioned above. It could make sense for example:

  • if you'd represent a game engine, that interacts both with external players and internal components acting as players, and interacting with the game engine in the same way as a human player.
  • a multi-agent system composed of relatively independent interacting "agent" components, if you wanted to give an overview of the intent of the agents interacting within the system, before digging in more precise interactions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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