Use Cases

1

• Use Cases

2
Overview of software development

• The problems
• Are we building the right system?
• How to manage a large team of people?
• How to guarantee the quality of the software?
• How to prepare for changes in future?
• How to make the software easy to maintain?
• How to document the software?
• What happen if people in the team quit?
• How to deal with these problems?
• Any guidance?

3
Methodology

• The guru
• provides guidance by naming a set of best
  practices in the industry
• This set of best practices is known as
  methodology
• Examples of methodologies
• Waterfall process
• Traditional approach
• Rational Unified Process (RUP)
• Proprietary product by Rational
• Agile Process
• Extreme Programming (XP)

4
Common approach

• Divide the work in 5 stages
• 1. Requirement model
• To capture the users requirements
• 2. Analysis model
• Initial rough model of the system
• 3. Design model
• Detailed model, one-to-one mapping between the
  classes diagram and the implementation model
• 4. Implementation model
• The code
• 5. Test model

5
Requirement model

• Traditional way of capturing requirements
• Developer interviews the users
• Jog down users requirements
• Write the requirement spec
• Deliver the system two years later
• What is wrong? What is the biggest risk?

6
The biggest risk

• We build a system that is not the users want !!
• How is this possible?
• Users have no idea of what they want
• Users do not understand the technical
  specification
• Requirements change, system must change too

7
Best practice in capturing requirements

• Use-case approach
• Use cases describe how the system is used from a
  user view point, written in the language of users
• Advantages
• Users understand the spec, so that they can
  participate in the process more effectively
• In comparison
• Traditional methods write the spec from the
  developers viewpoint, using developers language
• Too technical, users cant understand it

8
Traditional software development approach

• Waterfall model

Requirement definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance
9
Waterfall model

• The traditional approach, still widely used
• Main problem
• A complete cycle can take a year to complete,
  slow to respond to changes
• Modern approaches favor shorter cycle (from a day
  to a few weeks) that build the work
  incrementally, so that
• Risks can be discovered earlier
• Changes can be made more rapidly
• Short iteration provides continuous feedback to
  the users

10
Risks

• From development point of view, risk is the most
  critical issue
• Technical risks
• risks related to new technologies, new language
• risks related to architecture
• whether the architecture is robust
• risks related to building the right system
• risks related to performance
• Non-technical risks
• do we have the people with the right experience
• too tight a schedule
• needs timely input from subcontractors

11
Use-case driven approach
Use Cases Model
Find core classes from use cases
Analysis Model
Refine the analysis model
Design Model
Turn class diagram into code
Implementation Model
Do the testing based on use cases
Test Model
12
The process is iterative

• Start from the most important use case
• produce analysis model
• produce design model
• produce implementation model (the code)
• a little testing
• Add a second use case
• repeat the process,
• modify the model if necessary

13
Case study a library system

• The university library is using a 1960s program
  written in an obsolete language for some simple
  bookkeeping tasks, and a card index for user
  browsing.
• Your task is to build an interactive system which
  handles both of these aspects online

14
How to start?

• The problem statement is vague, but typical
• The difficulty in formulating the requirements
• Users are not sure of what they want
• Users have little idea of what computers can do
• Developers are not familiar with the users
  problem domain
• Hard for the users to visualize a non-existing
  system

15
USER Business Knowledge
PROGRAMMER Programming Knowledge
Project Manager
16
How to start?

• Do you homework
• collect materials about the library system
• A meeting between domain experts (the librarian),
  the users, and the developers
• Purpose of the meeting
• identify the actors and the use cases
• actors
• users of the system (borrower, administrator)
• use cases
• how the system will be used by the actors

17
Preliminary system requirements

• This application will support the operations of
  library for university. This includes the
  searching for and lending of library materials,
  including books, videos, and journals. Borrowers
  will enter their ID numbers in order to use the
  system and they will enter material ID numbers
  when checking out and returning items
• Member can borrow books, journals, and videos for
  up to ten items. Each type of library item can be
  lent for a different period of time. If returned
  after their due date, a fine will be charged,
  based on the type of item (books 1/day, journals
  3/day, videos 5/day).
• Materials will be lent to users with no overdue
  lendables, fewer than ten items out, and total
  fines less than 100.

