From use cases to classes (in UML)

1
From use casesto classes (in UML)
2
A use casefor writing use cases

• Use case writing a use case
• Actors analyst, client(s)
• Client identifies and write down all the actors.
• Analyst writes down all the actors.
• Client identifies the use cases, i.e., goals that
  actors can achieve step by step.
• Analyst draws a use case diagram documenting the
  relationships between the actors and use cases.
• Analyst describes main scenario for a use case,
  step by step.
• Analyst describes any alternatives to the main
  case.
• Analyst reviews the use case with client to make
  sure it is understandable and correct.
• Alternative Refine use case
• 7a. If client may request changes then go to
  relevant step above

3
Exercise

• I am the manager of a theatre.
• I want to create an automated movie ticket
  machine.
• You are analysts who need to describe what the
  customer wants as a set of use cases
• Simplifying assumptions
• One movie showing at a time
• Movie time is same every day, only one time, same
  price
• Only manager can change/add movie
• Customer can only buy tickets
• Who or what are the actors?
• What are the use cases (goals of actors)?

4
Use case diagramfor Movie Ticket Machine

• Why are there three Actors?
• Why three use cases for Customer?
• Which use cases look easy to write?

5
Use cases for Manager

• Use case Set title
• Actors Manager, Machine
• 1. Manager requests a change of movie title
• 2. Machine asks manager for new movie title
• 3. Manager enters movie title
• Use case Set price
• Actors Manager, Machine
• 1. Manager requests a change of ticket price
• 2. Machine asks manager for new price for movie
  title
• 3. Manager enters ticket price
• Alternatives Invalid price
• If manager enters price below 1 or greater than
  10
• 3a. Machine asks manager to reenter price
• Use case Set seats
• Actors Manager, Machine
• 1. Manager requests a change in number of seats
• 2. Machine asks manager for number of seats in
  theatre

6
Use cases for Customer

• Use case of tickets
• Actors Customer, Machine
• 1. Customer enters number of tickets
• 2. Machine displays total balance due
• Alternative Customer wants zero tickets
• At step 1, customer enters zero tickets
• 1a. Display thank you message
• 1b. Set balance to 0.0
• Use case Return change to customer
• Actors Customer, Machine
• 1. Customer requests change
• 2. Machine dispenses money
• 3. Machine updates customer balance

• Use case Buy tickets
• Actors Customer, Machine
• 1. Customer requests tickets
• 2. Machine tells customer to put balance
  due in money slot
• 3. Customer enters money in money slot
• 4. Machine updates customer balance
• 5. Customer requests tickets
• 6. Machine prints tickets
• 7. Machine updates number of seats
• Alternative Insufficient seats
• At step 1, if number of tickets requested is
  less than available seats,
• 1a. Display message and end use case
• Alternative Insufficient funds
• At step 5, if money entered lt total cost,
• 5a. Display insufficient amount entered
• 5b. Go to step 3

7
Domain analysis

• So far weve looked at requirements
  analysisunderstanding what the customer wants.
• Domain analysis understands the customers
  problemby identifying the classes comprising a
  problem domain.
• Booch "an attempt to identify the objects,
  operations, and relationships that domain
  experts perceive to be important about the
  domain.
• Result of OO analysis is a UML class diagram
  modeling the concepts and relationships in
  problem domain.
• Separation of concerns principle Keep problem
  domain model distinct from user interface or
  database modeling. Why?

8
Identifying classes is category-formation

• Objects simulate a slice of the world which a
  computer system models
• Why are objects are a natural construct for
  simulation?
• Classes of objects are a natural way to organize
  classes
• Infants learn to recognize objects and how to
  categorize them in their first few months
• A key insight of the child psychologist Piaget
  and cognitive science
• Adults rely on categorization to understand the
  world
• We create new categories all the time. Examples?
• New makes of cars, new technological gadgets, new
  courses and curricula.
• Natural categories, can be hard to define
  precisely
• Natural kinds how do you define an elephant? a
  game?
• Prototypes people see how close objects match a
  prototypical member of a category
• Why is the fuzziness of natural kinds a problem
  for OOSE?
• It's hard to be precise about defining categories
• That's why we need methodology for OO analysis
  and design

9
Candidates for classes

• Tangible things referred to by common nouns in
  requirements spec
• I.e., cookie, factory, triangle
• Events with associated information (i.e., flight,
  game).
• Abstract data stores (i.e., buffer, tree, hash
  table)
• External interface ports (i.e., terminal,
  printer, window, menu)
• Complex processes or operations (i.e., sort, edit
  command)
• Note verbs can also be classes!
• Especially processes than store state information
• Parsing -gt Parser, Scanner as a subclass of
  String
• Can anything be a class? What isn't a class?
• Indeed, category-formation is a fundamental human
  activity
• Proper nouns are instances of classes, not
  classes
• Classes have content store state information and
  perform operations
• If it doesnt store state and perform multiple
  operations, keep it simple
• Classes with just one or two routines (probably
  not worth classifying)
• Redundant classes merge synonyms, reuse classes
  in libraries

10
Defining terms

• Why is defining a glossary of terms especially
  helpful to OO analysis?
• Brief dictionary-like definitions describe how
  the term is used in domain
• Terms can help with the discovery of classes and
  their structure
• Maintain glossary files throughout development,
  finally as documentation

11
From use cases to classes

• 1. Identify classes of objects in the problem
  description
• Heuristic nouns may be classes
• But verbs can be nominalized (iterate-gtiteration
  , withdraw-gtwithdrawal)
• Heuristic does it store state (does it have
  attributes) and does it have operations?
• 2. Identify attributes of each class
• What characteristics are important to keep track
  of?
• What data must be maintained or remembered during
  objects life?
• 3. Identify methods of each class
• What actions must the object be able to perform?
• What actions can be done to the object (e.g., to
  change its state)?
• Use cases may correspond to methods
• 4. Identify parameters and return types of
  methods
• What input does a method need from caller? These
  are parameters.
• Does the method generate a result value?
• The return type must match the data type of data
  to be returned.