UNIT TWO

SYSTEM MODELING
USING UML
 Part I

Functional Modeling:
Use Case Diagram
Outline
 Modelling Concept

 Overview of UML

 More of UML

 Building blocks

 Common mechanisms

 Architecture and Views

 Use Case Diagram – Functional Modelling

 Use Case Scenario

1) What is Model?
 A model is a representation in a certain medium of something in the
same or an-other medium.
 The model captures the important aspects of the thing being modeled
from a certain point of view and simplifies or omits the rest.
 i.e. Modeling consists of building an abstraction of reality.
 Abstractions are simplifications because:
 They ignore irrelevant details and only represent the relevant details.
 What is relevant or irrelevant depends on the purpose of the model.
 A model is expressed in a medium that is convenient for working.
 It is like Drawing a flowchart
 Listing the steps cared out by an application
 E.g.
 Models of buildings may be drawings on paper
 3D figures made of cardboard or finite-element equation in computer.
Why Modelling?
 Why do engineers build models? Why do aerospace engineers build
models of aircraft? Why do structural engineers build models of
bridges? What purposes do these models serve?
What for Modeling?
 To abstract reality:
 Show essential details; filter out non-essential details.
 To find out if something will work (e.g. Modeling aircraft - to see if
they will fly, bridges – to see if they will stands, buildings - to see if
their clients will like the way they look)
 To Estimate cost
 Mostly designs with models are much cheaper than the real thing we are
building
 To have a Standardization
 Models are used to capture and precisely state requirements and domain
knowledge so that all stakeholders may understand and agree on them.
Cont ...
 Easy of understanding:
 Know how a system work and What a system made up of
 To help us deal with complexity as many systems are made of
numerous subsystems interconnected in complicated ways.
 To deal with human limitations in understanding complex things.
 Bringing clarity - to promote understanding of requirements
 Allows to deal with complexity through a divide-and-conquer approach
 In general, it enables developer to incrementally refine simple models
into more detailed ones that are closer to reality
 For example:- assume we want to build an airplane. Even with the help
of field experts, we can’t build an airplane from scratch and hope that it
will function correctly. Instead, we first build a scale model of the air
frame to test its aerodynamic properties. In this scale model, we only
need to represent the exterior surface of the airplane. We can ignore
details such as the instrument panel or the engine.
Cont ...
 Creativity and innovation:- the simplicity of creating and modifying
small models permits creative thought and innovation at little cost.
 To organize, find, filter, retrieve, examine, and edit information
about large systems.

 A model is an abstraction describing a subset of a system.

Why Model software?
Software is getting increasingly more complex
 Windows XP > 40 million lines of code
 A single programmer cannot manage this amount of code in its

entirety.
Code is not easily understandable by developers who did not write it
We need simpler representations for complex systems
 Modeling is a means for dealing with complexity
OO Analysis:- modeling application domain
(represents all aspects of the user’s problem
Object which includes physical environment, peoples,
work process etc.)
Oriented
Modeling
OO Design:- modeling the solution domain
(which represents the system design and object
design activities of the development process)
2) Overview of UML
What Is UML?
 A diagrammatic object-oriented modeling language.
 Use diagrams to document object-based decomposition of systems
and to show the interaction b/n these objects and their dynamics.
 Nonproprietary standard for modeling software systems.

Where UML Come From?

 The first OO modeling languages were developed in the mid 1970's
 By the mid 1994 there were more than 50 OO modeling languages most
