DATA MODELING CONCEPTS

If software requirements include the need to create, extend, or interface with a

database or if complex data structures must be constructed and manipulated,
the software team may choose to create a data model as part of overall
requirements modeling.

A software engineer or analyst defines all data objects that are processed
within the system, the relationships between the data objects, and other
information that is pertinent(relevent) to the relationships.

The entity-relationship diagram (ERD) addresses these issues and represents

all data objects that are entered, stored, transformed, and produced within an
application.
DATA MODELING CONCEPTS
❑ Data Objects:

A data object is a representation of composite information that must be

understood by software. Therefore, width (a single value) would not be a valid
data object, but dimensions (incorporating height, width, and depth) could be
defined as an object.

A data object can be

an external entity (e.g., anything that produces or consumes information),

a thing (e.g., a report or a display),

an occurrence (e.g., a telephone call) or event (e.g., an alarm),

DATA MODELING CONCEPTS
an external entity (e.g., anything that produces or consumes information),

a thing (e.g., a report or a display),

an occurrence (e.g., a telephone call) or event (e.g., an alarm),

a role (e.g., salesperson),

an organizational unit (e.g., accounting department),

a place (e.g., a warehouse), or a structure (e.g., a file).

The description of the data object incorporates the data object and all of its
attributes.

A data object encapsulates data only—there is no reference within a data

object to operations that act on the data
DATA MODELING CONCEPTS
❑ Data Attributes:

Data attributes define the properties of a data object and take on one of three
different characteristics. They can be used to

(1) name an instance of the data object, (2) describe the instance, or (3) make
reference to another instance in another table.

One or more of the attributes must be defined as an identifier—that is,

the identifier attribute becomes a “key” when we want to find an instance of the
data object.

In some cases, values for the identifier(s) are unique, although this is not a
requirement.
DATA MODELING CONCEPTS
❑ Relationships :

A connection is established between person and car because the two objects
are related.

But what are the relationships? To determine the answer, you should
understand the role of people (owners, in this case) and cars within the context
of the software to be built.

You can establish a set of object/relationship pairs that define the relevant
relationships. For example

A person owns a car.

A person is insured to drive a car.

 DATA MODELING CONCEPTS
❑ Relationships :

The relationships owns and

insured to drive define the
relevant connections between
person and car. Figure
illustrates these
object-relationship pairs
The arrows noted in Figure provide important information about the
graphically.
directionality of the relationship and often reduce ambiguity or
misinterpretations.
 CLASS-BASED MODELING
Class-based modeling represents the objects that the system will manipulate,
the operations that will be applied to the objects to effect the

manipulation,

relationships between the objects, and

the collaborations that occur between the classes that are defined.
 CLASS-BASED MODELING
The elements of a class-based model include

classes and objects,

attributes,

operations,

class responsibility,

collaborator

(CRC) models,

collaboration diagrams, and

packages
 CLASS-BASED MODELING
❑ Identifying Analysis Classes:

Classes are determined by underlining each noun or noun phrase and

entering it into a simple table.

If the class (noun) is required to implement a solution, then it is part of the

solution space;

otherwise, if a class is necessary only to describe a solution, it is part of the

problem space.

Analysis classes manifest themselves in one of the following ways:

External entities that produce or consume information to be used by a

computer-based system
 CLASS-BASED MODELING
❑ Identifying Analysis Classes:

Things (e.g., reports, displays, letters, signals) that are part of the information
domain for the problem.

Occurrences or events (e.g., a property transfer or the completion of a series

of robot movements) that occur within the context of system operation.

Roles (e.g., manager, engineer, salesperson) played by people who interact

with the system.

Organizational units (e.g., division, group, team) that are relevant to an

application.

Places (e.g., manufacturing floor or loading dock) that establish the context of
the problem and the overall function of the system.
 CLASS-BASED MODELING
❑ Identifying Analysis Classes:

Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a

class of objects or related classes of objects.
 CLASS-BASED MODELING
❑ Specifying Attributes:

Attributes are the set of data objects that fully define the class within the
context of the problem.

Attributes describe a class that has been selected for inclusion in the
requirements model.

