Start at 17th March 2012 end at 31th March 2012 Phase4 (use Cases) Start at 17th March 2012 end at 31th March 2012

Use Case Diagrams Any use case diagram should contain: Actor(s). Use cases. Associations/Relationships among actors and use cases.

Actors Actors are drawn as stick persons with the role of the actor written below. Actor names are unique typically represent the role that an actor plays with respect to the system. Is someone (e.g. human beings) or something (e.g. other objects or systems) that interact with the system. Is entity external to the system who participates in the story of the use case (receive or input), such as a person, computer system or organization. Example: a library clerk, cashier, customer, Passenger, GPS satellite, bank, customer department. Actor role name

Use Case Use cases are drawn as ellipses with the name of the use case written inside the ellipse. Use case name typically consists of an active verb and one or more nouns that concisely describe the system function modeled. Use case

Use Case(s) Each use case have an associated behavior specification which describes the sequence of actions making up a use case scenario. Use case behavioral description has two formats: Expanded Use Case High Level Use Case Describes a process in details. It has an additional section not present in HL. Describes a process very briefly, usually in 2 or 3 sentences. Purpose: Intention of the use case. Type: 1- Primary, Secondary or Optional. 2- Essential or Real. Cross References: Related use cases and system functions. Typical course of actions: describes in detail the conservation of interaction between the actors and the system. It consists of : Use Case: Use case name. Actors: List of actors (external agents) indicating who initiates the use case. Description (Success scenario): Narrative description of the process.

Plan and Elaborate Phase Steps Define system function. Define system boundary, actors & use cases. HL use cases. Draw use case diagram. Expand critical use cases (Essential / Analysis). Real use case (Design). Rank use case.

Relationships between Use Cases Include - use cases that are included as parts of other use cases. Extend - use cases that extend the behavior of other core use cases.

Relationships between Use Cases The base use case explicitly incorporates the behavior of another use case at a location specified in the base. The included use case never stands alone. It only occurs as a part of some larger base that includes it. base included <<include>>

The <<include>> Relationship

Relationships between Use Cases The base use case implicitly incorporates the behavior of another use case at certain points called extension points. The base use case may stand alone, but under certain conditions its behavior may be extended by the behavior of another use case. base extending <<extend>>

The <<extends>> Relationship

Example: Library System University library system requirements Books and journals – the library contains books and journals. It may have several copies of a given book. Some of the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Only members of staff may borrow journals. Members of the library can normally borrow up to six items at a time, but members of staff can borrow up to 12 items at a time. New books and journals arrive regularly, and old ones are sometimes disposed of. The current year’s journals are sent away to be bound into volumes at the end of each year. Borrowing – it is essential that the system keeps track of when books and journals are borrowed and returned. The new system should also produce reminders when a book is overdue. There may in future be a requirement for uses to be able to extend the loan of a book if it is not reserved. Browsing – this system should allow users to search for a book on a particular topic, by a particular author, etc., to check whether a copy of the book is available for loan and, if not ,to reserve the book. Anybody can browse in the library. P. Stevens, R. Pooley. Using UML: Software Engineering with Objects and Components. Addison-Wesley, 2000

Define actors and use cases: reserve books, Borrow Resources , Extend loan, Resources Browsing, Manage loans Borrower Resources Browsing Visitors Add resources, delete resource , Register Borrowers, update catalogue Library clerk

High Level Use Case Format: HL Borrow Resources Use Case: Borrow Resources. Actors: Borrower (initiator), library clerk Type: Primary, Essential. Description: A Borrower arrives at a checkout with Resources to Borrow. The library clerk records the Borrowed resources and calculate loans. On completion, the Borrower leaves the library with the resources.

High Level Use Case Format: HL Resource Browsing Use Case: Resources Browsing. Actors: Visitors (initiator). Type: Primary, Essential. Description: A Visitors can search for a resources by their topic, authors, ISBN ,titles and….Members of the library can check the availability of resources or reserve it.

High Level Use Case Format: HL Add resources. Use Case: Add Resources Actor: Library clerk. Description (Success Scenario): The use case begins when the Librarian receives new resources (books and journals) to add to the catalog. The title, call number, and other information are recorded. Then the resources are placed on a shelf organized by resource type and call numbers.

Use Case Diagram Lib system Browse Cancel Borrowing Visitor <<Extend>> Visitor Borrow copy of Resources Return copy of Resources <<Include>> Manage loan Extend loan Borrower Delete Resources Reserve books Add Resources Register Members Librarian Update Catalogue

Expanded Use Case Format Borrow Resources Use Case: Borrow Resources. Actor: Borrower (initiator), library clerk. Purpose: Capture borrowing information. Overview (Success Scenario): A Borrower arrives at a checkout with Resources(books and journals) to Borrow. The library clerk records the Borrowed resources and calculate loans. On completion, the Borrower leaves the library with the resources.. Type: Primary, Essential . Cross References: none.

Expanded Use Case Format Example: Borrow Resources(cont.) System Response Actor Action 1. This use case begin when Borrower arrives at the checkpoint after browsing a list of resources to borrow. 3. The system will check member ship and calculate the number of resources, check resources overdue then issues loans card for it. 2. The Library Clerk records the resources for registered borrowers. 5. Logs the completed borrowing. 4. The clerk will give borrower resources with loan card. 5.The Borrower will leave with resources and load card.

Expanded Use Case Format Example: Borrow Resources(cont.) Alternatives: Line 2. Borrower are not register cancel borrowing operation. Line 3. Borrower exceed the number of allowed resources.

Example 2 - Banking System

Example 3 – ATM System