Use Case Diagram
A use case analysis is the primary form for gathering usage requirements for a new software program or task to be completed. A Use Case is a description of the systems behavior from a users viewpoint. This diagram is a valuable aid during analysis developing Use Cases helps us to understand requirements. The diagram is deliberately simple to understand. This enables both developers (analysts, designers, coders, tests) and the target users to work with the diagram.
Goals of Use Case
A use case represents how a system interacts with its environment by illustrating the activities that are performed by the users and the system’s responses.
They are a means of expressing user requirements and extensively used in the analysis phase. The primary goals of use cases are:
- designing a system from the user’s perspective
- communicating system behavior in the user’s terms
- specifying all externally visible behaviors
When to Write Use Cases
Capturing use cases is one of the primary tasks of at the initial stage of your project. Most of your use cases will be generated during that phase of the project, but you will uncover more as you proceed.
They are are an essential tool in requirements capture and in planning and controlling an iterative project. In other words, use cases can be used for the entire software development lifecycle.
here I list when to write them for perform requirement capturing and also the subsequent development activities:
- To capture functional requirements of a system.
- To communicate with end users and domain experts.
- To design test cases for validating system functionality.
- To provide traceability from requirements into actual classes and operations.
- To drive the development process.
- To plan iterations and releases
Use Case Diagram - model elements
Basic model elements
The use-case diagram contains the following 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 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".
System Boundary
A model element that represents the boundary of the system of interest.
Advanced model elements
Advanced model elements
The use-case model may also contain the following advanced model elements.
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.
Relationships of Use Case model elements
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 Use Case
<<extend>> is used to include optional behavior from an extending use case in an extended use case.
- 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.
Include 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.
- Factoring out behavior that is in common for two or more use cases to maximize re-use, simplify maintenance and ensure consistency.
Business Use Case vs System Use Case
Business Use-Case
A Business Use-Case is a way in which a customer or some other interested party can make use of the business to get the result they want whether it’s to buy an item, to get a new driving licence, to pay an invoice, or whatever. An important point is that a single execution of a Business Use-Case should encompass all the activities necessary to do what the customer (or other actor) wants, and also any activities that the business needs to do before the process is complete from its point of view.
System Use-Case
In contrast, a System Use-Case is a way in which a user of a computer system can make use of the system to get the result they want. This will typically be something we can readily imagine as being done in a single sitting on a single PC or other device such as an ATM or a mobile/cell phone, usually with a single UI, or a small number of closely-related screens such as a wizard, and taking maybe between a couple of minutes and a half-hour at most.
Note that: Most modeling tools will distinguish a business use case from an ordinary use case by placing a line through the use case shape; alternatively give the business use case a stereotype name Business