A use case diagram visually represents the interactions between external actors and a system to accomplish goals. It identifies actors, use cases that represent the goals, and the relationships between actors and use cases. A use case is a list of steps defining interactions between an actor and the system. Actors can be people, organizations, other systems, or software and represent roles that interact with the system. The use case diagram also models relationships between elements and can include optional system boundary boxes to separate internal and external components.
A use case diagram visually represents the interactions between external actors and a system to accomplish goals. It identifies actors, use cases that represent the goals, and the relationships between actors and use cases. A use case is a list of steps defining interactions between an actor and the system. Actors can be people, organizations, other systems, or software and represent roles that interact with the system. The use case diagram also models relationships between elements and can include optional system boundary boxes to separate internal and external components.
A use case diagram visually represents the interactions between external actors and a system to accomplish goals. It identifies actors, use cases that represent the goals, and the relationships between actors and use cases. A use case is a list of steps defining interactions between an actor and the system. Actors can be people, organizations, other systems, or software and represent roles that interact with the system. The use case diagram also models relationships between elements and can include optional system boundary boxes to separate internal and external components.
A use case diagram visually represents the interactions between external actors and a system to accomplish goals. It identifies actors, use cases that represent the goals, and the relationships between actors and use cases. A use case is a list of steps defining interactions between an actor and the system. Actors can be people, organizations, other systems, or software and represent roles that interact with the system. The use case diagram also models relationships between elements and can include optional system boundary boxes to separate internal and external components.
Download as DOCX, PDF, TXT or read online from Scribd
Download as docx, pdf, or txt
You are on page 1of 2
3.
USE CASE DIAGRAM
AIM: Steps to draw Use Case Diagram using Rational Rose. REQUIREMENTS: It requires hardware interfaces such as Pentium(R) 4 CPU 226 GHz, 128 MB RAM, keyboard, mouse and a Monitor. It requires Software interfaces such as CD ROM Driver, Windows OS and Rational Rose. THEORY: Use Case approach uses a combination of text and pictures in order to improve the understanding of requirements. The use cases describe what of a system and not how. The only give functional view of the system. Use Cases: Use cases are structured outline or templates for description of user requirements, modelled in a structured language like English. Use Case Diagram: Use cases are graphical representation that may be decomposed into further levels of abstraction. Use Case Scenarios: Use case scenarios are unstructured description of user requirements. Guidelines For 1. Use Cases: A use case is a list of steps, typically defining interactions between a role (known in Unified Modelling Language (UML) as an "actor") and a system, to achieve a goal. The actor can be a human or an external system. The following provides an outline of a process for creating use cases: Identify all the different users of the system. Create a use case profile for each category of users, including all the roles the users play that are relevant to the system. Create a use case for each goal, following the use case template. Steps in higher level use cases may be treated as goals for lower-level sub-use cases. Structure the use cases. Avoid over structuring as this can make the use cases harder to follow. Review and validate with users. 2. Actors: A use case defines the interactions between external actors and the system under consideration to accomplish a goal. Actors must be able to make decisions, but need not be human. An actor might be a person, a company or organization, a computer program, or a computer system hardware, software, or both. Actors are always stakeholders, but not all stakeholders are actors, since they never interact directly with the system, even though they have the right to care how the system behaves. 3. Relationships: In UML, a relationship is a connection between model elements. A UML relationship is a type of model element that adds semantics to a model by defining the structure and behaviour between the model elements. 4. System Boundary Boxes: A system boundary is a rectangle that you can draw in a use-case diagram to separate the use cases that are internal to a system from the actors that are external to the system. A system boundary is an optional visual aid in the diagram; it does not add semantic value to the model. CONCLUSION: A use case diagram for a real project is made.