OOP

1
References Jacquie Barker,Beginning Java
Objects Xiaopig Jia,Object-Oriented
ProgrammingAnthony Sintes,Teach Yourself Object
Oriented Programming Martin Fowler,UML
Distilled,
2
Use Cases - Motivation

• Use case diagrams were Jacobsens contribution to
  UML.
  
• Use cases are an artifact produced during
  analysis. During this time the developers elicit
  system requirements by asking users what they
  want to do with the system and what kind of
  responses they expect from it.
• Discovering requirements is use case analysis
• Use cases can help define what an iteration is.
  Can also be used to validate the system.
  
• System is the OOA term for a set of interacting
  objects. Requirements are features that the
  system must have to solve a given problem.
  
• By writing use cases for a system, developers can
  make sure that no particular kind of user or
  potential purpose for the system is overlooked.
  

3
Actors and Roles

• An actor is a role that a user plays in the
  system.
  
• There may be many actors playing the same role.
• E.g. many students all play the same role
• Actors may take on different roles at different
  times (a faculty member may also be dept.
  chair)
  
• We should think about roles rather than people or
  job titles.
  
• Actors carry out use cases.A single actor can
  perform many use cases a use case may have many
  actors performing it.

4
Use Cases - Actors

• An actor must be created for every role that
  might be assumed by a real user of the system.
  
• The narrative requirements specification is the
  first place to look for the roles. From
  roles(actors), we can derive use cases.
  
• In the Student Registration System (SRS), actors
  could include

Students Faculty Dept. chairs Alumni Prospecti
ve students
Registrars Office personnel The Billing
Department The Classroom Scheduling System The A
dmissions System
and so on.
Note Actors dont have to be human
5
Use Cases - Actors

• Fowler A good source for identifying use cases
  is external events. Think about all the events
  from the outside world to which you want to
  react. A given event may cause a system reaction
  that does not involve users, or it may cause a
  reaction primarily from the users. Identifying
  the events that you need to react to will help
  you identify the use cases.

6
Use Cases

• Each use case has a name and a set of scenarios.
• A scenario is a sequence of steps describing the
  interaction between the actors and the system.
  
• Alternative flows of events are described as
  alternative scenarios that complement the main
  scenario.
  
• Exceptional scenarios describe events and
  outcomes when preconditions of main scenario are
  not met or when errors or exceptions occur during
  normal flow of events.

7
Use Cases - scenarios

• Together, the scenarios describe a particular
  goal or outcome of the system and by whom the
  outcome is expected.
  
• The goal of the student registration system is
  to enable a user to register for a course
  
• Scenarios are described in one of two formats
• 1. a paragraph of text
• 2. a table in which one column describes the
  input events generated by actors and second
  column describing response produced by the system

8
Scenario

• The following scenario describes Buy a Product
• the customer browses the catalog and adds
  desired items to the shopping basket. When the
  customer wishes to pay, the customer describes
  the shipping and credit card information and
  confirms the sale. The system checks the
  authorization on the credit card and confirms the
  sale both immediately and with a follow-up
  email. --Fowler
• Another scenario might be the credit card
  authorization fails.

9
Example Use Case - Text (Fowler)

• The text can be a narrative or numbered steps
• Buy a Product
• Customer browses catalog and selects items to
  buy
  
• Customer goes to check out
• Customer fills in shipping info
• System presents full pricing info, including
  shipping
  
• Customer fills in credit card info
• System authorizes purchase
• System confirms sale immediately
• System sends confirming email to customer
• Alternative authorization failure
• At step 6, system fails to authorize credit
  purchase
  
• Allow customer to re-enter credit card info and
  re-try
  
• Alternative regular customer
• 3a. System displays current shipping
  information, pricing info, and last 4 digits of
  credit card info
  
• 3b.Customer may accept or override these
  defaults
  

10
Use Cases

• Take this set of use cases for an online banking
  system
  
• Logging on
• Making a payment
• Transferring funds between accounts
• Reviewing account balances
• Each of these use cases could be composed of one
  or more scenarios
  

11
Use Cases

• Alistair Cockburn, in Writing Effective Use
  Cases, warns that reading use cases is easy
  writing them is harder.
  
• He states that the writer must master three
  concepts that apply to every sentence in the use
  case and to the use case as a whole. These
  concepts are
• Scope what is really the system under
  discussion?
  
• Primary actor who has the goal?
• Level how high- or low- level is that goal?

12
Use Cases

• Scope identifies the system under discussion
  (SuD)
  
• The primary actor is the stakeholder that
  initiates an interaction with the SuD to achieve
  a goal
  
• Stakeholder is a person or thing that has an
  interest in the behavior of the SuD (e.g.
  customers, vendors, other programs)

13
Use Cases

• It is the responsibility of the sponsor of the
  project, not the software engineer, to eliminate
  requirements from the scope .
  
• For example, we will assume that alumni and
  prospective students will not be part of the
  first iteration of the SRS case study.
  
• Once you decide who/what the actors are, you can
  diagram their interaction with the system using
  UML. Diagrams are entirely optional.
  

14
UML Notations for Actors and Use Cases

• A use case diagram consists of
• use cases
• actors
• relationships among actors and use cases

User
An actor
Case 1
A use case
15
Use Case Relationships

• Use case relationships represented in UML are
• extension or generalization (among actors)
• association (between actors and use cases)
• dependency (among use cases)
• include
• extend
• generalization

16
Use Case Relationships in UML

• An extends relationship is like the extends
  relationship among classes
  
• an actor representing a general group of users
  can be extended (specialized) by another actor
  representing a more specialized group of actors
  
• An association relationship is between use case
  and actor
  
• uc1 uc2 means use case uc1 is part
  of use case uc2
  
• uc2 uc1 means use case uc2 is a
  special case of use case uc1

17
Extension Relationships (Jia diagram)
User
Faculty
Registrar
Student
18
Dependency Relationships

Check grades
Validate user
Student

User
Get roster



Faculty
Enter grades
Verify grades
Registrar
Diagram from Jia
19
Use Case Diagram - SRS (Barker)
Billing System
Student
SRS
Admissions System
Faculty
Classroom Scheduling System
Dept.Chair
Note Modified UML notation (non-human
actors are in boxes, not stick figures
Registrar
20
Use Cases for SRS

• Register for a course
• Drop a course
• Determine a students course load
• Choose a faculty advisor
• Establish a plan of study
• View schedule of classes
• Request a student roster for a given course
• Request a transcript for a given student
• Maintain course information
• Determine a students eligibility for graduation
• Post grades for a given course

These are high-level use cases (goals)
Some use cases can be decomposed
21
Decompose Use Cases

• Register for a course can be decomposed into
  different scenarios
  
• verify a student has met prerequisites
• check students plan of study
• check for seat availability
• wait-list the student (optional)

22
Matching Use Cases and Actors

• Barker suggests matching actors with use cases
  and creating a table of the relationships

Initiating Actor ? Student Faculty BillingSyste
m (etc.) Use Case Register for cou
rse provides info N/A N/A Request transcript con
sumes info consumes info N/A Post final grades co
nsumes info provides into N/A Determine student c
onsumes info consumes info consumes info
course load (etc.)
Cross-referencing actors with use cases ensures
you dont identify an actor who has no use for
the system and that you dont specify a use case
that is unnecessary.