18
Use case model

• Who is an actor?
• entities external to the system that interacts
  with the system
• represent a role that a user can play
• Who is a user?
• An instance of the actor the actual person who
  uses the system
• e.g John is an instance of the actor Borrower

19
Use case model

• What is use-case?
• A use case is a sequence of actions that an actor
  performs within a system to achieve a certain
  goal
• use cases are written using the language of the
  users and from the user point of view
• A complete set of use-case descriptions specifies
  the complete functionality of the system

20
Use case and scenario

• Scenario
• Scenario is also a sequence of steps describing
  an interaction between a user and a system
• Borrower borrows 3 books successfully
• Borrower borrows 3 books but failed because the
  number of borrowed items exceed the limit
• . . .
• Different scenarios, same goal - borrowing
• A use case is a set of scenarios tied together by
  a common goal

21
Describe the system in the language of the users

• Traditional approach
• requirements are typically in the form
• the system shall do this and that . . .
• Use cases approach
• requirements from users point of view
• actor shall do this and that . . .
• Written in the language of the users, users can
  understand and can provide feedback

22
Writing use cases

• Identify the Actors
• actor is external to the system
• identify actors first can help us to find the use
  cases
• Actors
• Borrower
• Librarian
• System administrator

23
Actor

• Primary actor - borrower
• The actor that the system is built for
• Use the primary actor to find the primary use
  cases
• Each complete course of events initiated by an
  actor is potentially a use case
• Secondary actor librarian, system administrator
• Not a primary actor because we would not need a
  librarian if there is no borrowers
• Iterative process
• Deal with the primary use cases first

24
Writing use cases

• Actor - Borrower
• Use case borrowing books
• This use case includes everything until all books
  are checked out
• Keep use case simple, factor out alternatives
• Alternative use case
• What if the borrowing limit is exceeded?
• Focus on the basic course first
• Deal with the alternative later

25
Use case model

• A use case model contains
• Use case diagram
• Use case description
• Use cases discovered in our first iteration
• User borrow copy of book
• User return copy of book

26
Use case diagram

• Record the information pictorially, in a use case

Borrow copy of a book
Borrower
Return copy of a book
27
Use case description

• Describe in active-voice English, pick the main
  success scenario
• Use case Borrow copy of book
• A Borrower presents a book.
• The system checks whether the borrower can borrow
  (borrower must be a member in the library, does
  not already have the maximum permitted number of
  books on loan, does not have overdue book, and
  does not have fine exceeded 100).
• If the checks succeed, the system records that
  this library member has this copy of the book on
  loan
• Extensions
• 3a The checks failed. Refuses the loan.

28
Writing use cases

• Use cases are strongly correlated with the user
  manual of the system
• Advice - write the user manual before the code !
• Prototyping
• Produce a rough user manual
• Discover all the basic courses of action
• Ignoring alternative courses (exceptions)

29
Writing use cases

• Screen mockups
• Make a draft screen design (GUI) and test it
  using the use cases
• windows navigation diagram
• showing how user can move from one window to next
• Mining legacy user manuals
• reengineer a legacy system, work from the user
  manual backward

30
Structure the use cases

• Structure use cases using UML stereotype ltlt. .
  .gtgt
• stereotype is a notation that allows developers
  to define non-standard relation
• ltltusegtgt or ltltincludegtgt
• sequences that are common to several use cases
• Analogous to delegation
• ltltextendgtgt
• To describe alternate (or exceptional) scenario
  based on certain condition
• Analogous to inheritance (specialization)

31
ltltusesgtgt

• The source use case makes use of the target use
  case

ltltusegtgt
Extend loan
Check for reservation
Borrower
Borrow copy of a book
ltltusegtgt
32
ltltextendgtgt

• New use case Refuse loan
• Main scenario borrows books
• The alternative scenario borrows books, but
  exceeds the limit the loan is refused

Refuse loan
ltltextendgtgt
Borrowing books
Borrower
33
Notes

• Use cases represent an external view of the
  system, it is not correlate with classes inside
  the system (although use cases can be used to
  discover classes)