In essence, it is the attributes that define the class—that clarify what is

meant by the class in the context of the problem space.

To develop a meaningful set of attributes for an analysis class, you should

study each use case and select those “things” that reasonably “belong” to
the class
 CLASS-BASED MODELING
❑ Defining Operations :

Operations define the behavior of an object.

Although many different types of operations exist, they can generally be

divided into four broad categories:

(1)operations that manipulate data in some way.

(2) operations that perform a computation,

(3)operations that inquire about the state of an object, and

(4) operations that monitor an object for the occurrence of a controlling event.

These functions are accomplished by operating on attributes and/or

associations.
 CLASS-BASED MODELING
Therefore, an operation must have “knowledge” of the
nature of the class’ attributes and associations.

As a first iteration at deriving a set of operations for an

analysis class, you can again study a processing narrative
(or use case) and select those operations that reasonably
belong to the class. To accomplish this,

the grammatical parse is again studied and verbs are

isolated.

Some of these verbs will be legitimate operations and

can be easily connected to a specific class
 CLASS-BASED MODELING
❑ Class-Responsibility-Collaborator (CRC) Modeling:

CRC modeling provides a simple means for identifying and organizing the
classes that are relevant to system or product requirements.

One purpose of CRC cards is to fail early, to fail often, and to fail
inexpensively.

It is a lot cheaper to tear up a bunch of cards than it would be to

reorganize a large amount of source code.

A CRC model is really a collection of standard index cards that represent

classes.
 CLASS-BASED MODELING
❑ Class-Responsibility-Collaborator (CRC) Modeling:

The cards are divided into three sections.

Along the top of the card you write the name of the class.

In the body of the card you list the

class responsibilities on the left and

the collaborators on the right.

 CLASS-BASED MODELING
❑ Class-Responsibility-Collaborator (CRC) Modeling:

In reality, the CRC model may make use of actual or virtual index cards.
The intent is to develop an organized representation of classes.

Responsibilities are the attributes and operations that are relevant for the
class. simply, a responsibility is “anything the class knows or does”.

Collaborators are those classes that are required to provide a class with the
information needed to complete a responsibility.

In general, a collaboration implies either a request for information or a

request for some action
 CLASS-BASED MODELING
Classes :

Entity classes, also called model or business classes, are extracted directly
from the statement of the problem These classes typically represent things
that are to be stored in a database and persist throughout the duration of
the application.

Boundary classes are used to create the interface (e.g., interactive screen
or printed reports) that the user sees and interacts with as the software is
used. Entity objects contain information that is important to users, but
they do not display themselves. Boundary classes are designed with the
responsibility of managing the way entity objects are represented to users.
 CLASS-BASED MODELING
Classes :

Controller classes manage a “unit of work” from start to finish. That is,
controller classes can be designed to manage

(1) the creation or update of entity objects,

(2) the instantiation of boundary objects as they obtain information from

entity objects,

(3) complex communication between sets of objects,

(4) validation of data communicated between objects or between the user and
the application.

In general, controller classes are not considered until the design activity has
begun.
 CLASS-BASED MODELING
Responsibilities :

System intelligence should be distributed across classes to best address the

needs of the problem.

Each responsibility should be stated as generally as possible.

Information and the behavior related to it should reside within the same
class.

Information about one thing should be localized with a single class, not
distributed across multiple classes.

Responsibilities should be shared among related classes, when appropriate

 CLASS-BASED MODELING
Collaborations :

Classes fulfill their responsibilities in one of two ways:

1) A class can use its own operations to manipulate its own attributes,
thereby fulfilling a particular responsibility, or

2) a class can collaborate with other classes.

To help in the identification of collaborators, you can examine three

different generic relationships between classes (1) the is-part-of
relationship, (2) the has-knowledge-of relationship, and (3) the
depends-upon relationship.
 CLASS-BASED MODELING
Collaborations :

When a complete CRC model has been developed, stakeholders can

review the model using the following approach

All participants in the review are given a subset of the CRC model index
cards. Cards that collaborate should be separated

All use-case scenarios (corresponding use-case diagrams) should be

organized into categories.

