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)

Department of Information Engineering 2

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

Department of Information Engineering 3

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?

Department of Information Engineering 4

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

Department of Information Engineering 5

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

Department of Information Engineering 6

Traditional software development approach
• Waterfall model

Requirement
definition

System and
software design

Implementation
and unit testing

Integration and
system testing

Operation and
maintenance

Department of Information Engineering 7

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

Department of Information Engineering 8

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

Department of Information Engineering 9

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

Department of Information Engineering 10

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

Department of Information Engineering 11

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

Department of Information Engineering 12

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

Department of Information Engineering 13

 USER PROGRAMMER
Business Knowledge Programming Knowledge

Project Manager

Department of Information Engineering 14

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
Department of Information Engineering 15
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.
Department of Information Engineering 16
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

Department of Information Engineering 17

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

Department of Information Engineering 18

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

Department of Information Engineering 19

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

Department of Information Engineering 20

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

Department of Information Engineering 21

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

Department of Information Engineering 22

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
Department of Information Engineering 23
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

Department of Information Engineering 24

Use case diagram
• Record the information pictorially, in a use case

Borrow copy of a book

User
Return copy of a book

Department of Information Engineering 25

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.
Department of Information Engineering 26
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)

Department of Information Engineering 27

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

Department of Information Engineering 28

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)

Department of Information Engineering 29

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

Department of Information Engineering 30

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

Department of Information Engineering 31

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
Department of Information Engineering 32
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?

Department of Information Engineering 33

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

check­out search check­in

check borrow­ID check fine .  .  .

Data base

Department of Information Engineering 34

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

Department of Information Engineering 35

Object modeling
• Decompose an application based on objects

Department of Information Engineering 36

The main problem

• How are the objects?

• What are the objects’ responsibility?

• Your system is only as good as the

objects you find

Department of Information Engineering 37

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

Department of Information Engineering 38

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

Department of Information Engineering 39

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

Department of Information Engineering 40

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

Department of Information Engineering 41

 Goal

To discover classes in the application,

form a glossary,

use the glossary to produce scenarios

Department of Information Engineering 42

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
Department of Information Engineering 43
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

Department of Information Engineering 44

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

Department of Information Engineering 45

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

Department of Information Engineering 46

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

Department of Information Engineering 47

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

Department of Information Engineering 48

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
Department of Information Engineering 49
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

Department of Information Engineering 50

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

Department of Information Engineering 51

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

Department of Information Engineering 52

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, . . .
Department of Information Engineering 53
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?”

Department of Information Engineering 54

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

Department of Information Engineering 55

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)

Department of Information Engineering 56

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?
Department of Information Engineering 57
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

Department of Information Engineering 58

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?
Department of Information Engineering 59
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.
Department of Information Engineering 60
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

Department of Information Engineering 61

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 .

Department of Information Engineering 62

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

Department of Information Engineering 63

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

Department of Information Engineering 64

 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
Department of Information Engineering 65
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”?

Department of Information Engineering 66

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?
Department of Information Engineering 67
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
Department of Information Engineering 68
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

Department of Information Engineering 69

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

Department of Information Engineering 70

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

Department of Information Engineering 71

Collaboration drawings

UI
DB

Collection
Library

Lendable
Borrower Date

Department of Information Engineering 72

Class diagram

checkout
checkin
search
UI Library Borrower

collection

Lendable Date

Book Video Journal

Department of Information Engineering 73

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

Department of Information Engineering 74

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
Department of Information Engineering 75
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

Department of Information Engineering 76

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
Department of Information Engineering 77
• 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

Department of Information Engineering 78

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

Department of Information Engineering 79

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

Department of Information Engineering 80

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
Department of Information Engineering 81
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

Department of Information Engineering 82

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

Department of Information Engineering 83

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

Department of Information Engineering 84

main

static DB db; //static object

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

Department of Information Engineering 85

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

Department of Information Engineering 86

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
Department of Information Engineering 87
• 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
Department of Information Engineering 88
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

Department of Information Engineering 89

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

Department of Information Engineering 90

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

Department of Information Engineering 91

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

Department of Information Engineering 92

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
Department of Information Engineering 93
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

Department of Information Engineering 94

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
Department of Information Engineering 95
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
Department of Information Engineering 96