LESSON 7: INTRODUCTION TO UNIFIED MODELLING LANGUAGE (UML)

1. Whats a model and a diagram?

A model is an abstract representation of a system, constructed to understand the system prior
to building or modifying it
Most modelling techniques used involve graphic languages
A useful model has the right level of detail and represent only what is important for the task in
hand.
Many things can be modelled such as traffic flow, bridges, etc.
A diagram illustrates some aspect of a system and provides a complete view of a system at a
particular stage and from a particular perspective.
A model may consist of many related diagrams with supporting data and documentation.
2. Why Modelling?
Models make it easier to express complex ideas
Reduction of complexity. Models reduce complexity by separating those aspects that are
unimportant from those that are important. This makes complex situations easier to understand
Models enhance and reinforce learning and training
The cost of modelling analysis is much lower than the cost of similar experimentation conducted
with a real system
Manipulation of the model (changing variables) is much easier than manipulating the real system

3.

Interesting information about modelling

A model is rarely correct on the first try
Always seek advice and criticism of others.
A model design could be improved by taking into consideration different perspectives
Avoid excess model revisions, as they can distort the essence of the model.

4.

Static Model
Can be viewed as a snapshot of a systems parameters at rest or at a specific point in time
Static models are needed to represent the structures or static aspect of a system
Static models assume stability and an absence of change in data over time

5. Types of models
Use-case model defines the outside and inside of the systems behaviour
Domain object model objects of the real world are mapped into the domain object model
Analysis object model presents how the source code should be carried out and written
Implementation model represents the implementation of the system
Test model constitutes the test plans, specifications and reports.
6. Dynamic Diagram
Viewed as a collection of procedures or behaviours that, taken together, reflect the behaviour of a
system over time
Dynamic relationships show how the business objects interact to perform tasks

7.

Whats UML?
UML: Unified Modelling Language
Consist of a number of graphical elements to form diagrams.
It enables system builders to create blueprints that capture their visions in a standard, easy to
understand way and provides a mechanism to effectively share and communicate these designs
with others.

IS 131

Page 1 of 2

LESSON 7: INTRODUCTION TO UNIFIED MODELLING LANGUAGE (UML)

8. Primary Goals in the design of UML

Provide users a ready-to-use, expressive visual modelling language
Be independent of particular programming languages and development processes
Provide a formal basis for understanding the modelling language
Encourage the growth of the OO tools market
Support higher-level development concepts
Integrate best practices and methodologies
9. UML Diagrams
Static Diagram
Class Diagram
Use Case Diagram
Behaviour Diagram
Dynamic Diagram
Interaction Diagram
Sequence Diagram
Collaboration Diagram
Statechart Diagram
Activity Diagram
Implementation Diagram
Component Diagram
Deployment Diagram

IS 131

Page 2 of 2

LESSON 8: USE CASE DIAGRAMS

1. Identifying Actors
Whats an Actor?

An actor is a role that a user plays with respect to the system

A user may also play more than one role
Actors carry out use cases
A single actor may perform many use cases and a use case may have several actors
performing it
Actors dont need to be human as an actor can also be an external system that needs some
information from the current system
Actors are being identified to assist in the process of coming out with use cases

Useful Questions asked to identify actors

Who is using the system? Who is affected by the system? Which groups need help from the
system to perform a task?
Who affects the system? Which user groups are needed by the system to perform its
functions?
Which external hardware or other systems (if any) use the system to perform tasks?
What problems does this application solve (for whom)?
How do users use the system (use case)? What are they doing with the system?

2. Finding Use Cases

Whats a scenario?

It is a sequence of steps describing an interaction between a user and a system

Whats a Use case?

It is a set of scenarios tied together by a common user goal

Use case has a common all-goes-well case, and many alternatives that may include things
going wrong and also alternative ways that things go well

Guidelines for finding Use cases

For each actor, find the tasks and functions that the actor should be able to perform or that the
system needs the actor to perform. The use case should represent a course of events that
leads to a clear goal
Name the use cases
Use case name should provide a general description of the use case function
The name should express what happens when an instance of the use case is performed
The name should be active, expressed in the form of a verb (Borrow) or verb and noun
(Borrow Books)
Describe the use cases briefly by applying terms with which the user is familiar

3. Dividing Use Cases into packages

Each case represents a particular scenario in the system

Use case can be modelled to show how the system currently works or how it could work in the
future
Use cases would have to be broken down into several smaller packages (subsystems) for
better control

IS 131

Page 1 of 5

LESSON 8: USE CASE DIAGRAMS

4. Use Case Relationships

<<Include>> Relationship

Occurs when theres a chunk of behaviour that is similar across more than one use case
This is used to avoid describing the same behaviours over and over again
This behaviour would be extracted and be treated as a separate use case which could be
used by other use cases
This helps to avoid redundancy by allowing a use case to be shared (e.g. a bit like the
inheritance concept)

<<Extend>> Relationship

This relationship materialises when there is one use case which is very similar to another use
case but does a bit more or is a bit more specialised (e.g. like the subclass concept)
This is used to capture alternative scenarios

5. Documents to be delivered
Activity Diagram

A simple flowchart that could be used to find out what are the major requirements set by the
customer (general)
The same technique could also be used to identify the detailed operations of each individual
use cases (this could assist in the documentation of use cases later on)

Requirements List

No
1.

Includes a column to show which use cases provide the functionality of each requirement
Example:
Requirement
Use Case(s)
To record names, address and contact details for each Add a new client
client
To calculate the annual bonuses for all staff
Calculate
staff
bonuses

2.

Actors
Actor
Customer

Staff

IS 131

Description
The accountant works in the Accounts Department and is responsible for
the major re-sourcing issues for campaigns including staffing and related
financial matters
Any member of staff in the company

Page 2 of 5

LESSON 8: USE CASE DIAGRAMS

Use Cases
Use Case
Add a new client

Calculate
bonuses

Description
When the company obtains a new client, the full details of the
client are entered. Typically this will because of a new
campaign, and therefore the new campaign would be added
straight away.
staff At the end of each month, staff bonuses are calculated. This
involves calculating the bonus due on each campaign a member
of staff is working on. These are summed to give the total staff
bonus.

Detailed Use Case Report (for each individual use case)

Use Case Name
Actor
Description

Normal Course

Add a new client

Campaign Manager
When the company obtains a new client, the full details of the
client are entered. Typically this will because of a new
campaign, and therefore the new campaign would be added
straight away.
1. Client completed the form with the necessary information
2. Clerk entered all information presented into the system

Alternative
of actions

3. System presents entered information for verification

purposes
4. Clerk verifies information and the clients information is
stored in the database
course 4a. Incorrect information
The clerk would be permitted to make modifications
4b. Incomplete information
The clerk would be able to enter the missing information
should the information be provided by the client initially

IS 131

Page 3 of 5

LESSON 8: USE CASE DIAGRAMS

6. Sample Use Case Diagram (Simple)

Add a new campaign

Record completion of
a campaign
Assign a Staff
Contact
Campaign
Manager
Record a client
payment

Check campaign
budget

Use case diagram for Campaign Management

Add a new Client

Assign staff to work

on campaign

Campaign
Manager

Add a new advert to a

campaign
Staff Contact
Change a client
contact
Record completion of
advert
Use case diagram for Campaign Advertisement

IS 131

Page 4 of 5

LESSON 8: USE CASE DIAGRAMS

7. Sample Use Case Model with <<extend>> and <<include>> relationships

Add a new Client

Assign staff to work

on campaign

Find campaign

<<include>>
<<include>>
Add a new advert to a
campaign
Campaign
Manager

Check campaign
budget

<<extend>>
Print campaign
summary
Use case diagrams for Campaign Management in detail

8. What do you learn from this lessons discussion?

9. Reference Materials:
Object-oriented Systems Development using the Unified Modelling Language (Ali
Bahrami)
Chapter 6: Object-oriented Analysis Process: Identifying Use Cases
Object-oriented Systems Analysis & Design Using UML (Bernett, McRobb & Farmer)
Chapter 6: Requirements Capture
UML Distilled Second Edition: A Brief Guide to the Standard Object Modelling
Language (Martin Fowler with Kendall Scott)
Chapter 3: Use Cases
Using UML: Software Engineering With Objects and Components (Perdita Stevens
with Rob Pooley)
Chapter 7: Essentials of Use case models
Chapter 8: More on use case models
Systems Analysis and Design Methods (Jeffrey L. Whitten & Lonnie D. Bentley)
Chapter 8: Object Modelling
IS 131

Page 5 of 5