The review leader reads the use case deliberately.

When the token is passed, the holder of the Sensor card is asked to describe
the responsibilities noted on the card.
 CLASS-BASED MODELING
Collaborations :

The review leader reads the use case deliberately.

When the token is passed, the holder of the Sensor card is asked to describe
the responsibilities noted on the card.

If the responsibilities and collaborations noted on the index cards cannot

accommodate the use case, modifications are made to the cards.

This continues until the use case is finished. When all use cases have been

reviewed, requirements modeling continue. .

 CLASS-BASED MODELING
❑ Associations and Dependencies :

In many instances, two analysis classes are related to one another in some
fashion, much like two data objects may be related to one another. In
UML these relationships are called associations.

In some cases, an association may be further defined by indicating

multiplicity
 CLASS-BASED MODELING
Multiplicity is the specification of the number of instances of one class that
may be related to the instance of another class.

Multiplicity constrains the number of a related object.

You can use multiple associations between objects.

Some typical type of multiplicity:

Multiplicity Option Cardinality

0..1 No instances or one instance
1..1 1 Exactly one instance
0..* * Zero or more instances
1..* At least one instance
5..5 5 Exactly 5 instances
m..n At least m but no more than n instances
 CLASS-BASED MODELING
One to One Association
has
Account Holder 1 1
Cheque Book One account holder has one cheque book

Many to Zero or One Association

issue
Account Holder * 0..1
Debit Card An account holder can issue at most one debit card.

Many to Many Association

withdraw
Account Holder * *
ATM Every account holder can withdraw money from all ATMs.

One to One or Many Association

Bank have Branch The bank should have at least one branch.
1 1..*
 CLASS-BASED MODELING
❑ Analysis Packages:

An important part of analysis modeling is categorization. That is, various

elements of the analysis model are categorized in a manner that packages
them as a grouping—called an analysis package—that is given a
representative name

For example, Classes such as Tree, Landscape, Road, Wall, Bridge,

Building, and VisualEffect might fall within this category. Others focus on
the characters within the game, describing their physical features, actions,
and constraints.
 CLASS-BASED MODELING
❑ Analysis Packages:
CLASS DIAGRAM
The purpose of class modeling is to describe
objects in systems and different types of
relationships between them.

The class diagram is used to construct and visualize object-oriented systems.

Class modeling is used to specify the structure of the objects, classes, or components that exist
in the problem domain or system.

Class diagram provides a graphic notation for modeling classes and their relationships.

An object is a concept, abstraction, or thing with an identity that has meaning for an
application.

Class diagrams represent an overview of the system like classes, attributes, operations, and
relationships.
ELEMENTS OF CLASS DIAGRAM (CLASS NAME)

The name of the class appears in the upper section.

Class name should be meaningful.
Class Class name should always be aligned center of the upper section.
Name
Class name should start with capital letters, and intermediate letter is
Attributes a capital.
Operations Class name should be always bold format.
For e.g.:
Account Customer Employee

Abstract class name should be written in italic format.

CONT.
For e.g. in the banking system, there are two types of accounts; one is a saving account and another
is a current account.

Account is an abstract class and saving account and the current account is a subclass of Account.

The system can’t directly access the Account class.

Abstract class
italic font

Account

Normal class
non italic font

SavingAccount CurrentAccount
ELEMENTS OF CLASS DIAGRAM (ACCESS MODIFIERS)
Public (+): Member accessible by all classes, whether these classes are in
the same package or in another package.

Private (-): Member cannot be accessed outside the enclosing/declaring

class.

