9

I am working on a use case diagram of a fully automated system. An external system will trigger just one use case of this system. Most of the other use cases are scheduled tasks and invoked by the timer. I have a use case that is invoked by the timer and it includes and extends two other use cases.

enter image description here

When I write the use case discriptions, who will be the actor for UC-2 and UC-3. Can a use case exists without an actor? I have seen lot of use case diagrams which has included or extended use cases without directly conneced to an actor. Please clarify this. Thanks in advance.

EDIT: My system is connected with a DBMS. My system will analyse the database workload time to time and check whether any tuning can be done. That's all about my system. UC-1 is Analyse DBMS, UC-2 is Check Performance statistics and UC-3 is Tune the database. So timer is the one which invoke the use case. DBMS gets the benefit.Steps in Check Performance (UC-2) are repeated in another use case. That's why I put it as a separate use case. On the other hand Tune database(UC-3) will be performed only if there is a need for tuning after analyzing the database.

Deepan Cool
  • 476
  • 1
  • 6
  • 16

3 Answers3

9

Officially this is correct. An included use case is a mandatory part of the including use case and an extending use case will optionally extend some use case. As @Ister notes in the comment, the actor for the included/extending use cases will be that of the main use case.

But, and this from my experience, you best avoid the use of those include/extend relations. In most cases, people tend to use them for functional decomposition which is plain wrong. A use case shall show an added value for its actor, not how a piece of functionality is used somewhere. In most cases a structuring of added value is not present and you can well show each bubble as a stand-alone use case or integrate it into the main use case. I recommend reading Bittner/Spence to get into matters.

Edit1: I just realize the sentence

trigger just one use case of this system

This rather sounds like you mix use cases with activities. It's not a piece of functionality. A use case is added value. There is a scenario (set) for a use case which has a trigger. But saying "a use case is triggered" sounds just wrong. You trigger the activities of a use case (where it starts getting technical). Most techies have difficulties making the cut and abstract to use cases. One more reason to read Bittner/Spence.

Edit2: In your comment you are talking about technical use cases. I admit that I had intensive discussions about this in the past. But you need to differentiate between technic and business. Your business use cases are Analyse DBMS, Check Performance, and Tune database. As such they are no UCs for a Timer but for some institution that cares about performance. The only UC for Timer is Trigger task (or something like that). There is a cut. The Timer does not care about business. It will happily trigger the shutdown of the system in the same way. It does not become a business actor only for that fact that it is technically used to start some business relevant process.

And not to forget: read Bittner/Spence. For me this book was an eye opener since I also had no idea about the intention of use cases.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • Since it is a fully automated system, if I avoid such include/extend relationships, I will end up with just one use case for the whole system. In that case I can't show lot of features of the system. I will end up with just one use case description with hundreds of steps and one massive activity diagram. How to overcome this scenario? – Deepan Cool Nov 11 '16 at 08:14
  • It's unlikely that there is just one use case. What you mean is that you have one large system (technically speaking). Try getting concrete and I might help with finding use cases. – qwerty_so Nov 11 '16 at 09:01
  • 1
    It seems that the UC-1 is some sort of steering activity while further UC-s are those actual functionalities of your system. In such case you just don't model what you've called UC-1 as this brings no actual system value. Besides that the answer by @ThomasKilian is precise and while there are some cases when you might build a decomposition by UCs inclusion/extension (even specification mentions that) it's far better to do that on activity/interaction level. If you decide to have a extending/included UC your triggering actor would be the same as the one from initial UC. – Ister Nov 11 '16 at 09:46
  • @ThomasKilian - My system is connected with a DBMS. My system will analyse the database workload time to time and check whether any tuning can be done. That's all about my system. UC-1 is Analyse DBMS, UC-2 is Check Performance statistics and UC-3 is Tune the database. So timer is the one which invoke the use case. DBMS gets the benefit. Is my use case diagram wrong? Please correct me. – Deepan Cool Nov 11 '16 at 10:21
  • Steps in Check Performance (UC-2) are repeated in another use case. That's why I put it as a separate use case. On the other hand Tune database(UC-3) will be performed only if there is a need for tuning after analyzing the database. – Deepan Cool Nov 11 '16 at 10:24
  • Would you mind to edit your question with that? Answering in comments is bad habit. Thanks! – qwerty_so Nov 11 '16 at 10:39
  • See my extended answer :-) – qwerty_so Nov 11 '16 at 10:56
  • @ThomasKilian - can you kindly tell me how to draw the use case for this scenario. Maybe with an example image. – Deepan Cool Nov 11 '16 at 10:59
  • You can use your drawing with the above substitutions, but you need to replace `Timer` by the business actor! N.B. reading Bittner/Spence took me a few weeks and I had an idea of what they said. But to get a good understanding it took another whole year at least. Further I can recommend to look at ICONIX for a light weight process to model systems. – qwerty_so Nov 11 '16 at 11:01
3

It is likely that UC2 and UC3 are not really use cases but in fact steps/actions within the UC1. A good way to check to see whether you have real use cases is to ask your self if there is any actor (human, system or time etc.) that would have that use case as a complete goal. In other words would any actor initiate this use case. In addition to this - Occasionally you may have a use case that has no actor initiating. This should occur only in the case that there are multiple other use cases (i.e. at least 2)that will either include or extend that use case. In this case the use case is there for the purpose of facilitating reuse in your model and simplifying the model - in particular when you write your use case narrative. Don't go out of your way to create include and extend relationships always double check - if no actor is using the use case you are including or extending and no other use case is using it then you absolutely don't need it.

Claudine Allen
  • 41
  • 3
-1

Use case is always a scenario executed by actor(s). In your situation primary actor is the system under discussion.

Technically you can introduce a timer as an actor who executes first UC-1 step, but better KISS. Just add a line before UC-1 steps via common convention:
Trigger: timer according to [Link to requirements about timer schedule].
If you have to write something beyond this line (for example timer checks conditions before triggering UC-1) then timer must become an actor.

Overall your use cases structure looks very valid for me, just don't forget to connect UC-1 to some higher goal anyhow. And please remove extends/includes as already mentioned.

Vlad
  • 497
  • 1
  • 3
  • 8