Use Case Model
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.
Use Case
A model element representing each use case. Properties include the use case name and use case specification. See Use Case artifact 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, Cashier 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.
Reviews:
Post a Comment