CODEWITHSUNDEEP
event-handlingumluse-case
deb
deb

Reputation: 425

UML Use-Case Diagram

I'm drawing a UML use-case diagram for the following scenario:

  1. External system provides an event - I think my actor here would be the event generated
  2. System ingests the event
  3. System enriches the event
  4. System correlates enriched event with some data existing in the system
  5. If system finds a hit notification is sent to human actor
  6. If not, event is discarded

So my 2 actors would be: the event generated by this external system and the user that receives the notification.

Now, I'm not certain on how to model the other items in my initial list of they should be modeled at all.

Should I have something like:

Should I model the discard event at all?

Thanks!

Upvotes: 1

Views: 793

Answers (2)

Ister
Ister

Reputation: 6318

Let's look at the definitions.

Actor

I will use a definition from UML Specification, section 18.1.3.1

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

It clearly states a close list of who/what can become an Actor. In your case, it is an External System that interacts with your system so it is your Actor. The other Actor is naturally User.

Use Case

Here I will support myself with the definition from Alistair Cockburn's "Writing Effective Use Cases" book (section 1.1).

A use case captures a contract between the stakeholders of a system about its behavior. The use case describes the system’s behavior under various conditions as it responds to a request from one of the stakeholders, called the primary actor. The primary actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and conditions surrounding the requests. The use case collects together those different scenarios.

In your case, it is apparent that once the External System (primary Actor) provides an event, the processing is then carried out by your system until either the User (secondary Actor) is notified or the event is discarded. It seems that there are no delays or further interactions required in order to accomplish this goal so it is clearly just one use case, Ingest event.

The processing ending by notifying the User will be your main path while the one where the event gets discarded will be either an alternative or even a negative path (depending on how you look at it).

If you consider the discard as an alternative path, you should model the multiplicity of the association to the User as 0..1 to show the User is not always notified. You do not have to do that if you account this as a negative path, as those are considered "failure paths" so not all tasks of the UC has to happen. I would be very careful though. Since you expect discarding to be something happening on a regular basis it seems to be an alternative path rather than a negative one.

Alternative approach

The assumption in my model is that you actively notify the User (e.g. send him a push, a mail or do some other action).

It might be possible though that you just create a notification and the User has to actively read it. In such case, User would not be an Actor of Ingest event at all. Instead, as a result of Ingest event you create a notification (not visible on UC diagram). In addition, User needs an additional use case to Read notifications, in which he is the primary (initiating) Actor.

Summary (TL;DR)

You only have one Use Case in your scenario: Ingest event.

Your Actors are: External System (primary) and User (secondary with multiplicity 0..1).

Upvotes: 4

qwerty_so
qwerty_so

Reputation: 36313

  • For your actor: Event is no actor. Event is an event. If you don't have a specific name call it External system.
  • Ingest event would be ok as UC.
  • I'd guess that enrichment goes with Ingest event. Same for discarding it. Both are activities inside the use case.
  • Correlation and sending to the user would be (UC---Actor) Inform User --- User.
  • Not informing the user would be a path inside the Inform User's activities.

Generally:

  • Use cases show added value the system under consideration delivers to one of its actors.
  • Use cases are no functions (those are hidden inside the UC's activities).
  • If a UC does not add value, it is no use case.

Upvotes: 2

Related Questions