Include Relationship
A use case includes the functionality described in the other use case as a part of its business
process flow.
The tip of the arrowhead points to the parent use case and the child use case is connected at
the base of the arrow.
The use case which is using the other use case is not complete without it
Apply <<include>> When You Know Exactly When To Invoke The Use Case

Extend Relationship
The child use case adds to the existing functionality and characteristics of the parent use case.
The tip of the arrowhead points to the parent use case and the child use case is connected at
the base of the arrow.
An extended use case is a valid use case by itself
Apply <<extend>> When A Use Case May Be Invoked Across Several Use Case Steps

Dos and Don'ts

Use cases should not be used to capture all the details of a system.
The use cases diagram should be uncluttered and readable, yet, be complete without missing
significant aspects of the required functionality.
Use cases are meant to capture "what" the system is

Reference
Creating Use Case Diagrams http://www.developer.com/design/print.php/10925_2109801_2

LESSON 9: INTERACTION DIAGRAMS

1. Interaction Diagrams

Models that describe how groups of objects collaborate in some behaviour.

Captures the behaviour of a single use case
2 types: sequence diagram and interaction diagram
The process of creating sequence or collaboration diagrams is a systematic way to think about
how a use case can take place; and by doing so, helps the identification of objects

2. Sequence Diagram

Object is shown as a box at the top of a dashed vertical line

The vertical line is called the objects lifeline, which represents the objects life during the
interaction
Each message is represented by an arrow between the lifelines of 2 objects
The order in which these messages occur is shown top to bottom
Each message is labelled at minimum with the message name; arguments and some control
information could also be included
Self-call is a message that an object sends to itself, by sending the message arrow back to the
same lifeline

3. Collaboration Diagram

Sequence of the messages is indicated by numbering the messages

The spatial layout eases the presentation of information (e.g. how the objects are linked together)

4. Sequence Diagram Vs Collaboration Diagram

Sequence diagram emphasises on the sequence (easy to see the order in which things occur)
Collaboration diagrams indicates how objects are statically connected
Simplicity is the key feature for both the sequence and collaboration diagrams
These diagrams are not suitable when there is a need to represent something more than a single
sequential process
One of the problems with the interaction diagrams is that they can be awkward to use when
exploring alternatives

5. Example of Sequence Diagram

:Club Member

:Member System

:Member

Ask for Member ID

Enter Member ID
Verify Member Status
Found Member Status
Request for next transaction

IS 131

Page 1 of 2

LESSON 9: INTERACTION DIAGRAMS

6. Example of Collaboration Diagram
:Club Member
1: Ask for Member ID
2: Enter Member ID
5: Request for next transaction

:Member System
3: Verify Member Status

4: Found Member Status

:Member

7. Reference Materials:

Object-oriented Systems Development using the Unified Modelling Language (Ali Bahrami)
Chapter 7: Object Analysis: Classification

UML Distilled Second Edition: A Brief Guide to the Standard Object Modelling Language (Martin
Fowler with Kendall Scott)
Chapter 5: Interaction Diagrams

IS 131

Page 2 of 2

LESSON 10: ACTIVITY DIAGRAMS

1. Activity Diagram
Describes the sequencing of activities with support for both conditional and parallel behaviour
Conditional behaviour is delineated by branches and merges

Branch
A branch has a single incoming transition and several guarded outgoing transitions
Only one outgoing transition can be taken, so the alternatives should be mutually exclusive

Merge
Has multiple input transitions and a single output
Marks the end of the conditional behaviour started by a branch
Parallel behaviour is indicated by forks and joins
Forks
Has one incoming transition and several outgoing transitions
When the incoming transition is triggered, all the outgoing transitions are taken in parallel

Joins
Has multiple incoming transitions and only one outgoing transition

Note:
Forks and joins must match

2. Reference Materials:
Object-oriented Systems Development using the Unified Modelling Language (Ali Bahrami)
Chapter 5: Unified Modelling Language
UML Distilled Second Edition: A Brief Guide to the Standard Object Modelling Language (Martin
Fowler with Kendall Scott)
Chapter 9: Activity Diagram
3. Example of an Activity Diagram

IS 131

Page 1 of 1

LESSON 11: CLASS DIAGRAMS

1. UML Class Diagram
It is a collection of static modelling elements, such as classes and their relationships,
connected as a graph to each other and to their contents
Class diagram does not show temporal information
It is also referred to as object modelling
Object modelling is the process by which the logical objects in the real world are represented
by the actual objects in the program
The main task of object modelling is to graphically show what each object will do in the
problem domain, describe the structure and the relationships among objects by visual notation
and determine what behaviours fall within and outside the problem domain
The visual representation of the objects, their relationships and their structures is for ease of
understanding
To be able to come out with a good model of the real world and the objects needed to model
the system, the following questions had to be answered:
What are the goals of the system?
What must the system accomplish?
2. Class Notation
A class is drawn as a rectangle with 3 components separated by horizontal lines
The top name compartment holds the class name
The middle compartment holds general properties of the class, such as attributes
The bottom compartment holds a list of operations
Either or both the attribute and operation compartment may be suppressed
3. Object Diagram
It is an instance of a class diagram
It shows a snapshot of the detailed state of the system at a point of time
Notation is the same for an object diagram and a class diagram
4. Operations
A description/behaviour of a class. Things the class can do.
You can refer to the sequence/collaboration diagram for details of the operations
5. Attributes.
Characteristics of the object
e.g. person object has attributes like name, age, sex. etc.
6. Association
A association is a logical connection between 2 or more objects
The end of an association where it connects to a class shows the association role, which is
part of the association and not part of the class.
7. Multiplicity
Association have multiplicity (range of permitted cardinalities of an association)
Cardinality specifies how many instances of one class may relate to a single instance of an
associated class.
It has a Lower bound. Upper bound value.

IS 131

Page 1 of 4

LESSON 11: CLASS DIAGRAMS

8. Compositions and Aggregation.
Aggregation is essentially any whole part relationship
A hollow diamond is attached to the end of the path to indicate aggregation
Aggregation represents the situation where a class consist of several component classes,
which behaves very differently.
Composition refer to as part-whole relationship
The UML notation for composition is a solid diamond at the end of the path
Composition is stronger as each part may belong to only one whole at a time. When the whole
is destroyed, so are all its parts.
9. Generalisation
It is the relationship between a more general class and a more specific class
Generalisation is displayed as a directed line with a closed, hollow arrowhead at the super-class
end
Ellipses () indicate that the generalisation is incomplete and more subclasses exist that are not
shown
All subclasses share given properties

10. Guidelines for identifying Super-sub class relationships

Top down: Look for noun phrases composed of various adjectives in the class name
Bottom up: Look for classes with similar attributes or methods. In most cases, common attributes
and methods could be moved to an abstract class
Reusability: Move attributes and behaviours as high as possible in the hierarchy
Multiple inheritance: Avoid excessive use of multiple inheritance

1. Class Diagram
Describes the types of objects in the system and the various kinds of static relationships that exist
among them
Shows the attributes and operations of a class and the constraints that apply to the way objects
are connected
2. Associations
Represents the relationships between instances of classes
Each association has 2 association ends; each end is attached to one of the classes in the
association
And end can be explicitly names with a label; this label is called role name
Multiplicity is an indication of how many objects may participate in the given relationship
Guidelines for identifying associations

A dependency between 2 or more classes may be an association. Association often corresponds

to a verb or prepositional phrase such as part of, next to, works for or contained in
A reference from one class to another is an association
Eliminate unnecessary associations

Implementation associations (e.g. concerned with the implementation or design of the class within
certain programming or development environment)
Ternary associations (e.g. associations among more than 2 classes)
Directed actions (or derived) association

IS 131

Page 2 of 4

LESSON 11: CLASS DIAGRAMS

3. Guidelines for identifying Super-sub class relationships
Top down: Look for noun phrases composed of various adjectives in the class name
Bottom up: Look for classes with similar attributes or methods. In most cases, common attributes
and methods could be moved to an abstract class
Reusability: Move attributes and behaviours as high as possible in the hierarchy
Multiple inheritance: Avoid excessive use of multiple inheritance
4.

Guidelines for identifying Aggregation/a-part-of relationship

Assembly: A physical whole is constructed from physical parts
Container: A physical whole encompasses but is not constructed from physical parts
Collection-member: A conceptual whole encompasses parts that may be physical or conceptual

5. Defining Attributes
Characteristics of the object
6. Defining Operations
Processes that a class knows to carry out
Can refer to the sequence diagram / collaboration diagrams for details
7. Example of a class diagram:

