Documente Academic
Documente Profesional
Documente Cultură
C-DAC, 2009-10
FPGDST
Contents
Requirements Collection The UML Mechanism Actors Use cases Use Case Diagrams Use Case Documentation Template Steps in Use Case Modeling Use Case Realization Summary
C-DAC, 2009-10 2
FPGDST
Requirements Collection
Requirements forms the basis of any software development activity. Denotes the user-requirements; defines the goals to be achieved.
Must be precisely and completely understood by the team providing the solution.
User requirements (and team members) keep changing; requirements must therefore be welldocumented.
C-DAC, 2009-10 3
FPGDST
Requirements must be complete, consistent and unambiguous. Must be reviewed, reviewed again and reviewed yet again before the design and implementation begins. Involves the participation of domain-experts to ensure that the requirements have been correctly understood. captures the WHAT of the problem-domain.
C-DAC, 2009-10 4
FPGDST
Captures the problem-domain in terms of functionality to be provided (Use Cases), and the roles (Actors) for whom these functions are performed. An abstraction of the problem-domain and a vehicle to facilitate a clear, well-articulated and unambiguous understanding of the problemdomain.
C-DAC, 2009-10 5
FPGDST
Actors
Entities external to the system who interact with the system. Communicate with the system by sending and/or receiving messages.
FPGDST
Finding Actors
Who uses the main functionality of the system? Who needs support from the system? Who will need to maintain, administrate, and keep the system working?
C-DAC, 2009-10
FPGDST
Use Case
Is an abstraction of a set of sequences that yield some functionality. Represents some user-visible function. Is always initiated by an actor. Describes the interaction between the actors and the system for a system function. Achieves a discrete goal for the actor. Notation:
ParseQuery
C-DAC, 2009-10 8
FPGDST
To capture functional requirements of a system. To communicate with end users and domain experts. To design test cases for validating system functionality. To provide traceability from requirements into actual classes and operations. To drive the development process. To plan iterations and releases
C-DAC, 2009-10 9
FPGDST
What functions does the system perform? What functions do the actors require?
C-DAC, 2009-10
10
FPGDST
A graphical representation of the Use Cases of a system, its actors, and the interaction between them.
It depicts the system boundary.
Diagram Model elements Actors Use cases Relationships between Actors and Use Cases between Use Cases themselves
C-DAC, 2009-10 11
FPGDST
C-DAC, 2009-10
12
FPGDST
C-DAC, 2009-10
13
FPGDST
Is a text description of the use case functionality in the user language and terminology No specific UML format Describes WHAT and not HOW
Typically includes: Objectives of the use case How the use case is initiated The flow of events Alternate flow in the use case How the use case finishes with a value to the actor
C-DAC, 2009-10 14
FPGDST
Flow of Events
The behaviour of the Use Case can be described by a flow of events - which spells out in slight detail what exactly the Use Case does.
Typically, flow of events specifies: the main flow of events (what happens and in what order when all is well). alternate flow(s) of events (what happens and in what order when something goes wrong).
C-DAC, 2009-10
15
FPGDST
A Use Case actually describes a set of sequence of actions, specified in primary & alternate flows. Each sequence represents one possible flow of actions in using the system. Each sequence is called a Scenario. A Scenario is basically one instance of a use case. a Scenario is to a Use Case, what an Object is to a Class.
C-DAC, 2009-10
16
FPGDST
FPGDST
C-DAC, 2009-10
18
FPGDST
Draw Use case diagram: Connect all the use cases to the respective
actor to form a preliminary use case diagram.
Refine Use case diagram: Identify the dependency between the use
cases (using stereotypes include, extends etc.)
FPGDST
Example
The Bookworm is a circulating library that lends books and journals for a specified period of time. Books are lent to members only. If available, the book is issued forthwith to the requesting member. If the book is not currently available, the member can reserve the same. If the member fails to return the book after the specified period and/or loses or damages the book, he is required to make good the loss/damage. Alternatively, at the end of the period, the borrower may renew the issue.
Membership is accorded for a period of one year, at the end of which the member has the option to renew his membership.
C-DAC, 2009-10 20
FPGDST
Actors ?
Librarian
Member
Identify Behavior of each actor - Librarian: Issues Book, Collect Dues, Renew Issue,
View Catalog - Member: Return Book, Reserve Book, Renew membership, View Catalog
C-DAC, 2009-10 21
FPGDST
Use Cases:
ReserveBook
IssueBook
ReturnBook
CollectDues
RenewIssue
RnwMship
ViewCatalog
C-DAC, 2009-10
22
FPGDST
RnwMship
ViewCatalog
C-DAC, 2009-10 23
FPGDST
CollectDues Librarian
ReturnBook RenewIssue
Includes
ReserveBook
includes
Permit Transaction
RnwMship ChgsDue
Member
BkReserved
extends
extends
C-DAC, 2009-10
24
FPGDST
Primary Flow : -Use case begins when actor starts browsing for book - Actor enters Title (E-1) or Author name (E-2) or Publisher name (E-3) - Books satisfying the specified criteria are displayed - Actor may select one of the results or may refine the search(E-4). Alternate Flow : E-1: If the specified title is not available, re enter the title or terminate the use case E-2: If the displayed result doesnt fetch the required book, re-enter the author name or terminate the use case E-3: If the displayed result doesnt fetch the required book, re-enter the publisher name or terminate the use case E-4: If the displayed results doesnt fetch the required book or many titles by the same publisher or author are displayed then the search may be refined. Actors : Librarian, Member
C-DAC, 2009-10 25
FPGDST
FPGDST
Use Case A
<<implements>> Class A
<<implements>> Class B
<<implements>> Class C
Oper1() ...
Oper2() ...
Oper3() ...
C-DAC, 2009-10
27
FPGDST
Realization: Example
:UserInterface
Code Generator
4: Execute(code) : Database : Runtime Processor
C-DAC, 2009-10
28
FPGDST
FPGDST
C-DAC, 2009-10
30
FPGDST
Summary
Requirements elicitation is the stepping stone to the project. Requirements must clearly and completely understood by the entire project team. Must be reviewed for semantic correctness and completeness.
Requirements elicitation must focus on the WHAT of the system and must be documented in the users vocabulary.
Use Case Diagrams is the UML mechanism for requirements capture. Use Case Diagrams are a graphical presentation of the actors in the domain and the use cases initiated by them.
C-DAC, 2009-10 31
FPGDST
Summary
Use cases are abstractions of discrete behaviour exhibited by the system; perform a specific goal for an actor. An actor is an abstraction of a role played by anyone or anything interacting with the system. A use case is essentially a set of sequence of actions. A specific sequence of this set of sequences is called a scenario. A scenario is documented as Flow of Events; each use case has a main flow of events and alternate flow of events. Common behaviour across use cases can be factored out and is then either used or extended by other use cases.
C-DAC, 2009-10 32
FPGDST
EXERCISE
Write the Use Case Descriptin for the use cases of Bookworm Library
C-DAC, 2009-10
33
FPGDST
References
C-DAC, 2009-10
34
FPGDST
E-Resources
http://pnguyen.tigris.org/SER4505.pdf http://www.sparxsystems.com/downloads/w hitepapers/The_Use_Case_Model.pdf http://www.bredemeyer.com/pdf_files/funct req.pdf http://www.parlezuml.com/tutorials/usecase s/usecases_intro.pdf