Protected (#): Member can be accessed only by subclasses and within a

class. SavingAccount
Package (~): Member can be accessible by all classes, within the package. + accountNumber:long
+ name:String
Outside package member not accessible. # dob: Date
~ panNumber:String
Static (underlined) : Member can be accessed using class name only.
ELEMENTS OF CLASS DIAGRAM (OPERATION)
The operation is a function or procedure that may be applied to objects in a class.

The UML notation is to list operations in the third compartment of the class box.
Class
Name The operation name in the regular face, left align the name in the box, and use a
Attributes lowercase letter for the first character.

Operations Optional detail, such as an argument list and result type, may follow each operation
name.

The return type of method should be written after colon.

Accessibility of operation must be defined using a member access modifier.

Syntax : accessModifier methodName(argumentList):returnType

Account

+ changePhoneNumber(phoneNumber:String):int
 GENERALIZATION & SPECIALIZATION
Generalization is the process of extracting Vehical
shared characteristics from two or more + no of wheels:int
classes and combining them into a
+start() : void
generalized superclass +stop() : void
+applyBreak() : void

Specialization
Shared characteristics can be attributes or

Generalization
+refilllFule() : int
methods.
Represents an "is-a" relationship
For example, a car is a vehicle and a truck
is a vehicle. In this case, vehicle is the
general thing, whereas car and truck are the Car Truck
more specific things.
Specialization is the reverse process of +parkAtHome() : void + loadGoods() : void
Generalization means creating new + unloadGoods() : void
sub-classes from an existing class.
GENERALIZATION & SPECIALIZATION
For example in a bank, any
Customer opens an account. Account
+ accountNo:long
The account can be either a + balance:double
+debitAmount(amount:double): void
savings account or a current +creditAmount(amount:double) : int
+getBalance(accountNo:long) : double
account. In saving account,
customer earns fixed interest
on the deposit. But this SavingAccount CurrentAccount
+ interestRate:double
facility is not available in the + isTransactionLimitOut(accountNo:long) : int

current account.
LINK AND ASSOCIATION CONCEPTS
Link and associations are the means for establishing relationships among objects and
classes.

A link is a physical or conceptual connection among objects.

An association is a description of a group of links with common structure and common

semantic & it is optional.

Aggregation and Composition are the two forms of association. It is a subset of association.

Means they are specific cases of association. In both aggregation and composition object of
one class "owns" object of another class, but there is a minor difference.
AGGREGATION
Aggregation is a subset of association. it is a collection of
different things.
It is more specific than an association.

It represents ‘has a’ relationship.

Aggregation implies a relationship where the child is independent of its parent.

For e.g.: Here we are considering a car and a

wheel example. A car cannot move without a
wheel. Car Wheel
But the wheel can be independently used with the
bike, scooter, cycle, or any other vehicle.
The wheel object can exist without the car object,
which proves to be an aggregation relationship.
COMPOSITION
The composition is a part of the aggregation. It represents the
dependency between a parent and its children, which means if the
parent is discarded then its children will also discard.

It represents ‘part-of’ relationship.

In composition, both the entities are dependent on each other.

For e.g.: Person class with Brain class, Person

Heart class, and Legs class.

If the person is destroyed, the brain,

heart, and legs will also get discarded.
Brain Heart Legs
 CLASS DIAGRAM OF BANK MANAGEMENT SYSTEM
*
Bank
- name : string *
- code: string ha
ve
ve
+manageBranch();
ha

* 1..*
ATM Branch Account
- location : string manage - branchName : string 1 have 1..* ~ accountNumber: string
- manageBy: string * * - branchCode: string - balance: number
+transaction(); + manageAccount():void +debitAmount(amount:double): void
+ transaction():init 1..2 +creditAmount(amount:double) : int
*
* +getBalance(accountNo:long) : double

e
tra

ag
an
ns

ve
ac

m
ha
tio

*
n

Customer
- name: string 1 CurrentAccount SavingAccount
- address: string
* - dob: date - interestRate:double
- panNumber: string + isTransactionLimitOut(accountNo:long) :
+ manageAccount():void int
+ transaction():init
 REQUIREMENTS MODELING
(FLOW, BEHAVIOR, PATTERNS AND WEBAPPS)
The requirements model has many different dimensions.

Flow oriented models,

Behavioral models, and

the special requirements analysis considerations that come into play when
WebApps are developed.

Each of these modeling representations supplements the use cases, data models,
and class based models.
FLOW-ORIENTED MODELING
Although the data flow diagram (DFD) and related diagrams and information are
not a formal part of UML, they can be used to complement UML diagrams
and provide additional insight into system requirements and flow.

Flow-oriented modeling provides an indication of how data objects are

transformed by processing functions.

The DFD takes an input-process-output view of a system. That is,

data objects flow into the software, are transformed by processing elements, and resultant
data objects flow out of the software.

Data objects are represented by labeled arrows, and

transformations are represented by circles (also called bubbles).

FLOW-ORIENTED MODELING
The DFD is presented in a hierarchical fashion. That is, the first data flow model
(sometimes called a level 0 DFD or context diagram) represents the system as a whole.

Subsequent data flow diagrams refine the context diagram, providing increasing detail
with each subsequent level.
FLOW-ORIENTED MODELING
Creating a Data Flow Model: The data flow diagram enables you to develop models
of the information domain and functional domain.

As the DFD is refined into greater levels of detail, you perform an implicit functional
decomposition of the system.

A few simple guidelines of a data flow diagram:

(1) the level 0 data flow diagram should depict the software/system as a single bubble;

(2) primary input and output should be carefully noted;

(3) refinement should begin by isolating candidate processes, data objects, and data
stores to be represented at the next level;

(4) all arrows and bubbles should be labeled with meaningful names;
FLOW-ORIENTED MODELING
(5) information flow continuity must be maintained from level to level,2 and

(6) one bubble at a time should be refined. There is a natural tendency to overcomplicate the data
flow diagram. This occurs when you attempt to show too much detail too early or represent
procedural aspects of the software in lieu of information flow.

Creating a Control Flow Model: For some types of applications, the data model and the
data flow diagram are all that is necessary to obtain meaningful insight into software
requirements.

However, a large class of applications are “driven” by events rather than data, produce control
information rather than reports or displays, and process information with heavy concern for
time and performance.

Such applications require the use of control flow modeling in addition to data flow modeling.
FLOW-ORIENTED MODELING
An event or control item is implemented as a Boolean value (e.g., true or false,
on or off, 1 or 0) or a discrete list of conditions (e.g., empty, jammed, full).

To select potential candidate events, the following guidelines are suggested:

List all sensors that are “read” by the software.

List all interrupt conditions.

List all “switches” that are actuated by an operator.

List all data conditions.

Recalling the noun/verb parse that was applied to the processing narrative,
review all “control items” as possible control specification inputs/outputs.
FLOW-ORIENTED MODELING
To select potential candidate events, the following guidelines are suggested:

Describe the behavior of a system by identifying its states, identify how each
state is reached, and define the transitions between states.

Focus on possible omissions—a very common error in specifying control

FLOW-ORIENTED MODELING
FLOW-ORIENTED MODELING
FLOW-ORIENTED MODELING
The Control Specification: A control specification (CSPEC) represents the
behavior of the system in two different ways.

The CSPEC contains a state diagram that is a sequential specification of

behavior.

It can also contain a program activation table—a combinatorial specification

of behavior.

Figure 7.4 depicts a preliminary state diagram for the level 1 control flow model
for SafeHome.
FLOW-ORIENTED MODELING
FLOW-ORIENTED MODELING
The Process Specification: The PSPEC is a “minispecification” for each
transform at the lowest refined level of a DFD.

The process specification (PSPEC) is used to describe all flow model processes
that appear at the final level of refinement.

The content of the process specification can include narrative text, a program
design language (PDL) description of the

process algorithm, mathematical equations, tables, or UML activity diagrams.

FLOW-ORIENTED MODELING
CREATING A BEHAVIORAL MODEL
We can represent the behavior of the system as a function of specific events and time.

The behavioral model indicates how software will respond to external events or stimuli.

To create the model, you should perform the following steps:

1. Evaluate all use cases to fully understand the sequence of interaction within the
system.

2. Identify events that drive the interaction sequence and understand how these events
relate to specific objects.

3. Create a sequence for each use case.

4. Build a state diagram for the system.

5. Review the behavioral model to verify accuracy and consistency.

CREATING A BEHAVIORAL MODEL
Identifying Events with the Use Case:

The use case represents a sequence of activities that involves actors and the system.

In general, an event occurs whenever the system and an actor exchange information. A
use case is examined for points of information exchange.

The underlined portions of the use case scenario indicate events.

An actor should be identified for each event; the information that is exchanged should be
noted, and any conditions or constraints should be listed.

Once all events have been identified, they are allocated to the objects involved.

Objects can be responsible for generating events or recognizing events that have occurred
elsewhere.
CREATING A BEHAVIORAL MODEL
State Representations: In the context of behavioral modeling, two different
characterizations of states must be considered:

(1) The state of each class as the system performs its function and

(2) The state of the system as observed from the outside as the system performs its
function.

The state of a class takes on both passive and active characteristics.

A passive state is simply the current status of all of an object’s attributes.

The active state of an object indicates the current status of the object as it undergoes a
continuing transformation or processing.

An event (sometimes called a trigger) must occur to force an object to make a transition
from one active state to another.
CREATING A BEHAVIORAL MODEL
State Representations:

Two different behavioral representations are discussed in the paragraphs that follow.

1) The first indicates how an individual class changes state based on external events

