0
votes

I'm quite confused about what my actors should be in my use case diagrams.

For example, below is the use cases for a subsystem that deals with shipping orders for an online store. I don't understand what the actors should be for these. It is just the system doing these things behind the scenes. It appears to me that they are not triggered by some kind of external input.

What am I missing here?

enter image description here

1
These doesn't look like use cases, but would probably better be expressed as Actions in an Activity Diagram. - Geert Bellekens
Maybe 'Ship Order' is the use case and the rest are steps within the use case. Is 'Ship Order' triggered by an external input? If not, how does the system know it should do 'Ship Order' ? - www.admiraalit.nl
This is for a uni assignment. The lecturer gave us a list of 'subsystems' to draw use case diagrams for. 'Ship order' was one of the subsystems specified. I think the lecturer might not know what he's talking about to be honest. - somebloke
This doesn't answer my two questions. If you don't have the answers, I cannot help you. - www.admiraalit.nl
You should offer more context. It could be possible that each is instantiated by a different actor. It could also be that all are included by one of them that gets instantiated by a single or multiple actors. You need to offer more information on the domain it applies to. - SomeDutchGuy

1 Answers

0
votes

My thoughts on this:

  • "Ship order" as the subsystem name sounds confusing to me. It would probably be clearer to call it "Order shipping service" or something similar.
  • "Ship order" could be the main use case within this subsystem (as commented by www.admiraalit.nl). You may want to model the other activites as use cases as well and link them to your main use case using include relations. However, this makes sense only if you want to reuse them (e.g. include them in more than one use case) or if they can be invoked directly by an actor. For instance, "assign driver" or "create delivery schedule" might be called separately to change these things after the order has been handed over to delivery.
  • The actor triggering your use case(s) would either be an operator who decides that an order is ready for shipment or another subsystem if this happens automatically.