of which were only used by a small group of system designers.
 The following are most common one:
 Rumbaugh’s Object Modeling Technique(OMT): Class & Associations
 Shlaer-Mellor (Object-Oriented Analysis/Design (OOA/D),
 Booch Method : Categories and Subsystems
 Coad/Yourdon Methodology : Class, Object, Class-&-Object
 Jacobson OO Software Engineering (OOSE) Use case driven
Cont...
Problems in existence of different OO methodologies
 Resulted in multitude interpretation of the same concepts
 Encouraged confusion
 Limited the progress of methods
 Methods influenced one another
 Distracted the users by the decisions they need to make because of
many methods and notations competing with each other.

Solution: Need for Standardization

 Existing methods are already converging since these methods pick up
ideas from other sources.
 Based on the fact that differences between the various methods were
becoming smaller. The method wars did not move OOT any longer.
 A single, common language is desirable because it can be used for all
development methods, used throughout the project lifecycle, and used
for different application technologies.
Cont ...
UML
 Jim Rumbaugh (OMT) and Grady (Booch) decided at the end of 1994
to unify their work within a single method: the Unified Method.
 Unified Method 0.8 Oct. 1995
 A year later they were joined by Ivar Jacobson (OOSE)
 The Unified Method was transformed into UML (Unified Modeling
Language).
 6/96 UML 0.9
 9/96 UML 0.91

In general, UML is resulted from the unification of OMT, Booch method
and OOSE.
UML has also been influenced by other object-oriented notations, such as
those introduced by Mellor & Shlaer [1998], Coad & Yourdon [1995],
Wirfs-Brock [Wirfs-Brock et al., 1990], Martin and Odell [Martin & Odell,
1992].
Cont ...
Cont ...
Why UML?
 To provide a standard notation that can be used by all OO methods and
to select and integrate the best elements of precursor notations.
 Standardized notation without sacrificing specialized model data
 To have common language that can be used from product conception to
delivery, from system to detailed design levels
 UML provide convenient communication mechanism between all
role players in the software development field from the client to
the business analyst to the architects, designers and developers.
 To reduced learning curve across projects
 To avoid multitude interpretation of the same concepts
 To ignore confusion
 To make the users undistracted by their decisions
Cont ...
Why UML? Advantages
 A graphical view simplifies the understanding of system.
 Increased domain and design model reuse
 Reduces the risk of failure,
 Improves productivity and quality,
 Facilitates maintainability
 Usually results in reduced complexity.
 Increased customer involvement /understanding of problem translation
to product solution
 Designed for a broad range of applications and it provides constructs
for a broad range of systems and activities (e.g., distributed systems,
analysis, system design, data modeling, modeling hardware systems,
deployment)
3) More of UML
 A language whose vocabulary and rules focus on the conceptual and
physical representation of a system.
 UML defines structural and behavioral things and diagrams.
 UML is the language of blueprints for software.
 It is a graphical language for
 Visualizing
 Specifying – building models that are precise, unambiguous, complete
 Constructing – map from a model in UML to a programming language
 Documenting

What UML is Not?

 UML isn’t a method/methodology(Method=Notation(e.g. UML) + Process)
 Does not dictate a particular process
 Used to record result domain & design models, independent of process
 Choose appropriate process for particular project, independent of the
modeling language
Cont ...
UML
UML Structure

Building Common Architecture

Mechanisms
Blocks
 Building Blocks
 Architecture
 Things
 Relationships
 Use-Case View
 Diagrams  Design/Logical View
 Common Mechanisms  Process View
 Specifications  Implementation View
 Adornments  Deployment View
 Common Divisions
 Extensibility Mechanisms
A. Building Blocks of UML
UML has three building blocks:
 Things (the objects),
 Relationships (the glue that holds things together),
 Diagrams (categorized as either structure or behavioral)

1.1 Things – the abstractions

A. Structural things (nouns):- define the static part of model, and
represent conceptual or physical elements: This includes
 Class, Interface (defines set of operations), Collaboration

(interaction b/n elements), Use case, Component, and Node

B. Behavioural things (verbs):- consists dynamic part of UML, and
represent behaviour over time and space: Interaction and state machine
C. Grouping things – mechanism to group UML elements and defines
organizational parts of UML: Packages
D. Notational/Annotational things – explanatory parts of UML: Note
Cont ...
1.2 Relationship – tie things together
A. Dependency (uses): a semantic (logical) relationship between two
things in which a change to one thing (the independent thing) may
affect the semantics of the other thing (the dependent thing).
Ex. A car uses a fuel

B. Association: a structural relationship that describes a set of links, a

link being a connection among objects.

Association
Cont ...
C. Generalization (is a): a specialization/generalization relationship in
which objects of the specialized element (the child) are
substitutable for objects of the generalized element (the parent)

1.3 Diagram
 The graphical representation of a set of elements
 Help to visualize a system from different perspectives
 May contain any combination of things and relationships.
B. Diagrams used to describe behavior
A. Diagrams used to describe
and Function - dynamic
structure - static
 Use Case diagram (functional)
 Class diagram
 Sequence diagram
 Object diagram
 Activity diagram
 Component diagram
 Collaboration diagrams
 Deployment diagram
 Statechart diagram
Cont ...

