Scenario To Calculate Due Date Fine of A Library System

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?
Department of Information Engineering 1
Methodology
• Ask 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)

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

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?

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

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
developer’s viewpoint, using developer’s language
– Too technical, users can’t understand it

Traditional software development approach
• Waterfall model
Requirement
definition
System and
software design
Implementation
and unit testing
Integration and
system testing
Operation and
maintenance

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

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

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

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

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

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

USER PROGRAMMER
Business Knowledge Programming Knowledge
Project Manager

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
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 can lend 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.
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

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

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

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

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

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

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
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

Use case diagram
• Record the information pictorially, in a use case
Borrow copy of a book
User
Return copy of a book

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.
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)

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

Structure the use cases
• Structure use cases using UML stereotype <<. . .>>
– stereotype is a notation that allows developers to
define non-standard relation
– <<use>> or <<include>>
• sequences that are common to several use cases
• Analogous to delegation
– <<extend>>
• To describe alternate (or exceptional) scenario
based on certain condition
• Analogous to inheritance (specialization)

<<uses>>
• The source use case makes use of the target use case
Extend loan <<use>>
Check for
Borrower reservation
Borrow copy
<<use>>
of a book

<<extend>>
• New use case: Refuse loan

– Main scenario: borrows books
– The alternative scenario: borrows books, but exceeds
the limit; the loan is refused
Refuse loan
Borrowing books <<extend>>
Borrower

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 (<<include>>, <<extend>>
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.htm
• The Use Case Zone
– http://www.pols.co.uk/usecasezone/index.htm
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?

Procedural solution
• Structural programming
– Decomposed an application based on functionality
– Procedure usually has global knowledge
checkout search checkin
check borrowID check fine . . .
Data base

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

Object modeling
• Decompose an application based on objects

The main problem
• How are the objects?
• What are the objects’ responsibility?
• Your system is only as good as the

objects you find

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

CRC Cards
• Purpose
– A widely used technique in discovering the classes,
their responsibility and collaborations
• Tool - the index card
class name
subclasses:
superclasses:
responsibilities collaborators

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
– OOPSLA`89 in http://c2.com/doc/index.html
• A Laboratory for Teaching Object-Oriented
Thinking by Beck and Cunningham

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

Goal
To discover classes in the application,
form a glossary,
use the glossary to produce scenarios

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
• 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

• 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

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

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

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

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
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

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
• Video
– The set of objects that represent videotapes to be
• Journal
– The set of objects that represent technical journals
to be borrowed from the library

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

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, . . .
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?”

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

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 Ricky’s book?
– Betty: the librarian
– Group: agree
• Betty wrote CheckOutBook in the responsibility

column on her card (Librarian)

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. doesn’t have overdue
books, too large a fine, or too many borrowed items)
• Who has the responsibility to know whether the person

can borrow?
Check-out scenario
• The Librarian?
– Don’t 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

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?
Check-out scenario
• Book
– I’ll add KnowDueDate as a responsibility. I will also
add KnowIfOverdue. To do this, I need to collaborate
with Date to compare today’s date and due date
• Date
– I’ll add CompareDates responsibility to my list. To
compare, I need to collaborate with another instance
of Date (today’s date), so I’ll add Date as my
collaborator. In this case, today’s 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.
Check-out scenario
• Librarian
– OK. I now need to change the Book’s state to indicate
that it is OUT
– I’ll ask Book to
• set due date
• set out status
• record name of borrower
• Wait a minute . . .
– Need to collaborate with Book three times

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. I’ll 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 .

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 Book’s internal state in future will not
affect the way Librarian carries out her
responsibilities

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

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
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”?

Frank checks out a video
• Librarian
– I have my card up. I have added the responsibility
CheckOutVideo. I will verify that the Borrower doesn’t
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 don’t 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?
Related scenarios
• Video
– Yes. I’ll 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
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

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() {...}
}

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

Collaboration drawings
UI
DB
Collection
Library
Lendable
Borrower Date

Class diagram
checkout
checkin
search
UI Library Borrower
collection
Lendable Date
Book Video Journal

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

CRC cards after analysis session
Responsibility Collaborators
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
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

Book
superclass: Lendable
calculate fine
Video
calculate fine
Journal
calculate fine
• 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 Borrower Status
Teacher Student Teacher Student

• 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?

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

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
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

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

Start-up scenario
• Librarian
– Wait for user request
– Add WaitForUser responsibility, collaborate with
UI, because the UI has the responsibility to get the
borrower’s Id
• UI
– Add GetBorrowerId as a responsibility

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

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 User’s Id
– UI’s GetBorrowerId responsibility will handle user’s
input, get the Id, and pass to Librarian
• UI
– Collaborate with the C# Form classes to capture
user input

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 Frank’s
Id is correct first, before he can be the current
borrower
• Nancy (the OO expert)
– Don’t 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
• 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
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

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 Borrower’s 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. I’ll ask Borrower to
check whether it can borrow from the library. If it is
OK, then I must use UI to get user’s choice, . . .

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

Design model vs analysis model
• Analysis model • Design model
• conceptual model • physical model

• generic, applicable to • not generic, specific to
many designs an implementation
• less expensive to develop • more expensive to
• outlines the design develop
• may not be maintained • manifests the design
throughout the software • should be maintained
life cycle throughout the software
life cycle

Implementation model
• one-to-one mapping from design classes to code
• Traceability - dependency between the models can
easily be traced
Design Model Implementation Model
<<file>>
<<file>>
interface
Artifacts from each stage
Requirement Analysis Design

model model model
Use case Refined Use Refined Use

model case model case model
Refined
interaction
sequence diagram
diagram
Glossary class diagram refined class
diagram
source code

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
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/2
003/tp183.pdf
• A simplified approach to RUP – Gary Evans
– www-106.ibm.com/developerworks/rational/library/354.html
• dX: A minimal RUP process – Martin, Booch, Newkirk
– www.objectmentor.com/publications/RUPvsXP.pdf
• Extreme Programming (XP)
– www.serverworldmagazine.com/webpapers/2002/01_kanbay.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/2
003/TP167.pdf

Scenario To Calculate Due Date Fine of A Library System

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Scenario To Calculate Due Date Fine of A Library System

Uploaded by

Copyright:

Available Formats

Overview of software development

• How to deal with these problems?

Department of Information Engineering 2

Department of Information Engineering 3

• What is wrong? What is the biggest risk?

Department of Information Engineering 4

• How is this possible?

Department of Information Engineering 5

Department of Information Engineering 6

Department of Information Engineering 7

Department of Information Engineering 8

Department of Information Engineering 9

Use Cases Model

Find core classes from use cases

Refine the analysis model

Turn class diagram into code

Do the testing based on use cases

Department of Information Engineering 10

• Add a second use case

Department of Information Engineering 11

• Your task is to build an interactive system which

Department of Information Engineering 12

• The difficulty in formulating the requirements

Department of Information Engineering 13

Department of Information Engineering 14

• A meeting between domain experts (the librarian), the

• Purpose of the meeting

• This application will support the operations of library

Department of Information Engineering 17

– use cases are written using the language of the users

– A complete set of use-case descriptions specifies the

Department of Information Engineering 18

• A use case is a set of scenarios tied together by a

Department of Information Engineering 19

• Use cases approach

Department of Information Engineering 20

Department of Information Engineering 21

• Secondary actor – librarian, system administrator

Department of Information Engineering 22

• Use case: borrowing books

• Alternative use case

• Focus on the basic course first

• Use cases discovered in our first iteration

Department of Information Engineering 24

Department of Information Engineering 25

Department of Information Engineering 27

• Mining legacy user manuals

Department of Information Engineering 28

Department of Information Engineering 29

Department of Information Engineering 30

• New use case: Refuse loan

Department of Information Engineering 31

• Structuring Use Cases with Goals by Alistair Cockburn

• How to model the system?

Department of Information Engineering 33

check­out search check­in

check borrow­ID check fine . . .

Department of Information Engineering 34

Beck and Cunningham

Department of Information Engineering 35

Department of Information Engineering 36

• How are the objects?

checkout search checkin

check borrowID check fine . . .