3. use cases
Upcoming SlideShare
Loading in...5
×
 

3. use cases

on

  • 2,772 views

 

Statistics

Views

Total Views
2,772
Views on SlideShare
2,772
Embed Views
0

Actions

Likes
0
Downloads
109
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 1
  • A use case captures some user visible function A use case may be small or large A use case acheives a discrete goal for the user Techniques: Identifying use cases Based on the system scope model, we think of our system as a black box which Responds to envents ocurring along a chain of activities, representing a typical system cycle producing some response. We treat each use case as a self contained unit of interaction. It must be performed a single actor ina single place although it might result in output flows to other passive actors. The use case must also leave the system in a stable state; this may result in a some measurable value to it’s user.
  • The uses(include) occurs when you have a chunk of behaviour that is similar across more than one use case. Included use cases never stands alone- an example of delegation Use extend when you want to have one use case that is similar to antother use case but does a bit more-may extend to model optional behaviour – base use case may stand alone but under certain conditions e.g. plac an order might read: main flow of events: include (Validate user(set priority) – an extension point Similiarities imply factoring out common code Differeneces: in the case of extends actors have a relationship to the use case that is extended. It is assumed that a given actor willperform both the base use case and all of the extensions Different designers make use of use cases with varying degrees of granularity As uou perform modelling tasks you will come up with models that express how to do you use cases, there is more than one way these are called realisations.

3. use cases 3. use cases Presentation Transcript

  • Use Cases Chapter 3Object-Oriented Software Systems Engineering – Chapter 3 Slide 1
  • Objectives In this chapter we will:  Describe use case modelling  Introduce use cases and actors  Discuss relationships between use cases  Introduce use case descriptionsObject-Oriented Software Systems Engineering – Chapter 3 Slide 2
  • Use Case Modelling  The purpose of use case modelling to decide and describe the functional requirements of the system to give clear and consistent description of what the system should do to provide a basis for performing tests that verify the system to provide the ability to trace functional requirements into classes and operations  Use case model represents use-case view is described by a use-case diagramObject-Oriented Software Systems Engineering – Chapter 3 Slide 3
  • Use Case Modelling Use Cases are described using both text documents and diagrams Use-case modelling is primarily an act of writing text NOT just drawing diagramsObject-Oriented Software Systems Engineering – Chapter 3 Slide 4
  • Use Case Modelling  Definition of use case  represents a complete functionality as perceived by an actor  a set of sequences of actions a system performs that yield an observable result of value to a particular actor  Characteristics  is always initiated by an actor  provides tangible value to an actor (observable not necessary salient)  is complete - use case is not complete until an end value is produced even if several communications occur along the way  Scenario’s are instances of use-cases  A specific sequence of actions that illustrate behaviour  You’ll find primary scenarios and secondary scenariosObject-Oriented Software Systems Engineering – Chapter 3 Slide 5
  • Use Case Modelling – terms & concepts Name of System An Actor A Use CaseObject-Oriented Software Systems Engineering – Chapter 3 Slide 6
  • Use Case Modelling – terms & concepts  The system boundary  defines responsibility  black box that provides use-cases  within the system boundary  what the system does but not how the system does  Use-cases  a description of a set of sequence of actions, including variants that the system performs to yield an observable value to an actor  a set of scenariosObject-Oriented Software Systems Engineering – Chapter 3 Slide 7
  • Use Case Modelling – terms & concepts  Actor  representing a role that someone might play, rather than a particular individual  external entity that has interest in interacting with the system  Interaction  a communication relation between an actor and a use caseObject-Oriented Software Systems Engineering – Chapter 3 Slide 8
  • Identifying Use Cases and Actors  What functions does the actor require from the system?  Does the actor need to read, create, destroy, modify or store some kind of data in the system?  Does the actor have to be notified about events in the system, or does the actor need to confirm with the system for something?  Could the actor’s daily work be simplified or made more efficient via new functions in the system?  What input/output does the system need?  Can these requirements be handled by one actor or someone else as well?Object-Oriented Software Systems Engineering – Chapter 3 Slide 9
  • Use Case Modelling – organising use cases Communication AssociationUML use-case diagram An Actor A Use CaseCommunication associations: UseCase 1connect actors to use cases User 1 UseCase 2 Manager UseCase 3 User 2 Object-Oriented Software Systems Engineering – Chapter 3 Slide 10
  • Use Case Modelling – types of relationships Relationships between actors generalization - specialization Library User Student LecturerObject-Oriented Software Systems Engineering – Chapter 3 Slide 11
  • Use Case Modelling – types of relationships Two stereotypes of dependency relationship in use casesInclude Extends specifies that the source use case specifies that the target use case (A) explicitly incorporates the (B) extends the behaviour of the behaviour of the target (B) source (A) A includes the behaviour of B A is extended from B by adding some actions <<include>> <<extends>> Extension points A B A B Object-Oriented Software Systems Engineering – Chapter 3 Slide 12
  • Use Case Relationships Extend and Uses relationship - different forms of re-use  Extend relationship - accounts for optional behaviour  Include relationship -uses or include relationship  one use case uses another use case  (reuse by composition) <<extends>> Place rush (set priority) order Check password Place order <<uses>> Extension points set priority Vaildate user Retinal scanObject-Oriented Software Systems Engineering – Chapter 3 Slide 13
  • part 1 A Simple Use Case Diagram of Library Library System Search for Update book catalog Library Member <<extend>> Borrow a over limit Refuse copy of book Librarian loan Reserve a book Return a e>> copy of book <<includ > d e> in clu Member of << Staff Extend loanObject-Oriented Software Systems Engineering – Chapter 3 Slide 14
  • Use Case Diagram - order processing Place order Customer <<extend>> discount extension points <<i set discount ncl << ude >> inc << Give product lud nci information e> luCustomer > de Cancel order <<i >> ncl ude >> << Update in cl account Return ud Inventory product e> system <<i > nclu de> > Update product quantities Get status on order AccountingSales Rep system Run sales report Object-Oriented Software Systems Engineering – Chapter 3 Slide 15
  • Use Case Diagram - course management Course Management System Select Register for courses to courses teach Student Request Lecturer course roster Billing system Create course Maintain catalogue course’s infor. Maintain Maintain information lecturer’s infor. Registrar Maintain student’s inforObject-Oriented Software Systems Engineering – Chapter 3 Slide 16
  • UseCase 1Use Case Actor 1diagram UseCase 2 Manager Actor 2 UseCase 3 Class 2 Class 1 Class Statediagram diagram Class 3 Class 4 <<Actor>> state 1 User c2: object c3: objectSequence 0: event state 2 diagram 1: operation 2: operation Object-Oriented Software Systems Engineering – Chapter 3 Slide 17
  • UseCase 1 Actor 1Use Case UseCase 2diagram Manager Actor 2 UseCase 3 Class 2 Class 1 Classdiagram State Class 3 Class 4 diagram <<Actor>> state 1 User c2: object c3: objectSequence 0: event state 2 diagram 1: operation 2: operation Object-Oriented Software Systems Engineering – Chapter 3 Slide 18
  • Use Case  A use case is a starting point  You may not know very much about a subject, write down what you do know  Then you need to find out the detail that you do not know but that you need to know in order to solve the problem  When we have as much detail as we need, we can produce Use Case DescriptionsObject-Oriented Software Systems Engineering – Chapter 3 Slide 19
  • Use Case Descriptions A use case description:  The text to describe a particular use case interaction - in the form of a 2-way dialogue between the actor and the system  Provides the supporting detail for the use case diagram - not to be started until the diagram is complete/nearly complete  Also known as Use Case Scripts or Use Case Scenarios (beware - the latter has another meaning)Object-Oriented Software Systems Engineering – Chapter 3 Slide 20
  • What to describe  Describe the most common/normal form of interaction first - the basic course  Describe possible variations separately - the alternative courses  The script should be in a conversational style:  actor requests….  System responds by….  Actor does…..  And so on..Object-Oriented Software Systems Engineering – Chapter 3 Slide 21
  • Example of a Use Case Description  In the video rental shop, the interaction between Counter Assistant and Rent Video use case may be: Actor Actions System Response 1. Customer tenders video(s) to be rented and membership card 2. Counter assistant enters member 3. System provides member details and no.into system status of loans and fines 4. Assistant enters identification of each video to be rented 5. System accepts ids and gives fee payable 6. Assistant requests payment, takes money and enters payment made 7. System logs payment detailsObject-Oriented Software Systems Engineering – Chapter 3 Slide 22
  • Guidelines  Include a series of numbered sections or steps which describe noteworthy events and possibly related context, constraints and business rules  Steps may alternate between actor and system, or may be a series of consecutive steps taken by either of them  Written from the user’s point of view  Written in the vocabulary of the userObject-Oriented Software Systems Engineering – Chapter 3 Slide 23
  • Conversational Style  This conversational style script (as if for a theatre play) is a good compromise between the advantages and disadvantages of other methods:  It is quick and easy to write (important for capturing early, outline information)  It is quick and easy to read and to understand  It encourages concise-ness  It identifies the required sequence of actions  It highlights causes and effectsObject-Oriented Software Systems Engineering – Chapter 3 Slide 24
  • Essential Use Cases  These are used during the feasibility and analysis stages of the project  The aim is to be free of implementation detail to show the essence of the business requirements (the conceptual model)  Enables analysts, developers, users and clients to understand the scope of the problem and the processes requiredObject-Oriented Software Systems Engineering – Chapter 3 Slide 25
  • Real Use Cases  Now the Essential Use Cases will be used as the basis for lateral, creative thinking with the opportunity for new ideas on how to create the system  Real Use Cases are used to document the design of the project  how it will work in reality  For a user interface it may include prototype screen shots, print layouts, form layouts, menus  For a system interface it may include file layoutsObject-Oriented Software Systems Engineering – Chapter 3 Slide 26
  • Template Sections The following sections are normally included:  Use Case - its identifier/name  Actors - list of actors involved. Show which one initiates the use case  Overview - short outline description summarising the use case  Type - category of the use case  Cross References - use case relationships (covered later)Object-Oriented Software Systems Engineering – Chapter 3 Slide 27
  • Categories of Use Cases 1. Primary - major common process For example: Rent Video 2. Secondary - minor or rare processes For example: Request to supply unstocked New Video 3. Optional - processes that may or may not be usedObject-Oriented Software Systems Engineering – Chapter 3 Slide 28
  • Alternative Courses  Alternative courses can describe alternative events to the typical story  These are the less common, the exceptional or error cases  Place all the alternatives after all the typical course of events  For example: 7. Customer pays clerk by cash or credit Alternative Courses 7. Customer has unpaid late charges and will not pay them. Collect payment or cancel rental transactionObject-Oriented Software Systems Engineering – Chapter 3 Slide 29
  • Use Case Descriptions Review of use case descriptions:  Use Case descriptions supply the detail of system requirements  Conversational scripts are used to describe the interactions between actors and use cases  The basic course may be followed by 1 or more alternative courses  Essential Use Cases are used during Analysis, Real Use Cases are used during DesignObject-Oriented Software Systems Engineering – Chapter 3 Slide 30
  • Summary In this chapter we have:  Described use case modelling  Introduced use cases and actors  Discussed relationships between use cases  Introduced use case descriptionsObject-Oriented Software Systems Engineering – Chapter 3 Slide 31