Use case non assigned to actor - UML

1
votes

I'm creating some use cases for a project and i got confused about some UML concept about actors and use cases.

An actor is someone or another system that my software will have some boundry.

Starting after this, i got two questions:

A - Can i have an actor to represent a part of my own system that will work with no contact to user? e.g. An AI that will calculate something.

B - Since that the question above got a no with answer, my second question is: Can i have a Use case not assigned to some actor?

Well, and if I get two "false's" how must i do this thing?

Thank you

1
umlactoruse-case
would you please provide some example about the B!? and about the A you would mention about the daemon/background/AI guys in another diagrams, use case diagram usually is used for representing business related and requirements. - user2511414
It is hard to understand your real problem from your explanation. But as a genaral guide...You can not have a use case that is not assigned to an actor. - Hippias Minor
If you really can not find actors or use cases you find seem not relatic or artificial then maybe(?)use case approach not fit well in your situation.Then simply use other techniques such asfeature list to list your requirements - Hippias Minor
You shouldn't edit your question to give it a different purpose. The point of SO is that others with the same problem may find the answer here. Minor followups can be asked in comments, but new questions should be posted as such. - Uffe
Rolled back - please post your second question as a new, separate question. - Shog9

1 Answers

2
votes

You can do whatever you want, of course. But generally speaking, both A and B are bad ideas.

Each use case should represent a clearly defined interaction between the system and something which is external to the system - an actor (which can be a person, another system, or anything else that makes sense in your particular case). The whole philosophy behind use cases is to think in terms of these well-defined interactions, usually initiated by the actor and not by the system, which is why the classic use case example is an automated teller machine.

It is a mistake to assume that use cases are always the best way to structure your analysis. They're not. Sometimes they're good, sometimes they're plain wrong. They're just one tool in your analysis toolbox.

What you might look at doing is conducting the analysis in two phases: first at the system level, then break the system down into subsystems and do a separate analysis for each of them. At this level, subsystem 1 can be an actor in subsystem 2's use cases and vice versa.