:Bank
name
branchID

has

has
*

*
:Account

:BankClient
1

firstName
lastName
cardNumber
pinNumber

owns

:ATM_Machine

number
balance

address
state

deposit ()
withdraw()

verifyPassword()

IS 131

:CurrentAccount

:SavingAccount

clearCheque()

calcInterest()

Page 3 of 4

LESSON 11: CLASS DIAGRAMS

8. Reference Materials
Object-oriented Systems Development using the Unified Modelling Language (Ali Bahrami)
Chapter 8: Identifying Object Relationships. Attributes & Methods
UML Distilled Second Edition: A Brief Guide to the Standard Object Modelling Language (Martin
Fowler with Kendall Scott)
Chapter 4: Class Diagrams: The Essentials

11. Reference Materials:

Object-oriented Systems Development using the Unified Modelling Language (Ali Bahrami)
Chapter 5: Unified Modelling Language
Object-oriented Systems Development using the Unified Modelling Language (Ali Bahrami)
Chapter 8: Identifying Object Relationships. Attributes & Methods
UML Distilled Second Edition: A Brief Guide to the Standard Object Modelling Language (Martin
Fowler with Kendall Scott)
Chapter 4: Class Diagrams: The Essentials

IS 131

Page 4 of 4

INT I-UC Library

System
<<uses>>
user

Verify User ID
staff of library

<<include>>

User I D

<<uses>>

Provide Service
T o User

<<include>>
Ask For

M anage All T he

Somethings

BooksI n Library
<<extends>> <<uses>>
<<Extend>> <<include>>

<<extends>>

INT I-UC Library

Library Control System

Update System
<<Extend>>
INT I-UC Library Pre-

<<extends>>

Order Books System

<<Extend>>
INT I-UC Library Borrow

<<extends>>

& Return BooksSystem

<<Extend>>

INT I-UC Library

Search System
INT I-UC Library
Individual Account
System

Use Case Diagram: I NTI -UC Library System

I NTI -UC Library Search System

user

Check W ith

<<uses>>

User File

<<include>>

Enter Book

Verify user status

Code

Library Ssystem Computer

<<uses>>
<<include>>

<<extends>>

Enter Book
<<uses>>

Nama
Enter Book
Author

<<uses>> <<I nclude>>

Check for

<<I nclude>>
<<uses>>

Enter Book
Publisher
Enter Book
Edition

Requirement Books

<<include>> <<uses>>
<<I nclude>>
<<uses>>
<<I nclude>>

<<uses>>
<<I nclude>>

<<extends>>
<<extend>>
D isplaty Result
I n List

D atabase
Enter Book
I nformation

System

Update System

Use Case Diagrams: INTI -UC L brary Search System

I N T I -UC Library Borrow

And Return Books System

user

<<uses>>

Verify T he User

<<I nclude>>

ID

User I D

Borrow

<<uses>>

Books

<<I nclude>>
<<uses>>

Return
Books

Staff O f L ibrary

M anage And Return

<<I nclude>>
<<extends>>
<<extend>>

Calculate

Books System

<<uses>>
<<include>>

OverDue Fee

L ibrary Computer System

<<uses>>
Update T he Borrow

<<I nclude>>

Return Book Record in

System

D atabase
System

<<uses>>
<<include>>

<<uses>>
<<include>>

I NT I -UC Library Borrow Book

and Return System

Use Case D iagrams: I NT I -UC L ibrary Borrow And Return Books System

I N T I -UC L ibrary Update

Syst em

Add New

<<extends>>

Books
User

<<extend>>

Supply Books
And I nformation

M anage Books

Book Supplier
<<uses>>
<<uses>>

<<I nclude>>

<<I nclude>>
<<uses>>
L ist Book <<I nclude>>
Books

Code

I nformation
Book
L ocation

Update D atabase
of Books

Use Case D iagrams: I N T I -UC Libarary Update System

I N T I-UC Library Online

Pre-O rder Books System

Login to Library

<<uses>>

Website

<<I nclude>>

System

<<extends>>
User

D atabase

<<extend>>
Check
Password
Search
Books

Library Computer System

<<uses>> <<uses>>
<<I nclude>>
<<I nclude>>

<<uses>>
<<I nclude>>
I NT I -UC Library
Search System

Books

