What is Unified Modeling Language (UML)?
UML, short for Unified Modeling Language, is a standardized modeling language consisting of an integrated set of diagrams, developed to help system and software developers for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems. The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.
Use Case Basics:
A use case describes how a user uses a system to accomplish a particular goal. A use case diagram consists of the system, the related use cases and actors and relates these to each other to visualize: what is being described? (system), who is using the system? (actors) and what do the actors want to achieve? (use cases), thus, use cases help ensure that the correct system is developed by capturing the requirements from the user’s point of view.
What is a Use Case Diagram in UML?
A use case is a list of actions or event steps typically defining the interactions between a role of an actor and a system to achieve a goal. A use case is a useful technique for identifying, clarifying, and organizing system requirements. A use case is made up of a set of possible sequences of interactions between systems and users that defines the features to be implemented and the resolution of any errors that may be encountered.
While a use case itself might drill into a lot of detail (such as, flow of events and scenarios) about every possibility, a use-case diagram can help provide a higher-level view of the system, providing the simplified and graphical representation of what the system must actually do.
A use case (or set of use cases) has these characteristics:
- Organizes functional requirements
- Models the goals of system/actor (user) interactions
- Describes one main flow of events (main scenarios) and possibly other exceptional flows (alternatives), also called paths or user scenarios
Actors are usually individuals involved with the system defined according to their roles. The actor can be a human or other external system.
A use case describes how actors uses a system to accomplish a particular goal. Use cases are typically initiated by a user to fulfill goals describing the activities and variants involved in attaining the goal.
The relationships between and among the actors and the use cases.
The system boundary defines the system of interest in relation to the world around it.
How to Draw a Use Case Diagram?
A Use Case model can be developed by following the steps below.
- Identify the Actors (role of users) of the system.
- For each category of users, identify all roles played by the users relevant to the system.
- Identify what are the users required the system to be performed to achieve these goals.
- Create use cases for every goal.
- Structure the use cases.
- Prioritize, review, estimate and validate the users.
Note that: to make use case approach more “Agile”, do not detail all use cases, but prioritize them in your product backlog, you should refine the use case in different level of details according to the development phase with just-in-time and just-enough manner.
What is “Extend” in Use Case:
Extend is used when a use case adds steps to another first class use case. For example, imagine “Withdraw Cash” is a use case of an ATM machine. “Assess Fee” would extend Withdraw Cash and describe the conditional “extension point” that is instantiated when the ATM user doesn’t bank at the ATM’s owning institution. Notice that the basic “Withdraw Cash” use case stands on its own, without the extension. The extending use case is dependent on the base use case; it literally extends the behavior described by the base use case. The base use case should be a fully functional use case in its own right (‘includes included of course) without the extending use case’s additional functionality. Extending use cases can be used in several situations:
- The base use case represents the “must have” functionality of a project while the extending use case represents optional (should/could/want) behavior. This is where the term optional is relevant – optional whether to build/deliver rather than optional whether it sometimes runs as part of the base use case sequence.
- In phase 1 you can deliver the base use case which meets the requirements at that point, and phase 2 will add additional functionality described by the extending use case. This can contain sequences that are always or sometimes performed after phase 2 is delivered (again contrary to popular misconception).
- It can be used to extract out sub sequences of the base use case, especially when they represent ‘exceptional’ complex behavior with its own alternative flows.
One important aspect to consider is that the extending use case can ‘insert’ behavior in several places in the base use case’s flow, not just in a single place as an included use case does. For this reason it is highly unlikely that an extending use case will be suitable to extend more than one base use case. As to dependency, the extending use case is dependent on the base use case and is again a one way dependency, i.e. the base use case doesn’t need any reference to the extending use case in the sequence. That doesn’t mean you can’t demonstrate the extension points or add a x-ref to the extending use case elsewhere in the template; but the base use case must be able to work without the extending use case.