Fig: An overall view of UML diagrams showing how each diagram leads
to the development of other UML diagrams
Cont ...
UML Building Block Rules
 UML’s building blocks should be put together to develop a well-
formed model.
 A model that is semantically self-consistent and in harmony with all its
related models.
 The UML has semantic rules for
 Names: What you can call things, relationships, and diagrams

 Scope: The context that gives specific meaning to a name.

 Visibility: How those names can be seen and used by others

 Integrity: How things properly and consistently relate to one another.

 Execution: What it means to run or simulate a dynamic model.

B. Common Mechanisms in UML
 Systems development using UML can be made simpler by the presence of
common mechanisms:
1) Specifications
 Behind every part of UML’s graphical notation there is a specification that
provides a textual statement of the syntax and semantics of that building
block.
 Specification are used to state the system’s details
 Provides a semantic backplane that contain all the parts of all the models of
the system.
E.g. a class diagram

: Costomer
Alemayehu : Costomer
2) Common Division: Costomer
-name
name name
class and object -address
-phone address address
phone phone
Cont…
3) Adornments
 Most elements of UML have a unique and direct graphical notation that
provides visual representation of the most important aspects of the element.
 Every element in the UML’s notation starts with a basic symbol, to which
can be added a variety of adornments to that symbol. Transaction
 Making to look more attractive/easily understandable
+execute()
+rollback()
#priority()
4) Extensibility Mechanisms -timestamp()
 UML can be extended using the following mechanisms
 Stereotypes: Extends the vocabulary of UML, allowing you to create
new kinds of building blocks that are derived from existing ones but that
are specific to your problem.
 Constraints: Extends the semantics of a UML building block, allowing
you to add new rules or modify existing ones.
C. Architecture
 Before designing and developing the system, the architecture needs to made
by visualize the system from different viewer’s perspective.
 Architecture is the set of significant decisions/description about
 The organization of a software system
 The selection of the structural elements and their interfaces which the
system composed of it.
 Their behavior, as specified in the collaborations among those elements
 The composition of these structural and behavioral elements into
progressively larger subsystems
 The architectural style that guide this organization:
 The static and dynamic elements and their interfaces,

 Their collaborations, and their composition.

 Software architecture is not only about architecture and behavior, but also
concerned with usage, functionality, performance, resilience, reuse,
comprehensibility, economic and technology constraints and trade-offs.
View of Systems
 A view is simply a subset of UML modeling constructs that represent one
aspect of the system
 Use to describe the system architecture.
 Each of the views involve structural and behavioural models
 Systems can be viewed from a number of perspectives - different
Stakeholders:
 Refers to system owners, end users, analyst and designer, system
developers, project managers etc.
 Each looks at the system in different angle at different times over the
project’s life span.
 System Architecture can be used to manage these different viewpoints,
therefore controlling the development of a system throughout its life cycle
Cont…
UML captures these different angles/viewpoints as a set of 5 interlocking
views: -

Vocabulary System assembly

functionality configuration
Implementation management
Design view
view

behavior
Use case view

Deployment
Process view
view System topology
Performance distribution
scalability delivery
throughput installation

• Each view focused on a particular aspect of the system, are stand alone
and interact with each other
Cont….
 Use case view:- the centre view which connects all other views
 Models the functionality of the system as perceived by outside users, called actors.
 Focuses on scenarios executed by human users and external systems.
 Explain what the new system will do without specifying how it will do it
 Purpose:- To list the actors and use cases and show which actors participate
in each use case.
 End-product: use case diagrams

 Design views:- Supports the functional requirements of the system

 Focuses on the things (classes, interfaces and collaborations) that form the
vocabulary of the problem that the system is trying to solve and the
elements of the solution to that problem.
 The view encompasses the static and dynamic aspects of the system
 End-product: class and object diagram (static), Sequence/collaboration,
activity and statechart diagram (dynamic)
Cont….
 Process view
 Focuses on the aspects of the system that involves timing and the flow
of control.
 Addresses the performance, scalability and throughput of the system
 End product: Activity diagrams

 Implementation view
 Encompasses the components and files that are used to assemble and
release the physical system
 End-product: Component diagrams

 Deployment view
 Focuses on the geographic distribution of the various software elements
on hardware and other physical elements that constitute a system
 Encompasses the nodes that form the system’s hardware topology on
which the system executes
 End-product: Deployment diagram
Use Case Diagram:- Functional
Model
3.1 Use Case Model
 Use cases are a standard technique for gathering requirements in
