Boundary implications on Use Case Diagram

Hi,

i’m currently studying Software Development and have a question to ask regarding a Use Case Diagram I have to create (As part of analysis work to lead on to design at a later date)

With the problem domain (Listed below), i’m assuming that my Boundary would be the “Information Storage System”, as pretty much this is being specified as the main requirement.

If that is the case, am I then right for assuming that only 5 Actors would be displayed using the system? (“Manager”, “Cashier”, "End of day ", "Start of Day " and "End of month ")

…And as a result, that “Customer” and “Supplier” would not be present as they don’t directly interact with the system?

If anyone could help me with my assumptions to get me on my way, i’d be very grateful.

Many thanks and regards,

Francis.

----- Domain Desc ------

An information storage system is required for Paul

Hi Francis,

There are a few articles on Use Case Modelling at the Visual Paradigm Community website:

http://www.visual-paradigm.org/article.php

I hope this helps.

Martyn

Hi Francis,
I know, it is very late for you to get this answer .
But , as per answer of your question is concerned , You are right. Your System Boundary mainly decides about the primary actor. As you said that in your req specs , there is no mention of any behaviour of Customer or suppiler with respect to system , They will not part of your actor list.

Not sure if this helps but here we go anyway:

An actor represents a set of roles that a user or system plays within an entity (system or subsystem). Actors can be human or other systems that represent things outside the entity. The actor “communicates” with the entity by sending a series of messages backwards and forwards.

Looking at that you realise that End of Month etc are not actors, they are more pre conditions of your use case (start at end of month)

Within actors you have:

Primary Actor has user goals fulfilled thought using services of the process that is defined in the scope.

Supporting Actor provides a service (e.g. Information) to the process that is in scope.

Offstage Actor has an interest in the behavior of the use case but is not primary or supporting. E.g. Tax office

If your boundary is “Information Storage System”, you could call it POS (Point of Sales System) than your actors are Customers, employees, cashier, manager (cashier and manager could be generalised in employee) and suppliers would be actors.

These entities interact with the system, the suppliers could be seen as system actor, if you want to take B2B into account.

Well that is what I think.

:lol: