Software Modeling
Week 2: Use Case Diagram
Instructor: Nguyen Thi Minh Tuyen
Content
1. Introduction
2. Components
3. Use case description
4. Best practices
Introduction
- A use case is a foundational concept in many object-oriented development methods.
- Use case diagrams represent the desires of the customer/stakeholders.
- Essential for detailed design.
- Use case diagrams are utilized throughout the analysis and design process.
- They help answer:
- What is being described? (the system)
- Who interacts with the system? (actors)
- What can the actors do? (use cases)
Example: Student Administration
- System: Student Administration
- Actors:
- Professor
- Use Cases:
- Query student data
- Issue certificate
- Announce exam
Use Case
- Describes expected functionalities from the system under development.
- Provides tangible benefits to one or more interacting actors.
- Stems from requirements gathered from the customer.
- A set of all use cases describes the functionality the system will provide.
Actor [1]
- Actors interact with the system by:
- Initiating the use cases.
- Being utilized by the use cases, providing functionalities necessary for their execution.
- Actors represent the roles users assume.
- Users can adopt multiple roles simultaneously.
- Actors are not part of the system; they are external.
Types of Actors
1. Human: e.g., Student, Professor
2. Non-human: e.g., E-Mail Server
- Primary: Benefits directly from use case execution.
- Secondary: Does not benefit directly.
- Active: Initiates the use case.
- Passive: Provides functionality for use case execution.
Relationship between Use Case and Actor
- Actors are connected to use cases by straight lines (association): an actor communicates with the system and uses a
function.
- Each actor must interact with at least one use case.
- Associations are always binary: a specific use case and an actor.
Relationship between Use Cases
1. Included Use Case: Integrated behavior into a base use case.
2. Extending Use Case: May be integrated into a base use case's behavior but is optional.
Common Errors to Avoid
1. Do not model workflows/processes with use case diagrams.
2. Actors are not part of the system, so they are placed outside boundaries.
3. Issue information use cases may require actors like Assistant or Professor for execution.
Component Symbols
1. System Boundary: Separates the system and its users.
2. Use Case: Functional unit of the system.
3. Actor: Role of the system user.
Example: Information System of the Student Office of a University
- The student office processes key administrative activities.
- Students can register, enroll, and withdraw.
- Certificates are issued to students by the student office.
- Lecturers send grading information to the office.
- Differentiation between employees handling student data and other tasks.