many modern software development methodologies.
 E.g. In behavioral methodology - One of the first and primary
means of gathering requirements
 The starting point for UML modeling.
 Used to capture the intended behaviour of system or business
processes carried out in the system under development as it appears
to the outside user.
 Represents the functional requirements of a system
 A depiction of a system’s behavior or functionality under various
conditions as the system responds to requests from users functioning
for a specific business purpose.
 The Use case diagram is used to identify the primary elements and
processes that form the system.
Cont...
Use case Modeling could be
 Essential Use Case Diagram
Used at requirement elicitation stage


 Technology free

 Just to understand what users need to see on the system from

functions point of view

 System Use Case Diagram
 Is a continuation of essential use case

 Adding implementation related details

Use case model may consists of

 Single use case diagram
 Further (nested) packages of use case diagrams
 The supreme package of the nested packages is the use case model
 Notes:- emphasis is on depicting what a system does rather than how it
does it
Use Case Diagrams
 Use case diagrams show describe what a system does from the standpoint
of an external observer.
 The system is treated as a black-box and one solely identifies what the
system is used for.
 It closely connected to a scenario which is an example of what happens
when someone interacts with the system. Here is a scenario for a medical
clinic:
 Use Case Diagram- shows the relationship between actors and use cases in
a system

 Use case diagram Components:

 Use cases
 Actors
 Relationships
 System boundary
Cont...
UML Use Case Diagram Symbols

Use Case Connection

Include relationship
Actor
<<include>>

Extend relationship
Boundary
<<extend>>
Cont...
System Boundary
 This boundary is clarified by the system boundary
 Defines the scope of what a system will be.
 The dividing line between the system and its environment
 System boundary of a use case diagram defines the limits of the system.
 It shown as a rectangle spanning all the use cases in the system
 Use cases are within the boundary.
 Actors are outside of the boundary.
Cont...
Actor
 Model anything that needs to exchange information with the system
 Actors are external to the system (physical entities or other system)
 Actors interact with the system.

 Define roles that users can play but not a specific user.
 One user may play many roles
 An actor may represent many users.

 The different roles the actor represents are the actual business roles of
users in a given system.
 Most actors represent user roles, but actors can also be external systems.
 An actor is shown as a stick figure in a use case diagram depicted
"outside" the system boundary.
 To identify an actor, search in the problem statement for business terms
that portray roles in the system.
 Actor classes have actors instances/objects that represent specific actors.
Cont...
Use Case
 Represents a class of functionality provided by the system
 Describes a function provided by the system that yields a visible
result for an actor.
 Visual representation of a distinct business functionality in a system

 A typical sequence of actions that a user performs in order to

complete a given task
 Describing how the user will use the system
 To find use case, in the problem statement, list the discrete business
functions in your problem statement.
 The business process is discrete in nature.

 Remember that identifying use cases is a discovery rather than a creation.

 A use case is shown as an ellipse in a use case diagram and located inside
the boundary of the system.
 It is one of the key activities in requirements elicitation and analysis
Cont...
Examples 1:
Cont...
Examples 2:
Classifier
Use Case

Actor

System boundary
Cont...
Examples 3:
 Use case model:
 The set of all use
cases that completely
describe functionality
of the system.
Cont...
Examples 4: On-line Bookstore System

Register

Custome Order
r books

Sell used
books

Review
books
Cont...
Use cases characteristics:
 Describe the interactions/dialogs between a system and actors, including
the messages exchanged and the actions performed by the system.
 Not the computations the system performs.
 Only include actions in which the actor interacts with the computer.
 Use cases may be initiated by actors and may involve the participation of
numerous other actors.
 Use cases may have extension points that define specific points within an
interaction at which other use cases may be inserted
 Use cases classes have use case instances or objects called scenarios that
represent specific interactions.
 Be written so as to be as independent as possible from any particular user
interface design.
 objective of use case analysis is to model the system:
 … how users interact with this system
 … when trying to achieve their objectives.
Cont...
Relationship
 Represented by directional or non-directional edges
 May relate two use cases or two actors, or relate a use case and an actor
 May be annotated by stereotypes (constructs that extends the UML
vocabulary and adds new meanings to existing entities)
Association (Connection):
 An association between actor and use case
 Denoted as solid lines or paths.
 Arrowheads may be used to indicate who initiates communication in the
interaction.
 Connection does not indicate data flow
