Use Case

 

Find and Outline Actors and Use Cases Detail Use Cases and Scenarios Use-Case Model Find and Outline Requirements Detail Requirements Use-Case Model Requirements

Back to top

Main Description  

Explanation A use-case model is a model of how different types of users interact with the system to solve a problem.  As such, it describes the goals of the users, the interactions between the users and the system, and the required behavior of the system in satisfying these goals. A use-case model consists of a number of model elements.  The most important model elements are: use cases, actors and the relationships between them. A use-case diagram is used to graphically depict a subset of the model to simplify communications.  There will typically be several use-case diagrams associated with a given model, each showing a subset of the model elements relevant for a particular purpose.  The same model element may be shown on several use-case diagrams, but each instance must be consistent.  If tools are used to maintain the use-case model, this consistency constraint is automated so that any changes to the model element (changing the name for example) will be automatically reflected on every use-case diagram that shows that element. The use-case model may contain packages that are used to structure the model to simplify analysis, communications, navigation, development, maintenance and planning. Much of the use-case model is in fact textual, with the text captured in the Use-Case Specifications that are associated with each use-case model element. These specifications describe the flow of events of the use case. The use-case model serves as a unifying thread throughout system development. It is used as the primary specification of the functional requirements for the system, as the basis for analysis and design, as an input to iteration planning, as the basis of defining test cases and as the basis for user documentation   Basic model elements The use-case model contains, as a minimum, the following basic model elements. Actor A model element representing each actor. Properties include the actors name and brief description. See Concept: Actor for more information. Use Case A model element representing each use case. Properties include the use case name and use case specification. See Artifact: Use Case and Concept: Use Case for more information. Associations Associations are used to describe the relationships between actors and the use cases they participate in. This relationship is commonly known as a “communicates-association”. Advanced model elements The use-case model may also contain the following advanced model elements. Subject A model element that represents the boundary of the system of interest.   Use-Case Package A model element used to structure the use case model to simplify analysis, communications, navigation, and planning.  If there are many use cases or actors, you can use use-case packages to further structure the use-case model in much the same manner you use folders or directories to structure the information on your hard-disk. You can partition a use-case model into use-case packages for several reasons, including: To reflect the order, configuration, or delivery units in the finished system thus supporting iteration planning. To support parallel development by dividing the problem into bite-sized pieces. To simplify communication with different stakeholders by creating packages for containing use cases and actors relevant to a particular stakeholder. Generalizations A relationship between actors to support re-use of common properties. Dependencies A number of dependency types between use cases are defined in UML. In particular, <<extend>> and <<include>>. <<extend>> is used to include optional behavior from an extending use case in an extended use case. <<include>> is used to include common behavior from an included use case into a base use case in order to support re-use of common behavior. The latter is the most widely used dependency and is useful for: Factoring out behavior from the base use case that is not necessary for the understanding of the primary purpose of the use case to simplify communications. Factoring out behavior that is in common for two or more use cases to maximize re-use, simplify maintenance and ensure consistency. Example Use-Case Diagram Figure 1 shows a use-case diagram from an Automated Teller Machine (ATM) use-case model.   Figure 1: ATM Use-Case Diagram This diagram shows the subject (atm:ATM), four actors (Bank Customer, Bank, Cahier and Maintenance Person), five use cases (Withdraw Cash, Transfer Funds, Deposit Funds, Refill Machine and Validate User), three <<includes>> dependencies, and the associations between the performing actors and the use cases. The use cases Withdraw Cash, Deposit Funds, and Transfer Funds all need to include how the customer is identified to the system. This behavior can be extracted to a new inclusion use case called Validate User, which the three base use cases <<include>>. The base use cases are independent of the method used for identification, and it is therefore encapsulated in the inclusion use case. From the perspective of the base use cases, it does not matter whether the method for identification is to read a magnetic bank card, or perform a retinal scan. They only depend on the result of Validate Customer. Note that Figure 1 is only a partial view of the use-case model. The complete use-case model also includes descriptions of each actor, descriptions of each use case, and use-case specifications for each use case.  For a more complete example of this use case model see Example: Evolution of the Use-Case Model.