• Keep the use case diagram simple the benefit of
  a complex structured diagram (ltltincludegtgt,
  ltltextendgtgt is not great in practice
• The use case text is more powerful
• Structuring Use Cases with Goals by Alistair
  Cockburn
• http//members.aol.com/acockburn/papers/usecases.h
  tm
• The Use Case Zone
• http//www.pols.co.uk/usecasezone/index.htm

34

• OOAD
• CRC

35
OOAD OO Analysis Design

• Analysis model the what
• A first-cut (draft) of the system
• Identify the core classes of the system
• what are the objects?
• what are the object functions?
• what are the interaction between objects?
• Not worry about implementation issues (e.g. what
  database to use, which platform, etc)
• How to model the system?

36
Procedural solution

• Structural programming
• Decomposed an application based on functionality
• Procedure usually has global knowledge

check-in
check-out
search
. . .
check fine
check borrow-ID
Data base
37
Why OO modeling is difficult

• The most difficult problem in teaching OO
  programming is getting the learner to give up the
  global knowledge of control that is possible with
  procedural programs, and rely on the local
  knowledge of objects to accomplish their tasks.
• Beck and Cunningham
• (A Laboratory for Teaching Object-Oriented
  Thinking)
• Local knowledge
• Object has limited knowledge, the knowledge is
  encapsulated

38
Object modeling

• Decompose an application based on objects

39
The main problem

• What are the objects?
• What are the objects responsibility?
• Your system is only as good as the objects you
  find

40
CRC (Class-Responsibility-Collaboration) cards

• A popular technique Beck and Cunningham for
  finding objects in a system
• The role of an object is identified by
• Class name
• A good name makes it easier to understand the
  model
• Responsibilities
• The problems to be solved by the class
• Collaboration
• Its relationship with other classes

41
CRC Cards

• Purpose
• A widely used technique in discovering the
  classes, their responsibility and collaborations
• Tool - the index card

42
A key feature of CRC

• Each card represents a class of objects
• Each participant has a number of cards
• Participants play a simulation game
• participants act as objects passing around
  messages
• Ref
• OOPSLA89 in http//c2.com/doc/index.html
• A Laboratory for Teaching Object-Oriented
  Thinking by Beck and Cunningham

43
A meeting with the participants

• Clients (Betty and Dewey)
• those who are familiar with the user requirements
• Betty - who wrote the system requirements
• Dewey - the librarian, whose work will be off-
  loaded by the system
• Developers (Cecilia and Jim)
• who will design and implement the system
• Facilitator (Nancy)
• object oriented expert

44
Goal To discover classes in the
application, form a glossary, use the glossary
to produce scenarios
45
How to find the classes

• Collect material
• From high-level problem statement
• Lower-level requirements
• Expert knowledge of the problem domain
• Everything, including marketing literature
• Highlight the nouns and verbs
• Nouns and nouns phrases become objects and
  attributes
• Verbs and verb phrases become operations and
  associations

46
How to find the classes

• Brainstorming
• Write down all names of classes suggested
• no criticism, filtering of the names will be done
  later
• people who know their application can usually
  come up with a fairly complete list of classes

47
How to find the classes

• Result
• Library, Librarian, User, Borrower, Student
  Member, Staff Member, Article, Material, Item,
  Due Date, Fine, Lendable, Book, Video, Journal
• Filtering classes
• eliminate redundancies
• identify missing abstraction
• recognize related classes

48
Filtering classes

• Give a short, precise meaning for each
  abstraction
• e.g. Book the set of objects that represent
  books to be borrowed from a library
• Informal discussion on the glossary
• Should User be included in the cards?
• User may be outside the scope of the model
• Difference between Library and Librarian?
• Librarian be the class that has overall
  responsibility for checking in and out library
  materials. Library will be reserved for the
  entire application

49
Recognize related classes

• Article, item, material and lendable
• refer to the same thing
• Use Lendable to describe item lent at a library
• Due Date and Fine - class or attribute?
• Due Date is probably an attribute of Lendable and
  Fine is an attribute of Borrower
• Perhaps need a Date class for due date
• If not sure about the answer, leave the class
  there
• Later on after executing scenarios, classes that
  have no responsibility will be discarded
  eventually

50
Classes remained after filtering

• After filtering
• Librarian, Lendable, Book, Video, Journal, Date,
  Borrower, and User
• Classes eliminated
• Library, Article, Material, Item, Due Date, Fine
• New class added
• Date
• 8 cards altogether
• analysis stage use 3 x 5 index cards
• design stage use 4 x 6 index cards

51
How to play the CRC card game

• Assigning cards to
• the person who suggested them
• those who knows the most about the abstraction
• e.g
• Betty Librarian
• Dewey Lendable
• Cecilia Borrower, User,
• Jim Book, Video, Journal, Date
• Write a short description of the class at the
  back of each card

52
Responsibilities (written at the back of the
card)

• Librarian
• The object in the system that fulfills User
  requests to check out, check in, and search for
  library material
• User
• The human being that comes to use the library
• Borrower
• The set of objects that represent Users who
  borrow items from the library
• Date
• The set of objects that represent dates in the
  system

53
Responsibilities (back of the card)

• Lendable
• The set of objects that represent items to be
  borrowed from the library
• Book
• The set of objects that represent books to be
  borrowed from the library
• Video
• The set of objects that represent videotapes to
  be borrowed from the library
• Journal
• The set of objects that represent technical
  journals to be borrowed from the library

54
Example of a CRC card
(back of card)
Librarian The object in the system
that fulfills User requests to check out, check
in, and search for library material
Librarian (class name)
subclasses
superclasses
responsibilities collaborators
55
Attributes

• Where are the attributes of the classes?
• not concern at this early stage
• more concern about the behavior of the objects
• only need to record down attributes if it is
  obvious
• write the attributes at the back of the cards
• Scenario walkthrough
• Scenarios are concrete instances of use cases
• Use case
• A Borrower presents a book. The system checks . .
  .
• Scenario
• Ricky presents the C Primer to the system, . . .
  

56
Ask the What happens when . . . question

• What happens when
• Ricky returns a video, C Primer, to the Library
• Scenarios should be very specific
• related scenarios should be modeled separately
• avoids branching questions, e.g.
• What if the video is overdue?

57
The simulation

• People who own particular CRC card should hold
  the card in the air and become the active object
  in the scenario
• When someone holds a card saying I need to do
  this (responsibility) and points at someone
  (collaborator) else saying I need you to do
  that, control is passed to the collaborating
  object
• Live prototype and simulation

58
Check-out scenario

• What happens when . . .
• Ricky, who has no accrued fines and one
  outstanding book, not overdue, checks out a book
  entitled C Primer?
• Who should have the overall responsibility for
  checking out Rickys book?
• Betty the librarian
• Group agree
• Betty wrote CheckOutBook in the responsibility
  column on her card (Librarian)

59
Check-out scenario

• Librarian
• How to handle this CheckOutBook responsibility?
• Who (collaborator) can help me?
• The Book ?
• Ask the Book to change its status to OUT
• But wait a minute, the Librarian should make sure
  that the borrower can borrow (i.e. doesnt have
  overdue books, too large a fine, or too many
  borrowed items)
• Who has the responsibility to know whether the
  person can borrow?

60
Check-out scenario

• The Librarian?
• Dont overload the Librarian. Avoid using a mega
  object knowing too much and doing too much
• Large object is hard to change its role is also
  not clear
• OO is about distributing the responsibilities to
  objects of suitable size
• The Borrower !
• Ricky should know how many books he has borrowed

61
So Betty (Librarian), starts the scenario as
follows

• Librarian
• I am the Librarian and CheckOutBook is my
  responsibility. I need to verify whether this
  user can borrow. I will collaborate with Borrower
  to do this. Borrower, lift your card up.
• Borrower
• I am adding CanBorrow on my card as the
  responsibility. I can use KnowFine responsibility
  to see that my fine is less than 100. I will use
  KnowSetOfBooks responsibility to see if I am over
  my lendable limit. Knowing that I have only one
  book out, I need to find out whether this book is
  overdue. Will you know that, Book?

62
Check-out scenario

• Book
• Ill add KnowDueDate as a responsibility. I will
  also add KnowIfOverdue. To do this, I need to
  collaborate with Date to compare todays date and
  due date
• Date
• Ill add CompareDates responsibility to my list.
  To compare, I need to collaborate with another
  instance of Date (todays date), so Ill add Date
  as my collaborator. In this case, todays date is
  less than due date, Book.
• Book
• Great. Borrower, I can tell you that I am not
  overdue
• Borrower
• OK. Librarian, the Borrower can borrow.

63
Check-out scenario

• Librarian
• OK. I now need to change the Books state to
  indicate that it is OUT
• Ill ask Book to
• set due date
• set out status
• record name of borrower
• Wait a minute . . .
• Need to collaborate with Book three times

64
Check-out scenario

• Jim
• Can the Book object just checks itself out
  instead of collaborate with the Librarian three
  times
• Librarian
• Book, if I tell you who the Borrower is, can you
  please check yourself out?
• Book
• Sure. Ill add CheckOut as my responsibility. I
  must know how to CalculateMyDueDate, and I need
  to KnowMyBorrower, KnowDueDate, and KnowInOrOut.
  I will add these as responsibilities. Done. Back
  Librarian .

65
Check-out scenario

• The difference between
• Librarian collaborates with Book 3 times
• Book checks itself out
• First approach has a higher degree of coupling
• Know too much about the internal state of Book
• Bad, against the principle of encapsulation
• Second approach has less coupling
• Changing Books internal state in future will not
  affect the way Librarian carries out her
  responsibilities

66
Check-out scenario

• Librarian finishes her CheckOutBook
  responsibility by telling Borrower to add the
  Book to her list
• Librarian
• Borrower, please add this book to your list
• Borrower
• I will add a responsibility to AddBook
• End of check out scenario

67
Librarian
check out book for User
Borrower, Book
Date
compare dates
Date
Borrow
can borrow
Book
know set of books
Book
know if overdue
Date
check out
calculate due date
know due date
know borrower
know in or out
68
What we have achieved

• Identify objects (classes) in the system
• Identify their responsibilities
• the behavior of the objects later becomes the
  functions of the objects
• Identify their collaboration
• Related scenarios
• repeat the check-out scenario with different
  variations
• e.g. what happens if Frank has a non-overdue book
  at home and what to check out a video
  Casablanca?

69
Frank checks out a video

• Librarian
• I have my card up. I have added the
  responsibility CheckOutVideo. I will verify that
  the Borrower doesnt have any overdue Lendables
  and is not at his lending limit. To do this, I
  collaborate with Borrower.
• Borrower
• I already have this responsibility CanBorrow on
  my card, so I dont have to add any new
  responsibility. The Borrower is OK.
• Librarian
• Now Video, like what I have done with Book
  before, if I tell you who the Borrower is, can
  you check yourself out?

70
Related scenarios

• Video
• Yes. Ill add check out to my card. I know how to
  CalculateDueDate (only 7 days) and I KnowDueDate,
  KnowBorrower, and KnowInOrOut, and I will
  collaborate with Date. OK, back to you,
  Librarian.
• Librarian
• Borrower, the sequence is same as CheckOutBook !
  I think it is better to change my responsibility
  to CheckOutLendable for all the landable items
• Borrower
• A good idea. I shall replace my KnowSetOfBooks to
  KnowSetOfLendables to make my responsibility more
  general

71
Related scenarios

• Group discussion
• Note the similarity in the two scenarios (check
  out book and check out video)
• check out
• know borrower
• know if overdue
• know due date
• know in or out
• except
• calculate due date

72
What it will be looked like in C

• class Lendable
• public virtual bool Checkout() ...
• public virtual Date KnowDueDate() ...
• public virtual bool KnowBorrower() ...
• public virtual bool KnowInOrOut() ...
• public virtual bool KnowIfOverdue() ...
• public abstract double CalculateDueDate()
• class Book Lendable
• public override double CalculateDueDate() ...

73
Collaboration drawings

• Repeat the scenario walkthrough for other use
  cases
• Discover more classes and responsibility until
  you have a stable model
• Visualize the object relations
• Put the cards on the white board
• Link the pattern to see how the objects
  participated in the application
• Spot any spaghetti code
• The drawing becomes the analysis class diagram

74
Collaboration drawings
UI
DB
Collection
Library
Lendable
Borrower
Date
75
Class diagram
checkout checkin search
Borrower
UI
Library
collection
Lendable
Date
Book
Video
Journal
76
Advantages of CRC cards

• Live prototyping
• Identifying holes in requirements
• Common project vocabulary
• Group effort in identifying the classes and
  responsibilities
• Spreading domain knowledge
• Domain experts participate directly
• Making the paradigm shift
• Internalization of participants through role
  playing

77
CRC cards after analysis session
Collaborators
Responsibility
Librarian check out Lendable
Lendable, Borrower check in
Lendable
Lendable, Borrower search for Lendable
Collection get info
from user
UI Subsystem display message
UI Subsystem Collection
know set of Lendables
DB Subsystem, Lendables Borrower can
borrow
Lendable know set of Lendables know
fine amount
78
CRC cards after analysis session
Date compare dates
Date add days to
date Lendable subclasses Book, Video,
Journal calculate due date
Date calculate
fine check out
Date check in know
due date know borrower know in or out know if
overdue
Date
79
CRC cards after analysis session
Book superclass Lendable calculate due date

Date calculate fine Video superclass
Lendable calculate due date
Date calculate
fine Journal superclass Lendable calculate due
date
Date calculate fine
80

• Borrower can be a staff or a student
• Staff can borrow more books, has more privilege,
  and pays heavier overdue fine
• How to model this relationship?
• Inheritance or composition?

Borrower
Status
Borrower
Student
Student
Teacher
Teacher
81

• When to use inheritance
• To model is-a relation
• A staff is-a kind of borrower
• Problems with inheritance
• Superclass is fragile
• Subclass is rigid
• Ask what if question
• What if a student working part-time for the
  library, and has the status of a staff?
• Perhaps different class of borrowing right?
• Dont what to create new class (need
  recompilation!)

82
A possible solution

• Role
• Model the status by role
• Role-based access control
• Common in commercial packages

Borrower
Role
Rule
83
From analysis to design

• OO Analysis (OOA)
• Pay no attention to hardware/software platform,
  the database used, and the GUI required
• OO Design (OOD)
• Include real-world constraints, such as
• Target environment (UNIX/PC?)
• Language
• User interface (X-window/Windows ?)
• Database management (Oracle/MySQL?)
• Class libraries, software components
• Performance requirements

84
Design model

• Continuous refinement of classes
• Add and refine classes, responsibilities, and
  collaborations up to implementation level
• UI
• Keep the GUI subsystem as separate as possible
• Add new class UI to serve as a layer that
  separate the application and the GUI
• DB
• like UI, to separate the application from
  DBMS-specific calls

85
Design model

• Object creation scenarios
• Who is responsible in creating/destroying the
  object?
• What is the lifetime of the object?
• e.g. Librarian and DB classes
• A single object that lasted for the whole
  duration of the application process
• e.g. objects like Borrowers and Lendable
• created and destroyed more dynamically

86
Start-up scenario

• Create a DB object
• Only need one object for the system
• Created by the Library application at system
  start up
• Lifetime of the object lasted for the entire
  process
• DB established a connection to the DBMS as it is
  created, and closed it when it is destroyed
• Add CreateConnection responsibility in the DB
  card and write DBMS as the collaborator

87
Start-up scenario

• Librarian
• Wait for user request
• Add WaitForUser responsibility, collaborate with
  UI, because the UI has the responsibility to get
  the borrowers Id
• UI
• Add GetBorrowerId as a responsibility

88
main

• static DB db //static object
• void main()
• Librarian betty new Librarian()
• betty.WaitForUser() //pass control to UI, wait

89
Check-out scenario at design level

• Design level scenario
• Frank has no fine and one non-overdue book at
  home, want to check out a book called C Primer
• Librarian
• Wait for user to log in
• Collaborate with UI to get the Users Id
• UIs GetBorrowerId responsibility will handle
  users input, get the Id, and pass to Librarian
• UI
• Collaborate with the C Form classes to capture
  user input

90
Check-out scenario

• Librarian
• Frank enters his Id, I will collaborate with DB
  to create the Borrower object for Frank, who
  becomes my current Borrower
• Cecilia (the developer)
• Wait! The Librarian should verify whether Franks
  Id is correct first, before he can be the current
  borrower
• Nancy (the OO expert)
• Dont overload the Librarian. It is becoming like
  a monolithic block of code. Better use a separate
  class called IdVerifier
• The goal of OO design is to spread the knowledge
  and responsibility

91

• Librarian
• OK, before I get a Borrower object, I collaborate
  with IdVerifier to verify the Id
• IdVerifier
• I must have a Verify responsibility. I probably
  look in the current employee database table.
  Cecilia, you should add an Employee table to the
  database. Anyway, I found Frank
• Librarian
• Good. Now I can collaborate with DB to get a
  Borrower Object using the employee Id
• DB
• I use my GetBorrower responsibility, in which I
  get data from the DBMS and then use it to Create
  Borrower

92
Check-out scenario

• Borrower
• As I create myself, I need to create my set of
  previously borrowed Lendable objects. Perhaps I
  will just create an empty set and DB will pass me
  the actual Lendable to put on it.
• DB
• The Borrower table in the database will have the
  Id of the Lendable . So I use these Id and my Get
  Lendable responsibility to get data from the DBMS
  and to create Lendable. Actually, I create a Book
  object in this case (the book borrowed by Frank),
  which I can give to Borrower to add to her set
  using AddLendable responsibility

93
Check-out scenario

• Borrower
• I have an AddLendable responsibility, which I
  will add the Lendable to a container called
  Collection. I shall also have a DeleteLendable, a
  GetLendable, and a NumberOfLendables
  responsibilities
• DB
• I will use Borrowers AddLendable for each of the
  Lendable I found from database, then I can return
  the Borrower object to Librarian
• Librarian
• I now have the Borrower object. Ill ask Borrower
  to check whether it can borrow from the library.
  If it is OK, then I must use UI to get users
  choice, . . .

94
Check-out scenario

• Repeat the scenarios, refine the class diagram
  and the interaction diagram, try to develop a
  small prototype in C code, see how the system
  works, shows the prototype to users, . . .
• Iterative and incremental process
• Each CRC design class maps to a C class

95
Design model vs analysis model

• Analysis model
• conceptual model
• generic, applicable to many designs
• less expensive to develop
• outlines the design
• may not be maintained throughout the software
  life cycle

• Design model
• physical model
• not generic, specific to an implementation
• more expensive to develop
• manifests the design
• should be maintained throughout the software life
  cycle

96
Implementation model

• one-to-one mapping from design classes to code
• Traceability - dependency between the models can
  easily be traced

Design Model Implementation Model
ltltfilegtgt
ltltfilegtgt
interface
97
Artifacts from each stage
Design model Refined Use case model Refined int
eraction diagram refined class diagram source
code
Analysis model Refined Use case
model sequence diagram class diagram
Requirement model Use case model Glossary
98
Case tools

• Code generation
• Generate C/Java/C code from UML class diagrams
• Reverse engineering
• Turn C/Java/C code into UML class diagrams
• Round-trip engineering
• Generate C code from UML class diagrams
• Edit the C source code, compile and run
• Update the UML class diagrams by reverse
  engineering
• Repeat the iterations

99
Reading list

• A Laboratory for Teaching Object-Oriented
  Thinking by Beck and Cunningham (on CRC cards)
• c2.com/doc/index.html
• UML resources (contains references to tutorials
  on UML)
• www.omg.org
• Using the IBM RUP for small project Gary
  Pollice
• www3.software.ibm.com/ibmdl/pub/software/rational/
  web/whitepapers/2003/tp183.pdf
• A simplified approach to RUP Gary Evans
• www-106.ibm.com/developerworks/rational/library/35
  4.html
• dX A minimal RUP process Martin, Booch,
  Newkirk
• www.objectmentor.com/publications/RUPvsXP.pdf
• Extreme Programming (XP)
• www.serverworldmagazine.com/webpapers/2002/01_kanb
  ay.shtml
• A good introduction to XP
• www.extremeprogramming.org
• A Comparison of the IBM RUP and XP John Smith
• www3.software.ibm.com/ibmdl/pub/software/rational/
  web/whitepapers/2003/TP167.pdf