Subtitles of the Movie

In this movie, we'll look at how to represent the basic elements of use cases using UML. Now when we're dealing with use cases we're dealing with the system, with the actors who use that system and with the goals that those actors have in interacting with the system and we call those goals use cases. To represent the system we draw a rectangle and we give it a name. In this case we'll just call it system because we're just looking at the concepts. Now in some use case diagrams you may find that the people who draw it leave off the rectangle but when you're starting off to identify the actors and to identify the different use cases it's certainly a good idea to draw the rectangle simply because it helps you visualize what's inside of scope and what's outside of scope. If there's a goal that the system can take care of it belongs inside the rectangle, if it's a goal the system can't take care then it's not a use case in dealing with this system. So using the rectangle helps you keep scope in mind. Next we need to show our actors, we'll call this one actor one and as you can see represent the actors with a stick figure and you use a stick figure whether your talking about a human actor or another system. If you like you can label it system and this is how you do that. So we have right now two actors, two stick figures and we have our system. Next we want to start thinking about what goals these actors have in using the system and those are our use cases. We represent use cases in an ellipsis so they look like that, put in use case one use case two and let's do one more, use case three. So these are different goals that our actors might have in using this system. Now these things don't exist in isolation, they have relationships to each other and we show these relationships by drawing a line to indicate association. So let's say that actor one has this particular goal, use case one in using the system. We show that actor one initiates that use case by drawing a line and we'll say actor one also initiates use case two and we'll say actor two initiates use case three. So that makes it clear that this actor is the primary actor whose goal is use case one. This actor is also the primary actor whose goal is use case two and so on. Now sometimes you might find that a use case brings into play another actor, that's necessary to complete the use case. For example a validate credit card use case would require a payment processor in order to be complete. So you can also indicate secondary actors, we'll call this one actor three and since we're talking about processors we'll say this one is system two and if use case one requires some participation from actor three before it can be complete we have another association, so we want to indicate that.