Use C ase M odel and Use Case D iagrams

1. Use Case Model and Use Case Diagrams JunaSomare(2008-BCT-515) Pratima Lingden(2008-BCT-524) SabanamLakhey(2008-BCT-533)

2. Use case model • A set of scenarios that describes an interaction between a user and a system • Represent different ways in which a system can be used by the users • Involves a sequence of interactions • Viewed as a set of related scenarios tied together by a common goal • Represents a functional or process model of a system

3. Use case diagrams A use case diagram is “a diagram that shows the relationships among actors and use cases within a system.” Use case diagrams are often used to: Communicate the scope of a development project Provide an overview of all or part of the usage requirements for a system or organization in the form of an essential model or a business model Model your analysis of your usage requirements in the form of a system use case model

4. Elements of Use case Diagram: Use Case Diagrams have 4 major elements: • Actor: A user or another system that will interact with the system you are modeling. • Use case: A use case describes a sequence of actions that provide a measurable value to an actor • Relationship: An association between an actor and use case or two use cases. • System boundary boxes: The rectangle around the use cases is called the system boundary boxes. It indicates the scope of system.

5. Representation of Use Case Diagram elements 1. Actor: Represented by using stick person icon. Figure: Online shopping

6. 2. Use case: Represented by ellipse Figure: Implying timing considerations between use cases

7. 3. Relationship : Lines connecting two modeling elements with an optional open-headed arrowhead on one end of the line Figure: Enrolling students in a university

8. 4. System boundary box : Represented by rectangle around the use cases. Tic-tac-toe game Play move

9. Why consider use cases? • In a traditional Software Requirements Specification (SRS), features are presented without context. For example: The system shall log credit payments to the accounts receivable system. The lack of context makes room for ambiguity. • When does this event happen? • Is the order relative to other events significant? • Who triggers the event? • What happens when the accounts receivable system is unavailable? • In addition, a traditional SRS tends to devolve into a numbered list of detail that drones on page after page very difficult for the system's stakeholders to absorb. Use cases break requirements down into short "stories" so that readers can more easily understand the system.

10. E X A M P L E

11. Advantages • useful for scoping. • an excellent bridge between the software developer and end users. • Does not use a special language. • Easy to describe Use cases by turning it into a story or scenario. • Recorded using the UML and maintained within available CASE tools. • Test cases can be directly derived from the use cases

12. Disadvantages Not good at capturing non-functional requirements. No guarantee of templates clarity. difficult to avoid the temptation of describing user interface too early. Low information content.

13. Thank you!