Cont...
Includes:
 Connection between two use cases
 Indicates a use case that is used (invoked) by another use case.
 A base use case defines the location at which the inclusion use case is
included.
 Denoted as dashed lines with an open arrow-head pointing at the
inclusion use case and are labelled with the <<include>> stereotype.
Cont...
Extends: connection between two use cases
 Extends a use case by adding new behavior or actions
 Indicates that the base use case may be augmented by the extension use
case; i.e., the inclusion use case will augment the base use case if an
extension condition is satisfied.
 A base use case defines the extension point.
 Denoted as dashed lines/paths with open arrow-head pointing an extension
use case and labelled with the <<extend>> keyword (stereotype).
Cont...
The <<includes>> Relationship <<includes>> relationship
represents common functionality
needed in more than one use case
<<includes>> behavior is
Passenger factored out for reuse, not
because it is an exception
PurchaseMultiCa  The direction of a <<includes>>
rd
PurchaseSingleTicket relationship is to the using use
<<includes>> case (unlike the direction of the
<<includes
>> <<extends>> relationship).

<<extends CollectMoney
>> <<extends>
>
NoChange
Cancel
Cont...
The <<extends>> Relationship  <<extends>> relationships model
exceptional or seldom invoked cases
 The exceptional event flows are factored
out of the main event flow for clarity
Passenger
 The direction of an <<extends>>
relationship is to the extended use case
 Use cases representing exceptional flows
PurchaseTicket can extend more than one use case.

<<extends>> <<extends
>>

<<extends>>
<<extends
>>
OutOfOrder TimeOut

Cancel NoChange
Cont...

Sell Item
<<
In c
lud
es>
>
Reorder
<<Includes>>
Sales Clerk
Login
Add to
Stock <<Includes>>

Generate <<Includes>>
Report

Manager
Cont...
Generalization
 From specialization to generalized use case
 Indicate the specialization use cases are consistent with the generalized
use case and may add additional information.
 A specialized use case may be used in place of a generalized use case
and may use any portions of the interaction of generalized use case.
 From specialization to generalized Actor
 The specialized actor are consistent with the generalized actor and may
add additional information.
 A specialized actor may be used in place of a generalized actor and
receives the characteristics of the generalized actor.
 Notes:
 In both case generalization is denoted as solid lines/paths with a hollow
arrow-head pointing at the generalized use case or generalized actor.
Cont...
Example:
• From specialization to
generalized Actor Library User (Patron)

Faculty Members NonAcademic Staff Students External User

2ndYear 3rdYear 4thYear 5thYear Postgraduate

Cont...
Example:
From specialization to
generalized Use case
Cont...
3.2 Use Case Scenario/Documentation
Document containing detailed specifications for a use case
Contents can be written as simple text or in a specified format
Specify the behavior of a use case by describing the flow of events in text
clearly enough for an outsider to understand it easily.
Includes
 How and when the use case starts and ends
 When the use case interacts with the actors
 What objects are exchanged
 The basic flow and alternative flows of the behavior
The Use Case documentation needs information like:
 List of Actors
 List of Business Rules (BR)
 List of User Interfaces (UI)
Cont...
Major Elements of Flow Events
Introduction/Title: Descriptive name or match that describe a quick
background of the use case.
Actors: List the actors that interact and participate in this use case.
Actor Description/Definition: Define/Describe each actor.
Pre-conditions: Pre-conditions that need to be satisfied for the use case to
perform.
Post-conditions: Define the different states in which you expect the system
to be in, after the use case executes.
Basic Flow/Main success scenario: List the primary events that will occur
when this use case is executed.
Alternative flows/Extensions (how to deal with error): Any subsidiary
events that can occur in the use case should be separately listed. List each
such event as an alternative flow. A use case can have as many alternative
flows as required.
Use Case Documentation – Example
Name Sell Item
Identifier UC-008
Description Sell available items in a store to a customer
Actor Sales Clerk
Pre Condition none
Post Condition The sales clerk will sell the item if available in store

Extends none
Includes UC-001

Basic Course of Action