2) The second shows the behavior of the software as a function of time.

• State diagrams for analysis classes.

• One component of a behavioral model is a UML state diagram that represents active
states for each class and the events (triggers) that cause changes between these active
states.
• Figure 7.6 illustrates a state diagram for the ControlPanel object in the SafeHome security
function.
• Each arrow shown in Figure 7.6 represents a transition from one active state of an object
to another. The labels shown for each arrow represent the event that triggers the transition.
CREATING A BEHAVIORAL MODEL
STATE DIAGRAM
A state diagram is a graph whose nodes are states
and whose directed arcs are transitions between
states.
A state diagram specifies the state sequences caused by event sequences.

The state diagram is a standard computer science concept that relates events and state.

Events represent external stimuli.

States represent value of objects.

All objects in a class execute the state diagram for that class, which models their common behavior.

The UML notation for a state diagram is a rectangle with object name in a small pentagonal tag in the
upper left corner.
COMPONENTS OF STATE DIAGRAM
Initial State
A solid circle with an outgoing arrow shows the initial state.

Final State OR
A bull’s eye – a solid circle surrounded by a hollow circle/encircled X
shows the termination point.
State
State
Drawn as a rounded box containing the name of the state.
State names must be unique within the scope of the state diagram.
Our convention is to list state name in boldface, center the name near the top of the box, and
capitalize the first letter.
event(attribs) [condition]
Transition/Event

