The objective of this lesson is to define the purpose and function of use case view.
Use Case View
The Use Case View is a fundamental component of software design and architecture, playing a crucial role in capturing the functional requirements of a system. This perspective is primarily concerned with describing the interactions between external actors and the system, elucidating how the system delivers value to its users. Below, the purpose and function of the Use Case View are defined and expounded upon:
Purpose of the Use Case View:
Requirement Capture:
Functionality Specification: The Use Case View is instrumental in specifying and documenting the functional requirements of the system.
Stakeholder Communication: It facilitates clear and effective communication with stakeholders, ensuring that their needs and expectations are accurately understood and incorporated.
User-Centric Design:
Focus on User Interactions: By concentrating on how external entities interact with the system, the Use Case View ensures a user-centric approach to design.
Identification of User Goals: It aids in identifying and clarifying the goals and objectives that users aim to achieve through their interactions with the system.
Function of the Use Case View:
Use Case Modeling:
Use Case Diagrams: The Use Case View employs use case diagrams to visually represent the interactions between actors (users or other systems) and the use cases they are involved in.
Scenarios and Flows: It outlines various scenarios, including the main, alternative, and exception flows, detailing step-by-step how each interaction unfolds.
System Boundary Definition:
Delineating System Limits: The Use Case View plays a crucial role in defining the boundaries of the system, clearly demarcating what falls within the system’s scope and what lies outside of it.
External Actor Identification: It identifies the external actors that interact with the system, providing insight into the various entities the system needs to cater to.
Functional Requirement Validation:
Ensuring Comprehensive Coverage: By modeling all significant user interactions, the Use Case View helps ensure that all essential functional requirements are identified and addressed.
Basis for Verification: It provides a solid foundation for subsequent validation and verification activities, ensuring that the system’s implementation aligns with its intended functionality.
Guidance for Other Views:
Informing Design and Implementation: The insights gleaned from the Use Case View inform and guide the design and implementation decisions in other views of the system, ensuring consistency and coherence across the entire architecture.
Facilitating Traceability: It establishes clear traceability from requirements to implementation, aiding in impact analysis and change management.
In sum, the Use Case View is integral to the object modeling and software design process, providing a user-focused perspective that ensures the system’s functionality aligns with the needs and goals of its users. Through detailed use case modeling, clear system boundary definition, and the validation of functional requirements, it lays a solid foundation for a robust and user-centric software solution. This view not only facilitates effective communication with stakeholders but also provides critical guidance for other architectural views, ensuring a comprehensive and cohesive design approach.
Purpose and Function of the Use Case View
Define the purpose and function of the use case view.
The use case view contains only one model, the use case model. As the name implies, it focuses on the ways users will use the system.
The name itself came from Ivar Jacobson's work on the object-oriented software engineering (OOSE)/Objectory methods.
Use case view
Focus on user need
The goal of the model is to identify the functionality required by users before trying to model a solution. The model uses a diagram, a narrative description of the diagram, and scenarios to model these requirements.
Identify Features of the System
The model identifies the external users of the system and the key features the system must provide to be considered successful. You might compare this perspective to the RFP process for selecting a vendor product. You would identify the features that you are looking for and measure the vendor's offerings against these features. Furthermore, once a choice has been made, the requirements function as the testing criteria for implementations and enhancements. Each of the leading methodologies recognized the need to model users' needs apart from the software mechanisms used to support them. Hence, it was not a difficult decision to include the use case model in the UML.
The use case diagram itself is very simple, too simple for some folks. One particular challenge with the model is its similarity to functional models.
We willl cover the use case model in depth in the next module and help you discern the key differences between these techniques. In the next lesson, the logical view, the most inclusive of the four views, will be discussed.
Use Cases
Use cases are used during requirements elicitation and analysis to represent the functionality of the system. Use cases focus on the behavior of the system from an external point of view.
A use case describes a function provided by the system that yields a visible result for an actor. An actor describes any entity that interacts with the system (i.e., a user, another system, the system's physical environment).
The identification of actors and use cases results in the definition of the boundary of the system, that is, in differentiating the tasks accomplished by the system and the tasks accomplished by its environment.
The actors are outside the boundary of the system, whereas the use cases are inside the boundary of the system. For example, Figure 2-6 depicts a use case diagram for a simple watch.
The WatchUser actor may either consult the time on their watch (with the ReadTime use case) or set the time (with the SetTime use case). However, only the WatchRepairPerson actor can change the battery of the watch (with the ChangeBattery use case).
Figure 2-6 A UML use case diagram describing the functionality of a simple watch.
The WatchUser actor may either consult the time on her watch (with the ReadTime use case) or set the time (with the SetTime use case). However, only the WatchRepairPerson actor can change the battery of the watch (with the ChangeBattery use case). Actors are represented with stick figures, use cases with ovals, and the boundary of the system with a box enclosing the use cases.
