I am creating use cases for my web application and I was wondering if a representation of the DB should be listed as an actor. For example a user can check his profile and edit it (assuming that he is logged in). The two use cases would be:
- User can view his profile
- User can edit his profile
Would the use cases then be for example:
Actor: User, DB
Use case: View profile
Or can I leave out the DB as an actor? Unfortunately I haven't found any consistent way of drawing the use cases.
I would say if the DB is internal to your app (i.e. it is used solely by this app and the external world doesn't interact with it directly in anyway, only via your app), you shouldn't represent it as a separate actor.
If the DB is shared and used directly by external users/systems, it is probably better to represent it as a separate actor.
When You define Your use cases, You need to think about behavior of Your actors instead of structure.
Database is static reflection of actor. If we use anthropomorphizing, calling database an actor is like calling photography or memories of beloved one as real human.
According to my point of view I think Use Cases are drawn largely to depict the Interaction between System and External Environment.
Hence, DB is an internal entity comparing to the system, so it's not worthwhile to draw DB as an actor unless it's an external entity. At the same time, it should be mentioned that though it's an external body, accessing it directly can raise security issues, right!
Therefore, unless you have a very special reason for doing it like that, it's not wise to depict DB as an actor in Use Cases. Of course you can do that in Sequence Diagrams: there's no such issue, since it shows the interaction between actors and objects.