Drawn as a line from the origin state to the target state.

An arrowhead points to the target state.
COMPONENTS OF STATE DIAGRAM
event(attributes) [condition]
Guard condition

A guard condition is a Boolean expression that must be true in order for a

transition to occur.

A guarded transition fires when its event occurs.

Optionally listed in square brackets after an event.

HOW TO DRAW A STATE DIAGRAM

Step 1: Identify the important objects.

Step 2: Identify the possible states in which the object can exist.

Step 3: Identify the initial state and the final terminating states.

Step 4: Label the events which trigger these transitions.

STATE DIAGRAM FOR LIBRARY MANAGEMENT SYSTEM
• Identify the important objects • Identify the events /
– Book transition
– CD/DVD – Book issued to user
– News Paper – Submit the book
– Librarian – Request to issue same book
– Member – Completion of exam / end of
• Identify the states of Book’s Object the Semester

– Available
– Issue
– Return
– Renew
 EXAMPLE: STATE DIAGRAM OF BANK AUTOMATED TELLER
MACHINE (ATM)

This is an example of UML behavioral state diagram showing Bank Automated Teller Machine
(ATM) top level state machine.
ATM is initially turned off. After the power is turned on, ATM performs startup action and enters
Self Test state.
If the test fails, ATM goes into Out of Service state, otherwise there is trigger less transition to the
Idle state. In this state ATM waits for customer interaction.
The ATM state changes from Idle to Serving Customer when the customer inserts banking or credit
card in the ATM's card reader.
On entering the Serving Customer state, the entry action readCard is performed.
Note, that transition from Serving Customer state back to the Idle state could be triggered by cancel
event as the customer could cancel transaction at any time.
Serving Customer state is a composite state with sequential substates Customer Authentication,
Selecting Transaction and Transaction.
 STATE DIAGRAM OF BANK AUTOMATED TELLER
