This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am doing a uni project, one of my team members suggested putting the database as an actor on the use case diagram. I didn't think it was right, we were never really taught where the data source comes into play (we used Larman) though so would her idea be right?
Hey, welcome to JavaRanch. You'll be disappointed to know that the first person who got to your question doesn't actually have any formal training in this area, so don't trust a word I say. An actor is a component that matters. In the oft-used ATM examples the people are actors and the receipt printer is and, I believe, the database that keeps track of how much money the bank thinks you have is. That's because the database that keeps track of how much money people have at the bank is complex, large, and mission critical. How will you write a use case for the database failing to update without a database actor? On the other hand, if your writing a program that quizes people with Java questions from a database on their own computer, I say let them read the error messages and figure it out themselves (more of that software by programmers for programmers stuff). In general, the database is a complete and separate component that is easily capable of failure, so it is probably a good idea to add it as an actor for the simple reason that it can do no harm. Once again I warn -- I really have no clue what I'm talking about and have never so much as drawn a use case diagram in my life.
Hi there!... You know it depends on what you want to do with that Database... I mean if the DB are going to be the only one used forever and ever in your product, it can participate has a component of design (or a design constrain), and you don�t have to model it (well at leas not in the UC Diagram). BUT if your software are going to support to use one DB or Another (like using Access in a SingleMode and Oracle or DB2 in a Corporation Network) its better to think on it has an actor who plays a ROLE with your system. You know, Actors define the boundary of your system, for them to define the Strongest interfaces (I mean the ones that can changes most) of the system. But remember the complexity of having an actor everywhere on your model. I personaly would leave it has a Design Constrain! (Not in te UC diagram) Only Remember UC define Hilevel requirements (They are not ssuposed to deal with design or components)
IMHO, there should not be any DB unless you really expect high level service from it. Find the shortest path in between two addresses. The DB would then have to locate the places (from the addresses), find the shortest path accroding to some criteria, etc ... Then you could envidage it as an element of your diagram... not otherwise ! I repeat : IMHO
My $0.02: If we were to use Alistair Cockburn's (in "Writing Effective Use Cases") loose definition of an actor ("something with behavior"), the database could be validly depicted as an actor in the use case diagram. Note that I said could (standard consultant's defense ). Cockburn also defines the internal actor as "either the system under discussion (SuD), a subsystem of the SuD, or an active component of the SuD." Now the database could certainly be seen as an active component of the SuD. But (you knew this was coming, right) you should consider the perspective or level of the use case. Is this a high-, mid-, or low-level diagram? IMO, you would only depict the database as an actor in a low-level, implementation perspective diagram where the nitty-gritty details need to be shown. Otherwise, the database is an implementation detail that you really should leave out of the diagram. I think it is rarely necessary, if at all, to go down to low-level details when creating use case diagrams. The most useful use-case diagrams are the high-level ones and mid-level ones. These normally show just the external actors that either benefit from the use case or assist in giving the benefit. Also, make sure you are not mixing perspectives and levels. You should try to keep the perspective and level consistent throughout the use case and the diagram. I.e., if this is a high-level use case, don't mix in low-level details. Bottom line: in all likelihood, you probably don't need to show the database as an actor. Junilu
Hi, While modeling a database as a actor only thing that one needs to keep in mind is whether the database is a part of the system under discussion , if thats the case then database need not be modeled as an actor. If the database is an external database, then it can be modeled as an actor. Regards, Anjana email@example.com