Use-case Modeling

1. Use-case Modeling

2. Outline • Introduction • Use case model • Unified Modeling Language • Actor • Use cases • UC Description Properties • Relationships between Actors • Use Case Relationships Sharif Univ. of Tech.

3. Introduction • The main purpose of the Requirements discipline is to establish and maintain agreement with the customers and other stakeholders on what the system should do. • To this aim, the discipline produces some artifacts such as: Vision, Stakeholder requests, requirements management plan, supplementary specifications, Use-Case model, etc. • But the one which is more useful in the next steps of the process is Use-Case Model. Because it is a common language between people in the project team and also other stakeholders. Sharif Univ. of Tech.

4. Introduction (Cont.) • One of the most important artifacts of the requirements disciplines is use-case model. Sharif Univ. of Tech.

5. Use case model • Use cases are usually described in a textual document that accompanies a use case diagram; the combination of these use case diagrams & their supporting documentation is known as a use case model • Illustrate a system’s intended functions (use cases), its surroundings (actors) & the relationships between them (use case diagrams) • Are used to communicate • Provide a vehicle used by customers & developers to discuss the system’s functionality Sharif Univ. of Tech.

6. Unified Modeling Language • The Unified Modeling Language (UML) is the industry-standard language for specifying, visualizing, constructing & documenting artifacts of complex software systems • The UML: • Is a language • Applies to modeling and systems • Is based on the object-oriented paradigm Sharif Univ. of Tech.

7. Actor • Someone or something that interacts with the system (exchanges information with the system) • Typically, an actor represents a role that a human, a hardware device, or even another system plays with a system. • use case is always initiated by an actor • Finding the actors also means that you establish the boundaries of the system • A single user may play more than one role Sharif Univ. of Tech.

8. Identifying Actors • Who will use the main functionality of the system? • Who is interested in a certain requirement? • Who will need to maintain, administrate and keep the system working? • With which other software/hardware systems does the system need to interact? • Other computer systems • Other applications on the same computer (I.e. X client/server) • Pitfall: don’t confuse interaction with input Sharif Univ. of Tech.

9. Notation Operator Operation • A simple Use-Case Model: • Operator is the only actor of the model. • Operator is the initiator of the Operation Use Case. Sharif Univ. of Tech.

10. Use cases • A use case describes a set of sequences, in which each sequence represents the interaction of the things outside the system (its actors) with the system itself • Use cases form the basis of how the system interacts with the outside world (users, other systems, etc.) • “A use case is a sequence of transactions in a system whose task is to yield a measurable value to an individual actor of the system” • Describes WHAT the system (as a “Black Box”) does from a user’s perspective • A set of scenarios tied together by a common user goal Sharif Univ. of Tech.

11. Why Use Case? • Captures functional requirements from user’s perspective • Gives a clear and consistent description of what the system should do • A basis for performing system tests • Provides the ability to trace functional requirements into actual classes. • Serves as a unit of estimation • The smallest unit of delivery Sharif Univ. of Tech.

12. People who use use cases. • Customers will use the use cases to understand the system's behavior, and, since they must approve the use case's flow of events, customer will also use the use cases to approve the result of use-case modeling. • Potential users will use the use case to understand the system's behavior. • Software Architects will use the use cases to identify architecturally significant functionality. • People who analyze, design, and implement the system will use the use case to understand the required system behavior and to refine the system. • Use-case designers will use the use cases' flows of events to find classes. (These are the most important artifacts for use-case designers.) • Testers will use the use cases as a base for identifying test cases. • Managers will use the use cases to plan and follow up the use-case modeling. • Documentation writers will use the use cases to understand what sequence of use should be described in the documentation (such as the system user guide). Sharif Univ. of Tech.

13. Finding Use Cases • For each of the actors previously defined: • Which services does the actor require from the system? • Read, create, destroy, modify, store information • Does the actor have to be notified about events in the system, or does the actor need to notify the system about something? • Could the actor’s daily work be simplified? • Don’t concentrate only on the current system Sharif Univ. of Tech.

14. Validating Use Cases • Is the use case complete? • Is the actor’s goal going to be met? • Are there any changes that would simplify the process depicted in the use case? • Are there any additional goals that are not addressed? • Are there any additional actors that are not represented? Sharif Univ. of Tech.

15. UC Description Properties • Name • Name of use case, usually close to the user’s goal • Forward traceability (unique) • Description • A brief description of the role and purpose of the use case. • Flow of Events (Main Flow) • A textual description of what the system does in regard to the use case (not how specific problems are solved by the system). The description is understandable by the customer. • Alternative flows • A textual description of the exceptional paths in the main flow of the use-case Sharif Univ. of Tech.

16. UC Description Properties (cont.) • Pre-conditions • The necessary conditions that have to be met before the use case can be performed • Could be other Use Cases as well (not equivalent to <<include>> at the beginning of the description) • Post-conditions • The state of the system after the use case is performed • The value delivered to the actor • Distinguishes between variations and exceptions • Special Requirements • A textual description that collects all requirements, such as non-functional requirements, on the use case, that are not considered in the use-case model, but that need to be taken care of during design or implementation. • Reference to requirements • Backward traceability Sharif Univ. of Tech.

17. Some Notes • The first four properties construct UC outline. • Business UC are which describe current system. • Basic flow denotes successful scenario which should also contain: • How the UC will be started. • How the UC will be finished. Sharif Univ. of Tech.

18. Recommended Workflow • Identify actors (and their relationships if necessary) • For each actor identified and until no new UC is discovered do • Find all the goals of the actor • Decide on the main course of success for each goal • Create a Use Case for each of the goals • New actors/goals may be discovered • Validate/correct existing Use Cases • Draw the Use Case diagram • Simplify model by repeating the process incase the produced diagram is too complex Sharif Univ. of Tech.

19. Clerk Supervisor Manager Relationships between Actors • When several actors as part of their roles, also play a more generalized role, it is described as generalization • The behavior of the general role is described in an actor super-class • The specialized actors inherit the behavior of the super-class and extend it in some way • Relationships between actors are not always necessary Sharif Univ. of Tech.

20. X Y << include >> Use Case Relationships • Include relationship (“uses” in older versions) • When a number of Use Cases have common behavior, this behavior can be modeled in a single use case that is used by the other use cases • X << includes >> Y indicates that the process of doing X always involves doing Y at least once • Beware of functional decompositions • The included Use Case must be complete • X must satisfy the pre-conditions of Y before including it Sharif Univ. of Tech.

21. Specialized Generalized Use Case Relationships (cont.) • Generalization relationship • Used when a number of Use Cases all have some subtasks in common, but each one has something different about it that makes it impossible to lump them all in a single use case • The generalized and specialized use cases must share the same goal • A specialized Use Case may capture an alternative scenario of the generalized Use Case • The generalized Use Case must be complete • The Specialized use case may interact with new actors. • The Specialized use case may add pre-conditions and post-conditions (AND semantics). Sharif Univ. of Tech.

22. Use Case Relationships (cont.) • Extend relationship • Model conditional, or optional behavior in a business use case by describing the workflows in different use cases, where conditional or optional behavior is distinguished from mandatory behavior. • Model a complex workflow that seldom occurs. • Model a separate subflow that is only run under certain conditions. • Model several different business use cases that can be inserted at a certain point (the order being governed by the business actor Sharif Univ. of Tech.

23. Use Case Relationships (cont.) • Extend relationship • The business use cases being extended have to be meaningful and complete in themselves, even if the workflow of the added business use case is not executed. Sharif Univ. of Tech.