<<uses>>
<<I nclude>>
I NT I -UC Library
O nline Book
Logout From

System

Website

Use Case D iagram: I NT I -UC L ibrary Online Pre-O rder Books System

Enter User ID

Key I n Book I nformation

1
1

Book Code

Book Name

Book

Book

Book

Edition

Author

Publisher

Display The Book List

False
True
Show The Location Of The Book

End

Activity Diagrams: INTI-UC Library Search System

Year Of Publisher

Start

User ID
veri fy

False (re-enter)

True
Borrow Book
verify borrow or return book
False
True
Book Code

Return Book

Check available

Unavailable

Book code
Available

Check

False (Check agai n)

Check Number (1 user

max 5 books)
True

less than 5

Book return information

(Date, time, user ID)
True
Check overdue
Record the books
detail
overdue

False (No overdue)

Calculate overdue
payment

Borrow books

Complete borrow and return books

exceed (can't borrow)

End

Activity D iagram: I NT I -UC L ibrary Borrow And Return Books System

start

Add new books

unsuccess

Manage books
1

List the book code

Key in book information

book location

update database of the book

1

success
finish update

end

Activity D iagram: I NT I -UC Library I nformation Update System

Start

Login to Inti-UC li brary website

Enter user password

check
Invalid user l ogin
Valid
Search book homepage

search book
unavai labl e
1

book name

book edition

book author

book publisher

year of publish

di spl ay book in list

check

available
Book

logout INT I-UC library

end

Activity D iagram: I NT I -UC L ibrary O nline Pre-O rder Book System

User:User

Staff:Staff

ReturnSystem:ReturnSystem

Show I D
Verify I D
Select Borrow System
System Feedback
Key I n Book I nformation
D isplay T he Book List
Select O ne Needed
Show T he Location

Go T o Counter W ith Books

Go to Counter
Record And M ark

Sequence Diagram: I NT I -UC L ibrary Borrow Book System

Book:Book

User:User

Staff:Staff

ReturnSystem:ReturnSystem

Show I D
Verify I D

Select Borrow System

System Feedback
Key I n Book I nformation
D isplay
T he
Select O
ne Needed
Book
L ist
Show
T he
L ocatio
n
Go T o Counter W ith Books

Record And M ark

Sequence Diagram: I NT I -UC L ibrary Return Book System

Book:Book

Staff:Staff

UpdateSystem:UpdateSystem

Supplier:Supplier
Contact

Collect T he Book Needed

Provide Book
Key I n Book I nformation
Update

Sequence Diagram: I NT I -UC L ibrary Update System

Book:Book

Staff:Staff

User:User

O nlineBookSystem:O nlineBookSyste
m

Show I D
Verify I D
Select T he O nline System

Key I n Book I nformation

D isplay Book L ist
Select O ne Needed
D isplay T he Content

Sequence Diagram: I NT I -UC L ibrary O nline Pre-Order Book System

Staff:Staff

1: Show ID

User:User

7: Select One Needed

5: Key In Book Information
3: Select Borrow System

10: Record And Mark

2: Verify ID

ReturnSystem:ReturnSystem

8: Show T he Location
6: Display T he Book List
4: System Feedback

9: Go To Counter With Books

Book:Book

Collaboration D iagram: I NT I - UC L ibrary Return Book System

ReturnSystem:
ReturnSystem

4: System Feedback
6: Display T he Book List
8: Show T he Location

User:User

2: Verify ID
12: Record And Mark

Staff:Staff

11: Go to Counter
1: Show ID

3: Select Borrow System

5: Key In Book Information
7: Select One Needed

10: <anonymous>
9: Go To Counter With Books

Book:Book

Collaboration D iagrams: I NT I -UC L ibrary Borrow Book System

UpdateSystem:
UpdateSystem

5: Update

4: Key In Book Information

Staff:Staff

3: Provide Book

Book:Book

1: Contact

Supplier:Supplier

2: Collect T he Book Needed

Collaboration D iagrams: I NT I -UC L ibrary Update System

User:User
8: Display T he Content
6: Display Book List
4: <anonymous>
1: Show ID
2: Verify ID

7: Select One Needed

5: Key In Book Information
3: Select T he Online System

OnlineBookSystem:
OnlineBookSystem

Staff:Staff

Collaboration D iagrams: I NT I -UC L ibrary Online Pre-Order Book System