1.The Sales Clerk want to sell an item
2.The Sales Clerk logs into the system using “UC-001: Login”
3.The system displays the main Window “UI-002: Main Menu”
4.The Sales Clerk selects “Sell” from the Main Menu
5.The system displays the Sell interface “UI-006: Sell Item”
6.The Sales Clerk selects the items and quantity he want to sell
7.The system check the availability of the items according to the business rule “BR-012: check availability of item”
8.The system displays the total amount of money to be paid with the item list via “UI-013: Payment Voucher”
9.The Sales Clerk indicates he want to print the payment voucher.
10.The system prints the payment voucher
11.The use case ends when the Sales clerk receive the money and give the payment voucher to customer.

Alternative Course of Action A: The item is not available in store

8.The system determines that the item is not available.
9.The system informs the Sales Clerk that the transaction can not be completed via “UI-014: Item Quantity not Available”
10.The use cases resumes at step 6 of the basic course of action
3.3 The benefits use case modelling
 By modeling the behavior of an element with use cases, you provide a
way for domain experts to specify its outside view to a degree sufficient
for developers to construct its inside view
 Use cases provide a way for developers to approach an element and
understand it
 Use cases serve as the basis for testing each element as it evolves during
development
 Help to define the scope of the system
 Be used to plan the development process
 Be used to both develop and validate the requirements
 Form the basis for the definition of test cases
 Be used to structure user manuals
3.4 Summary of Use case
General steps in Use case Modeling
1) Identify the system’s boundaries
2) Identify actors from the SRS or problem definition
 List the primary actors
 List the goals of each primary actor
3)Identifying the Major Use-Cases
 Identify and write the major use-cases
 Carefully review use-cases
4) Expand the Major Use-Cases
 Choose one major use-case to expand
 Fill in the steps of the normal flow of events
 Normalize the size of each step
 Describe alternate or exceptional flows
Cont...
5) Confirm the Major Use Cases
 Review the current set with user involvement by consider
semantics and syntax
 Iterate the entire set of steps until all use cases are defined
6) Identify relationships
7) Create the Use-Case Diagram
 Start with system boundary
 Use symbols and represent use cases with in a boundary
 Place actors on the diagram
 Conclude by connecting actors to use cases by lines
8) Define use case description
Use Case Diagram Useful Link
http://www3.software.ibm.com/ibmd
l/pub/software/rational/web/pres/uca
se.html
THE
END
Reading Assignment and Questions
1. Discuss the various UML Model levels
The UML Reference Manual (Addison-Wesley - 1999) – Page 33

2. Model Automatic Teller Machine (ATM) using Use case Model

OOSAD Using UML - Dr. Fritz Solms - Page 31- 32

3. Model Passenger Booking System using Use case Model

 UML Diagram – Behavioral Modeling Page 1- end
HINTS AND TIPS: For developing use cases
The goal is to develop a well-structured use case that:
 Names a single identifiable, and reasonably atomic behavior of the
system or part of the system.
 Factors common behavior by pulling such behavior from other use
cases that it includes.
 Factors variants by pushing such behavior into other use cases that
extend it.
 Describes the flow of events clearly enough for an outsider to easily
understand it.
 Is described by a minimal set of scenarios that specify the normal and
variant semantics of the use case.
A well-structured use case diagram
 Focused on communicating one aspect of system’s static use case view.
 Contains only those use cases that are essential to understanding that
aspect.
 Provides detail content with its level of abstraction.
 Not so minimalist as to misinform the reader about semantics that are
important.
Exercise:
 On-line Bookstore is a web application that can be accessed by the store’s
registered customer, whereby each customer can order books, review one
or more books sold in the book store, and sell used books to other
customers. Before performing any one of these transactions, the customer
must first log-in into the system using their user id and password kept in
their account. The customer can also take a book he/she ordered.
 Problems:
 Develop a use case model(system use case)-Provide your reason to
pick “one” as a component of your model
 Document one of the use cases you have identified “sell used book”
 On-line Bookstore System

Register

<<extend>>
(CustID) Check out
Customer Order books
<<include>>

<<include>>
Sell used Log-in
books
<<include>>

Review books
Cont...
Solution: Sell used books
 Main flow of events: -

1. The CUSTOMER clicks the Sell Used Books button on the Home
Page.
2. The system displays the sell used books web page.
3. The CUSTOMER enters the required information on the used books
that he/she wants to sell.
4. The CUSTOMER clicks the SEND button on the webpage.
5. The system displays a confirmation page listing the information that
the CUSTOMER has entered.
6. The CUSTOMER checks that the information displayed are
accurate. If yes, CUSTOMER clicks “OK” button on the web page.
7. The system updates the USED BOOKS table in the database.