1. Use Case Modelling
1.1. Use Case Diagram
1.1.1. Overview
1.1.1.1. part of the Unified Modeling Language (UML)
1.1.1.2. Purpose: Analyze/record the functional requirements of a system.
1.1.1.3. Use case: a function that the system performs. Usually in response to a trigger from an actor
1.1.1.4. Actor: An external entity that interacts with a system - usually a user role but can also be an external system
1.1.2. Examples
1.1.2.1. A part of the project control system
1.1.2.2. Hotel Room Reservation
1.1.3. Use Case Symbols
1.1.3.1. Actor (Role, not Individual)
1.1.3.1.1. Involved with the functioning of the system at some basic level
1.1.3.1.2. Represented by stick figures
1.1.3.2. Use Case
1.1.3.2.1. represents a single system function
1.1.3.2.2. Represented as an ellipse
1.1.3.3. System Boundary
1.1.3.3.1. includes all the relevant use cases.
1.1.3.3.2. A boundary is the dividing line between the system and its environment
1.1.3.3.3. Use cases are within the boundary
1.1.3.3.4. Actors are outside of the boundary
1.1.3.3.5. Represented as a box
1.1.3.3.6. presented as use case subject in the UML standard.
1.1.3.4. Connection
1.1.3.4.1. is an association between an actor and a use case
1.1.3.4.2. does not indicate data flow
1.1.3.4.3. Actors are connected to use cases with lines
1.1.3.4.4. Use cases are connected to each other with arrows
1.2. Relationships in Use Case Diagram
1.2.1. <<include>> Relationship
1.2.1.1. An association between 2 use cases where one uses the functionality contained in the other
1.2.1.2. In a system, certain actions may be repeated. Such a general-purpose action can be written as a separate use case and then be used by / contained in other use cases
1.2.1.3. example
1.2.1.4. example 2
1.2.1.5. <<include>> can be used to decompose a use case into smaller use cases. The source use case is incomplete without the included use cases.
1.2.1.6. <<include>> can be used to reuse a common use case.
1.2.2. <<extend>> Relationship
1.2.2.1. An extend relationship extends a use case by adding new behaviors or actions
1.2.2.2. The extending use case has all the actions in the original one, and some more
1.2.2.3. Specialized use case extends the general use case
1.2.2.4. example
1.2.2.5. example 2
1.2.3. Generalization Relationship
1.2.3.1. 2 usages
1.2.3.1.1. Between actors
1.2.3.1.2. Between use cases
1.2.3.2. Example 1
1.2.3.2.1. Order
1.3. More References
1.3.1. Use Case Diagram và 5 sai lầm thường gặp - Thinhnotes
2. Written Use Cases
2.1. Definition
2.1.1. Document containing detailed specifications for a use case
2.1.2. Contents can be written as simple text or in a specified format
2.1.3. Step-by-step description of what must occur in a successful use case
2.1.4. Each ellipse in the use case diagram should have a corresponding written use case.
2.2. Template
2.2.1. A template for written use cases
2.3. Guidelines
2.3.1. ID & Name – descriptive name, matches name in use case diagram
2.3.2. Primary Actor – usually a user role
2.3.3. Stakeholders – any group or individual with an interest in the function of the use case
2.3.4. Trigger – an event or action that initiates the use case
2.3.5. Pre-conditions – conditions that must be satisfied in order to execute the use case
2.3.6. Post-conditions – outputs that can be expected if the service succeeds
2.3.7. Normal Flow – description of sequence of interactions between actor and system during the use case execution
2.3.8. Alternative flows – scenarios which are different from normal flow but still deliver the same business outcome
2.3.9. Exceptions – potential conditions that prevent a use case from succeeding
2.4. Example: Make Reservation
2.4.1. Make Reservation
3. Activity Diagrams
3.1. Roles in process modelling
3.1.1. Show the conditional logic for the sequence of system activities needed to accomplish a business process.
3.1.2. Show the conditional logic for the sequence of system activities needed to accomplish a business process.
3.1.3. Show the conditional logic for the sequence of system activities needed to accomplish a business process.
3.1.4. Depict the flow of control from activity to activity.
3.1.5. Depict the flow of control from activity to activity.
3.1.6. Help in use case analysis to understand what actions need to take place.
3.1.7. Help in identifying extensions in a use case.
3.1.8. Model work flow and business processes.
3.1.9. Model work flow and business processes.
3.2. Example
3.2.1. Order pizza
3.3. Notations for Activity Diagrams
3.3.1. Activity: a behavior that an object carries out while in a particular state
3.3.2. Branch: a diamond symbol containing a condition whose results provide transitions to different paths of activities
3.3.3. Merge: a circular symbol where different paths converge
3.3.4. Fork: the beginning of parallel activities
3.3.5. Join: the end of parallel activities
3.3.6. Swimlanes: columns representing different organizational units of the system
3.4. Examp;es with 4 Swimlanes
3.4.1. Purchase
3.5. From Use Case to Activity Diagram
3.5.1. A flowchart or a UML activity diagram is a useful way to visualize a (complex) use case
3.5.2. These diagrams show the decision points and conditions that cause a branch from the normal flow into an alternative flow