Can there be a precedent without an actor?

Question

I am working on a chart using a fully automated system. An external system causes only one use of this system. Most other use cases are scheduled tasks and are called by a timer. I have a use case that is called by a timer, and it includes and extends two other use cases.

When I write use cases, who will become an actor for UC-2 and UC-3. Can a precedent exist without an actor? I saw many use case diagrams that included or distributed use cases without connecting directly to the actor. Please clarify this. Thanks in advance.

EDIT: My system is connected to a DBMS. My system will analyze the database workload from time to time and check if it is possible to complete the configuration. It is all about my system. UC-1 analyzes the DBMS, UC-2 checks performance statistics, and UC-3 sets up the database. So a timer is one that triggers usage. DBMS gets an advantage. The steps in performance testing (UC-2) are repeated in another use case. That's why I put this as a separate use case. On the other hand, the Tune database (UC-3) will only be executed if it is necessary to configure it after analyzing the database.

Answer 1

Officially, this is correct. The included use case is a mandatory part of the inclusive use case, and extending the use period does not necessarily extend any use case. As @Ister points out in a comment, the actor for included / renewing use cases will act in the main use case.

But, and this is from my experience, you better avoid using such include / extend relationships. In most cases, people tend to use them for functional decomposition, which is wrong. A use case should show added value for its actor, and not as part of the functionality used somewhere. In most cases, there is no structuring of added value, and you can show each bubble as a separate use case or integrate it into the main use case. I recommend reading Bittner / Spence to get into things.

Edit1 : I just understand the sentence

launches only one use case for this system

It is more likely that you are mixing use cases with actions. This is not functionality. Application is value added. There is a scenario (set) for a use case that has a trigger. But to say that the “use case works” sounds simply wrong. You start the use case action (where it starts to get technical). Most technologists have difficulty reducing and abstracting the use of cases. Another reason to read Bittner / Spence.

Edit2 . In your comment, you talk about technical use cases. I admit that in the past I have intensively discussed this. But you need to distinguish between technology and business. Use cases for your business: Analyse DBMS , Check Performance and Tune database . Thus, they are not UC for Timer , but for some institution that cares about performance. The only UC for Timer is the Trigger task (or something like that). There is a cut. Timer does not care about business. Thus, it will successfully start the system. He does not become a business actor just for the fact that he is technically used to start a business process.

And don't forget: read Bittner / Spence. For me, this book was eye-opening, since I also had no idea about the intentions of use.

Answer 2

A use case is always a script executed by an actor (s). In your situation, the main subject is the system under discussion.

Technically, you can introduce a timer as an actor who performs the first step of UC-1, but better than KISS. Just add the line before the steps of UC-1 through the general convention:
Trigger: timer according to [Link to requirements about timer schedule].
If you need to write something behind this line (for example, the timer checks the conditions before starting UC-1), then the timer should become an actor.

In general, the structure of your applications looks very relevant for me, just do not forget to connect the UC-1 to some higher goal in any case. And please remove extends / includes, as already mentioned.

Answer 3

UC2 and UC3 are probably not actually used, but are actually steps / actions in UC1. A good way to check if you have any real use cases is to ask yourself if there is any actor (person, system or time, etc.) who will have this use case as a complete goal. In other words, any actor initiates this precedent. In addition to this - sometimes you may have a precedent that does not have an actor initiator. This should only happen if there are several other use cases (i.e. at least 2) that will include or extend this use case. In this case, a use case is used to facilitate reuse in your model and simplify the model - in particular, when you write your story about use. Do not go out of your way to create include and extend relationships, always double check - if none of the participants uses your use case that you include or distribute, and no other use case uses it, you absolutely do not need to.