MACHINE (ATM)
Bank ATM
turn off / turn off /
shut-down off shut-down

startup
turn on
/
successfully Self failure
Test

turn on

restart
/
failure
service Maintenanc Out of
Idle
e Service
service
cancel

card inserted remove failure

card
serving customer

Customer
Selecting
Authenticatio Transaction
Transaction
n
CREATING A BEHAVIORAL MODEL
State Representations:

Sequence diagrams. The second type of behavioral representation, called a sequence diagram in
UML, indicates how events cause transitions from object to object.

Once events have been identified by examining a use case, the modeler creates a sequence
diagram—a representation of how events cause flow from one object to another as a function of
time.

In essence, the sequence diagram is a shorthand version of the use case.

It represents key classes and the events that cause behavior to flow from class to class.

Figure 7.7 illustrates a partial sequence diagram for the SafeHome security function.
CREATING A BEHAVIORAL MODEL
SEQUENCE DIAGRAM

A Sequence diagram shows the participants (Objects) in an

interaction and the sequence of message among them.

A sequence diagram shows the interaction of a system with its actors to perform
all or part of a use case.

Sequence diagram represent the dynamic communication between object during

execution of task.

Each use case requires one or more sequence diagram to describe its behavior.

Each sequence diagram shows a particular behavior sequence of the use case.

It is best to show a specific portion of a use case and not attempt to be too general.

You can draw a separate sequence diagram for each task.

COMPONENTS OF SEQUENCE DIAGRAM
Object - Class Roles or Participants Object : Class
Class roles describe the way an object will behave in context.
Use the UML object symbol to illustrate class roles, but don't list object attributes.

Activation or Execution Occurrence

Activation boxes represent the time an object needs to complete a task.
When an object is busy executing a process or waiting for a reply message, use a thin gray
rectangle placed vertically on its lifeline.

Lifeline

A lifeline represents an Object in an interaction.

When that object's lifeline ends, you can place an X at the end of its lifeline to denote
a destruction occurrence. X
CONT.
Messages
Messages are arrows that represent communication between objects.
Use the following arrows and message symbols to show how information is transmitted between
objects.

Synchronous message
Represented by a solid line with a solid arrowhead.
This symbol is used when a sender must wait for a response to a message before it
continues.
The diagram should show both the call and the reply.

Asynchronous message
Represented by a solid line with a lined arrowhead
Asynchronous messages don't require a response before the sender continues.
Only the call should be included in the diagram.
CONT.
Reply message

Represented by a dashed line with a lined arrowhead.

these messages are replies to calls.

Delete message X

Represented by a solid line with a solid arrowhead, followed by an X.

This message destroys an object.
 GUIDELINE FOR SEQUENCE DIAGRAM
Prepare at least one scenario per use case Abstract the scenarios into sequence diagrams.
The steps in the scenario should be The sequence diagrams clearly show the
logical commands, not individual button contribution of each actor.
clicks.
It is important to separate the contribution of
You can specify the exact syntax of each actor as a prelude to organizing behavior
input. about objects.
Start with the simplest mainline
interaction - no repetitions, one main
activity, and typical values for all Divide complex interactions
parameters.
If there are substantially different Break large interactions into their constituent
mainline interactions, write a scenario for tasks and prepare a sequence diagram for each
each. of them.

Prepare a sequence diagram for each error condition.

Show the system response to the error condition.

STEPS TO DRAW A SEQUENCE DIAGRAM

Step-1 Select one scenario

Step-2 Identify the necessary set of the objects. Who is taking part ?

Step-3 Identify the necessary interactions/steps.

Step-4 Describe the message exchange between object.

Step-5 Identify the sequence of interactions and who starts Interactions.

SEQUENCE DIAGRAM FOR BOOK ISSUE

L:Librarian B:Book MR: Member

1. Request for a book
2. Check availability of
book

3. Book available rack no.

4. Validate Member
5. Response for validation
6. Check no of book
issued

7. Book can be issued

8. Update book status

9. Update member status

THANK YOU